You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/07/29 19:47:13 UTC
Severe assembly plugin problem
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Severe assembly plugin problem
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Severe assembly plugin problem
Posted by John Casey <jd...@commonjava.org>.
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
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Severe assembly plugin problem
Posted by John Casey <jd...@commonjava.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Posted by Brett Porter <br...@apache.org>.
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=rev&revision=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=rev&revision=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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org