maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Artifact resolution bugs and unfortunate jar-plugin/assembly-plugin interactions.
Date Mon, 21 May 2007 06:45:42 GMT
Seems like a good idea to capture this as a 2.1 feature request,  
write it up in the wiki and link in any related JIRA issues from all  
the plugins and MNG itself so that it has a focal point. As we work  
through things like the artifact mechanism it can be taken into  

That's in the general case, but hopefully we can also apply  
workarounds to the plugins to get these working properly in the mean  
time with 2.0.x.

I'm also particularly interested in seeing the "wider class of bugs"  
found by upgrading the assembly plugin be followed through while it's  
still in beta.

- Brett

On 19/05/2007, at 3:11 AM, Max Bowsher wrote:

> This is an email about a class of bugs, discovered working with the
> following general scenario:
> I am building a standalone Java application.
> maven-jar-plugin is configured with mainClass and addClasspath=true.
> maven-assembly-plugin is configured with a <dependencySet> to  
> gather up
> all the dependencies into a single directory.
> The application is invoked by a shell script which executes "java -jar
> $jarfile".
> This all works fine when using only release dependencies. When  
> snapshot
> dependencies are involved, the jar and assembly plugins sometimes
> disagree about whether to use SNAPSHOT or YYYYMMDD.HHMMSS-N naming for
> the dependent artifacts.
> To begin with, I will discuss the situation when using
> maven-assembly-plugin 2.1:
> This is JIRAed as MNG-2456. The underlying issue here is a Maven core
> bug - maybe something to fix in 2.1? Specifically, the
> DefaultArtifactResolver explictly set the Artifact "file" field to a
> path in the local repository using the SNAPSHOT rather than
> YYYYMMDD.HHMMSS-N form. Perhaps this is correct behaviour - but if so,
> it should be documented in the Artifact interface, and perhaps an
> additional field made available to expose the versioned file, if  
> one exists.
> Now, switch to considering the situation with maven-assembly-plugin
> 2.2-beta-1:
> This opens the doors on a larger class of bugs. Before, both jar and
> assembly plugins were using the same set of resolved artifacts -  
> the one
> produced by Maven in response to the @requiresDependencyResolution  
> mojo
> javadoc annotation. assembly-plugin 2.2-beta-1, though, switches to
> doing its own resolution. (I don't know why.) Even the "baseVersion"
> fields of the returned artifacts are then set to YYYYMMDD.HHMMSS-N  
> form
> - clearly wrong.
> This is a symptom, I think, of the weird way the DefaultArtifact class
> is written, with accessors that cause state changes - bug prone. A key
> example is DefaultArtifact.isSnapshot(). I would suggest that for  
> Maven
> 2.1, the class be changed such that all state changes are done in  
> setter
> methods, rather than adapting the state of the artifact object on the
> fly in accessor methods.
> Whilst speaking of DefaultArtifact and versioning bugs, another aspect
> to consider changing is the somewhat confusing interface for setting
> this information: There are three private fields closely concerned  
> with
> this - the "baseVersion", "version", and "file". Each of these has a
> direct public setter - though the setter for "version" is called
> setResolvedVersion(), not setVersion(). Then, there are additional
> setter methods setVersion(), selectVersion(), and updateVersion()  
> which
> update various combinations of these fields. I'd imagine some of these
> should be deprecated, because the current situation makes it really  
> hard
> to determine what the true behaviour of the class is.
> So, in conclusion, I think changes of some sort are needed in the  
> maven
> core, the jar plugin, and the assembly plugin, to fully sort out this
> collection of bugs for both 2.0.x and 2.1 lines.
> This is a really entangled issue with fearsome potential for
> compatibility problems, but if people more expert than I can help with
> defining the general direction to proceed, I'm more than willing to  
> work
> on producing patches.
> Thanks,
> Max.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message