RE: Severe assembly plugin problem
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. +1 This would be handy in the dependency plugin and also enforcer (http://jira.codehaus.org/browse/MENFORCER-11) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Severe assembly plugin problem
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]
Re: Severe assembly plugin problem
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
Re: Severe assembly plugin problem
Since John's on holidays you probably won't get a full answer for a little bit, but I took a quick dig in the svn logs and would guess: - this was to work around limitations in the artifact resolver (http://svn.apache.org/viewvc?view=revrevision=438528) - it delegates to the original artifact resolver so it should be mostly compatible, but I agree it's a bit worrying that it modifies the behaviour. - the problem you are seeing with depMan is fixed in r557792, which is not in the latest release (http://svn.apache.org/viewvc? view=revrevision=557792) - I would speculate the range issue is in core and not the resolver, though I haven't done any tests. Maybe you could try the 2.1 release instead of 2.2-beta-1? - Brett On 30/07/2007, at 3:47 AM, 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Severe assembly plugin problem
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. 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. -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
