On 2009-10-30, at 4:39 PM, Benjamin Bentmann wrote:
Brian Fox wrote:
I think we have to also consider that 2) is what Maven does now.
(Benjamin thinks it might be 3 but I seem to recall repos added along
the way stick around forever)
I was trying to check what Maven 2.x actually does and came up with
this POM snippet:
<dependencies>
<dependency>
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-utils</artifactId>
<version>1.4.0</version>
</dependency>
<dependency>
<groupId>edu.purdue.cs.bloat</groupId>
<artifactId>edu.purdue.cs.bloat</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
The first dependency nexus-utils is available from central and its
POM inherits a repository called sonatype-forge from its parent. The
second dependency is not available from central but only from
sonatype-forge.
Now in an environment without any mirrors, invoking something like
"mvn compile" on this POM to trigger dependency resolution, I
observed Maven 2.x failing to resolve the second dependency because
it only tried to download it from central and did not consider the
repository declared in the POM of nexus-utils.
This seems to indicate that Maven 2 is scoping the repositories
discovered in dependency POMs to the sub tree of the dependency
graph its about to process.
Scoping is the relatively easy part. Start trying to figure what to do
when sub-trees contribute conflicting artifacts. We have the simple
depMan approach which is just to override absolutely everything. This
may be fine if you know what your target platform is (and I use the
term used by the eclipse folks intentionally), but when it's not
described then you're back to full conflict resolution. It may simply
be we do what the Eclipse folks do which is to iteratively correct the
target platform until you have something that works. Where this breaks
down is when you start combining disparate target platforms and now
you start doing conflict resolution again or it simply doesn't work.
This is the general problem with people having an eclipse installation
and they download some plugin which was developed apart from the
standard eclipse distributions and you get a conflict which renders
your system unusable. Do we try to be proactive and store the
information to allow thing developed separately to be reconciled more
automatically? Is letting the user reconcile this through an iterative
process the way to go?
We could make some simplifications like an artifact having a canonical
repository, or home repository as Igor calls it, so that when people
hijack another projects artifactId/groupId these artifacts are not
considered in the calculation unless specific instructions are issued
by users with additional knowledge. Ultimately this may all be too
complicated and the reality may be that we can provide tools to help
reconcile these differences but ultimately you arrive at a hand-
crafted target platform for your final resultant application.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
