On Jul 30, 2007, at 8:18 AM, Jason van Zyl wrote:
I've added code in 2.2-beta-2-snap to address this problem...at
least, it should address it. I added resolution to the plugin
before 2.2-beta-1 because there were issues when people wanted to
create an assembly that didn't require dependencies to be
resolved, and the dependencies couldn't be resolved for one reason
or another. This way, dependency resolution is held off until one
or more assembly-descriptor subsections requires it.
How did it happen that you needed a different resolver? In the
shade plugin we're just using the set of artifacts resolved by the
system. You found something that didn't work to allow you to select
the artifacts you wanted due to problem with the artifact
resolution code? I have found problems too but can be worked around
inside the plugin and the set of artifacts handed back using
@requiresDependencyResolution.
As I mentioned before, not all assemblies require dependencies to be
resolved. In cases where the project's dependencies cannot be
resolved for one reason or another, using
@requiresDependencyResolution puts an unnatural constraint on these
builds.
IMO, this is indicative of a need to allow a plugin to call back into
the core and resolve/retrieve the project's dependencies (and it's
not the only case; see any of the IDE plugins). I'm not sure that I'm
actually using a different resolver implementation, though...I don't
remember that being an issue.
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
