Dependency isolation

[ruel.loehr]

I ran into an interesting Maven specific problem while working the xb breakout.

The net of the issue is that once a dependency and it's associated pom are downloaded they are only updated if the user specifies a version change or removes the dependency from their local repo. In theory, this makes sense, in practice however, it can be an issue.

For example, a user with an empty local repo attempts to build a project (non-jboss) using items from the ibiblio repo. His build retrieves those dependencies and puts them in his local repo. The pom he gets for junit looks like this:

http://www.ibiblio.org/maven2/junit/junit/3.8.1/junit-3.8.1.pom

Noticably absent are important things such as license information, project information, and so on.....

The user next will attempt to build a jboss project. JBoss also requires the junit dependency and has a copy of it in our own public repo.

http://repository.jboss.com/maven2/junit/junit/3.8.1/junit-3.8.1.pom

However, since the user already has this dependency in their local repo, it will not be updated, thus, the build uses a version which we can't control, and is really incorrect.

The workaround at this time is to name all dependencies we use with a name that is distinct from that of those in the ibiblio repo. e.g.:

<dependency>
 <groupId>jboss-junit</groupId>
 <artifactId>junit</artifactId>
 <version>3.8.1</version>
 <scope>test</scope>
 </dependency>

Related jira issue:
http://jira.codehaus.org/browse/MNG-1954
Related discussion:
http://www.nabble.com/updating-of-dependency-pom%27s-t1288191.html

[starksm64]

Can't this be dealt with by specifying the jboss repository as the primary one? Really I don't want to be relying on thirdparty (non-jboss hosted) repositories for anything.

[starksm64]

Also, a project should not build if a dependency that has inadequate pom info does happen to be used.

[ryan.campbell]

Just to clarify, we *are* specifying the jboss repository as primary. The issue is

1. a developer builds some non-jboss project, they download the POMs from some other repository.
2. when the developer tries to build JBoss, the POMs from the other repository are not overwritten.
3. We get potentially inconsistent builds, or the build just fails due to the license validation.

[ruel.loehr]

What I want is that whenever a user builds a jboss project (AS, XB, Cache) a specific "jboss" local repository is used (e.g. C:\jboss-maven-repo). This local repo would not be used when building other non-jboss projects. This would ensure we always our building against our own versions of dependencies and there would be no reliance on thirdparty repositories.

There are a few ways to define your own local repo location:
1) in your MAVEN_HOME/conf/settings.xml (global)
2) in your $USER/.m2/settings.xml (user)
3) via command line: mvn -Dmaven.repo.local=C:\blah install

1 & 2 will not work because when the value localRepository is set there it will apply to both jboss & non-jboss projects.

3 will work. A user could set an env variable (or we determine it for them) which points to his jboss-maven-repo . Each jboss project would have a script (build.sh) that kicks off the build with appropriate jboss repo location.

[starksm64]

The disconnect is that the local repository should be validated against those that the project pom says it will accept content from. If maven does not have this notion its broken for our purposes. There needs to be a notion in the repository as to whether or not its an authoritative source for an artifact. A local repository is by definition authoritative for nothing unless it can match the source of its content against that of the requesting project.

So my question is, is it a plugin that manages the local repository up to date check or is this an inherent behavior in maven?

[ruel.loehr]

It is inherant behavior in the core of Maven. I spoke with their developer lead last night, and he agreed that it is an issue. I'm putting together a patch for it such that artifacts will be updated if their md5 sums do not match those in repository specified in the pom.

[starksm64]

Ok, great.