Hervé BOUTEMY wrote:
I didn't have time to really look at it, but I like this deps directly into
classpath!
really kewl ;)
I know man, I was really excited when it all worked! The coolest part is
that <deps> can also be used inside filesets, so you don't need to do
anything special to access files behind artifacts. I have not tested it,
so I will add a UT to showcase this.
I have only one little question:
<dependency name="t:t:1.0::pom" pom="${basedir}/t-1.0.pom"/>
why specify name when you use pom? All the information in in the pom content,
no? This leads to information duplication, or even worse, inconsistency...
It's because Mercury does not know anything about POM files, it only has
a Java object that captures the dependency part of the model. This
design was intentional and came from the requirement to separate
dependency resolution from dependency storage.
As a result - Mercury relies solely on external providers to convert
stored dependencies into Java objects. Naturally - the interface to this
provider is GAV-only: this is the GAV, give me it's dependencies.
So if there is a raw POM file - I have 3 choices:
1. write an interpreter - bad idea as there is too much maven core
involved, and I only need dependencies
2. call project builder to read it this mixes in ProjectBuilder as a
direct dependency and conversion from Maven Artifact to Mercury
Artifact, so I chose to avoid it for now. This is still an option, and
this is how I would do it if this becomes a nuisance
3. require user to supply it. Used this now as the least resistance way
Please let me know if supplying GAV and POM is too much of a burden; I
will switch to #2.
Thanks,
Oleg
