Question

Consider this scenario. I have a small enterprise project dev environment. We use archiva as our artifact repo.

In-general, I would like to have PROJECT-SPECIFIC profiles set up, namely because tests will differ on a per-project basis.

However, the one thing I would LIKE to have constant, is a profile in my settings.xml file, which is active by default, used for development. Do I need to have my team members manually edit that file and place their ARCHIVA credentials in there (ldap system), so that they can access the internal repo?

Should I just not put a password on it? My other alternative is using a master password to encrypt a “shared” password, so nobody could see it, yet they would all have generic “read-only” access to the internal repo for snapshot dependencies and stuff. However, then they would also need the security-settings.xml file which contained the encrypted master password, and doesn’t that defeat the purpose of that system?

finally: can multiple profiles be active at the same time, or is that unnecessary? For example, if I have the dev profile active by default (which contains the artifact repo settings, encrypted svn credentials for releases), and then I specify different profiles in certain POM files, am I only to pick ONE profile? Let’s say I want to use Bamboo for CI, and there are some “test” profiles which use the surefire plugin and whatnot. Will these profiles co-exist with the activeByDefault DEV profile that exists in settings.xml, or can only one profile be activated at one time? All CI needs is the SCM information, so technically it shouldn’t need access to the internal archiva repo, so I suppose that if I was using a test profile (automatically using CI), it wouldn’t need anything from the profile.

I’m confused. I’m so close to having a fully maven-managed build environment, just trying to iron out those few kinks. Thank you.

Answer 1

However, the one thing I would LIKE to have constant, is a profile in
my settings.xml file, which is active by default, used for
development. Do I need to have my team members manually edit that file
and place their ARCHIVA credentials in there (ldap system), so that
they can access the internal repo?

Yes, they would have to edit that file on a pr user basis. From the doc:

The passphrase and password elements may be externalized in the future, but for now they must be set plain-text in the settings.xml file.

Should I just not put a password on it? My other alternative is using
a master password to encrypt a “shared” password, so nobody could see
it, yet they would all have generic “read-only” access to the internal
repo for snapshot dependencies and stuff. However, then they would
also need the security-settings.xml file which contained the encrypted
master password, and doesn’t that defeat the purpose of that system?

Why not add users public key to Archiva, and authenticate that way?

<servers>
    <server>
      <id>server001</id>
      <username>my_login</username>
      <privateKey>${user.home}/.ssh/id_dsa</privateKey>
      <passphrase>some_passphrase</passphrase>
      ...
    </server>
  </servers> 

finally: can multiple profiles be active at the same time, or is that
unnecessary?

Yes, multiple profiles can be active. You can use mvn help:active-profiles to list active profiles.