On 30 Jul 07, at 12:27 AM 30 Jul 07, John Casey 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.
IMO, this is a perfectly valid use case for artifact resolution,
and moreover, the reason we separated the artifact api from maven-
core in the first place. If we decide we want to enable plugins to
call back into the core conditionally to trigger artifact
resolution, then fine...but this isn't possible in 2.0.x.
For systems that have no access to the mechanism, but redoing it in
plugins doesn't make much sense to me as a full power of resolution
is available using @requiresDependencyResolution. What was the reason
to duplicate the resolver?
-john
On Jul 29, 2007, at 12:47 PM, Jason van Zyl wrote:
The assembly plugin doesn't seem to obey a hard version that I am
specifying in my POM as [1.2-alpha-9]. In addition I have this in
the dependencyManagement section of Maven's parent POM and it
still ignores it.
Right now I cannot get the assembly plugin to use the hard version
I am specifying. So I took a look at the assembly plugin and
noticed that it has it's own dependency resolver? And the question
is why? There are problems enough with the dependency resolution
but why are we adding insult to injury by adding yet another
resolver which has to stay in sync with the main code?
I cannot easily tell whether it's a problem with resolution in
general, or a result of the copy.
In my case I need the latest release of classworlds for anything
to work with trunk and it won't give me what I ask for rendering
the assembly plugin useless as I can't even plugin a chunk of ant
in there to replace the JAR before it tries to archive it.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
