Comments inline.
Cheers,
John
Garrett Conaty wrote:
I've been working quite a bit with Maven2 transitive dependencies at
work, and think that they're one of the best strengths of M2. In the
course of building quite a number of artifacts through build,
deployment, and update I've found that there are number of improvements
that can be made. So with the use cases that I've seen at work and
listening to what other devs in the community have experienced, I'm
proposing some enhancements.
These points are only an overview, and some are a variation or
enhancement on features in the Maven 2.1 design docs. I've gone into
more depth on the rationale and the features themselves on the MavenUser
Wiki at
http://docs.codehaus.org/display/MAVENUSER/Improving+Maven2+Dependency+Resolution
:
* Virtual Dependencies (also know as spec jars)
This is something we've been discussing for some time now. We just need
to have a concrete discussion about what's involved in implementing it.
For instance, we have to provide a portable way to resolve spec ->
implementation mappings. This might take a form similar to the
plugin-prefix -> implementation metadata file. Once we have that in
place, we need some consistent mechanism for choosing one implementation
over another. The corresponding mechanisms for plugin selection based on
prefix are somewhat crude...
* Environmental Context - Use the JDK environment and deploy environment
as part of the resolution phase. As an example, you don't need to get
JAXP API classes from a repository if compiling with JDK 1.4
If you can represent pieces like the JDK as a repository with an
alternate layout, I don't see why we couldn't tie this into the spec
dependencies bit above and make it work.
* Pinning Dependencies (Overrides) - If you have a fixed dependency tree
for a given release, it's important to be able to provided patches that
can override a node of the tree. <dependencyManagement> only appears to
handle this for parent-child projects.
I suspect an elegant way to handle this might be with an alternative
dependency selection implementation that uses some authoritative set of
"approved" versions when resolving artifacts...
Questions I have WRT this are:
1. will this set of blessed versions be portable (i.e. travel with the POM)?
2. how will developers in a team setting share this info? It seems like
implementing this would be an exercise in walking a tightrope between
portability and centralized declaration for versions.
* Filtering Parameters - Let the dependency resolution be able to pick
artifacts based on things like required JDK version, license,
signed/unsigned, tags,etc.
Is this a dependency selection technique? It seems like it's just a
matter of "approving" a given dependency as a candidate for selection
using POM attributes and possibly attributes of the jar itself (which
could be a bit more involved), before allowing artifact version
selection to proceed. Much of this could probably be factored out of the
DefaultArtifactCollector, into some sort of pluggable component.
* Blacklisting artifacts - Not just repositories. This is appropriate
if you don't control the POM that's using the artifact to be blacklisted.
...so you're talking about a global exclusions list? Again, my questions
about this center on dissemination of that list. Otherwise, can't you do
this with dependency exclusions now?
* License Acknowledgment - Some commercial vendors (Sun) require a
clickthrough license before downloading. Also a user getting an artifact
under an Apache license with an LGPL dependency would need to be
notified that they are not only accepting the Apache License but LGPL.
This might be another thing that gets added to the dependency selection
process, when we're gathering candidate artifact/versions. If you
combine it with spec dependencies, the selection algorithm might be able
to select an alternate [set of] deps to satisfy the spec dependency you
specify (when the user refuses to traverse the click-through)...
Also, any click-through implementation will have to completely satisfy
the legal requirements of people like Sun, which could mean finding a
way to embed/interact with a full-featured browser. I don't know of any
cross-platform way to do this, without embedding a browser...and I'm not
aware of any mature embeddable browser implementations, personally.
* Expose dependency resolution to client tools - Provide APIs so that
clients can pass in different artifacts with different filters to see
not only the multiple artifacts and paths that can resolve a dependency,
but also which one would be selected. This would be very helpful for
debugging and also to let UI tools visualize the dependency graphs.
We can undoubtedly go further in making this accessible, but it should
be possible to do what you describe even now. It's just a matter of
knowing the APIs...
I don't think these features have easy workarounds in Maven 2.0.x, but
if there are, that would be great.
I've peer reviewed these with the folks at work as well and I'm
interested in feedback from the community on these improvements as I'd
like to get started working on them.
Thanks,
Garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
