maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: Assembly plugin duplicate file resolution
Date Thu, 30 Oct 2014 17:22:39 GMT
On Thursday, 30 October 2014 at 16:41, Kristian Rosenvold wrote:
> O-kay. Now I understand the precedence in question; it is based on
> "container type":
> 
> The handlers for the different assembly phases are wired in with
> 
> @Requirement( role = AssemblyArchiverPhase.class )
> private List<AssemblyArchiverPhase> assemblyPhases;
> 
> 

As observed below, the only guarantee in injected collections is that default components will
appear before non-default components. Otherwise no guarantee is made to the order of entries.
> 
> With maven 3.2.3 this will evaluate to an order of repository >
> dependencyset > moduleset > fileitem > fileset
> With maven 2.2.1 it evaluates to moduleSet > repository > FileSet >
> DependencySet > FileItem
> 
> The first handler to add the file "wins". Now I am unsure of how the
> container decides *order* of elements that are wired into a list like
> this, its certainly different for 2.2.1 and 3.x, and I'm not really
> convinced there is any guarantee of order. It might even differ with
> JDK versions :)
> 
> So for 2.2.1 the documented "fileset > fileitem" precedence seems to
> hold, but not for 3.x.
> 
> So it seems safe to assume that currently precedence is busted in any
> way, shape or form and the site documentation only works for 2.2.1. It
> seems like a lot simpler change to modify the handler order
> ("container type"), to give a precedence like this:
> 
> fileitem > fileset > moduleset > dependencySet > repository
> 
> From a "precedence" point of view I assume it makes sense to have the
> most specific items (fileitem) have the highest precedence.
> 
> This would have to be done in a 2.6 release, not a minor release; a
> nice notice in the release notes should explain it...
> 
> Kristian
> 
> 
> 2014-10-30 13:37 GMT+01:00 Kristian Rosenvold <kristian.rosenvold@gmail.com (mailto:kristian.rosenvold@gmail.com)>:
> > But I really think the feature is legit; it just doesnt work very
> > well, and the precedence in the link I sent seems ill-though through.
> > Using order from the assembly specification sounds much more
> > understandable. And to be honest, I really dont think anyone can rely
> > on this order actually working in the current plugin, there's just too
> > much bugs.
> > 
> > "Unpack this jar, but always use *this* specific properties file" is a
> > nice assembly descriptor.
> > 
> > I think it's perfectly reasonable to evaluate
> > filsets/depedencyset/file specifications in reverse order, so last
> > wins. Achieving repeated items within a single file set is probably an
> > error ( easily achievable with duplicate <files><file> elements, hard
> > otherwise - maybe with hardlinks in the file system).
> > 
> > 
> > Kristian
> > 
> > 
> > 
> > 2014-10-30 13:10 GMT+01:00 Dawid Weiss <dawid.weiss@gmail.com (mailto:dawid.weiss@gmail.com)>:
> > > I agree with Anders, no surprise principle. Fail early. I spent a good
> > > while trying to figure out what the heck is happening with this --
> > > http://jira.codehaus.org/browse/MASSEMBLY-724
> > > 
> > > Dawid
> > > 
> > > On Thu, Oct 30, 2014 at 1:05 PM, Anders Hammar <anders@hammar.net (mailto:anders@hammar.net)>
wrote:
> > > > Wouldn't it make sense to fail the build in case of this instead? As I
see
> > > > it, there's something wrong in the descriptor and it should be fixed.
> > > > 
> > > > Also, doing this change (intead of just altering the algorithm) would
make
> > > > the plugin upgrade "better" (no suprises in the result). A failed build
> > > > with a good message instead.
> > > > 
> > > > /Anders
> > > > 
> > > > On Thu, Oct 30, 2014 at 12:57 PM, Kristian Rosenvold <
> > > > kristian.rosenvold@gmail.com (mailto:kristian.rosenvold@gmail.com)>
wrote:
> > > > 
> > > > > There's a truckload of jira issues related to the inclusion algorithm,
> > > > > and there just seems to be so many simpler ways of handling this
?
> > > > > 
> > > > > filesets/dependencysets/files processed in descriptor order (or
> > > > > reverse descriptor) order, first file wins. Reversing descriptor
order
> > > > > would make "last" file win.
> > > > > 
> > > > > Within a single set, first file always wins.
> > > > > 
> > > > > What is the use case being solved by the existing algorithm ?? And
why
> > > > > does it try to block based on "input" rather than assembly-output
name
> > > > > ?
> > > > > 
> > > > > Kristian
> > > > > 
> > > > > 
> > > > > 
> > > > > 2014-10-30 12:54 GMT+01:00 Kristian Rosenvold <
> > > > > kristian.rosenvold@gmail.com (mailto:kristian.rosenvold@gmail.com)>:
> > > > > > Reading the instructions on
> > > > > 
> > > > > http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html
> > > > > > makes me wonder, why on earth has this precedence been chosen
for the
> > > > > > assembly plugin ??? Especially case 2 is odd.
> > > > > > 
> > > > > > There'
> > > > > 
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org (mailto:dev-unsubscribe@maven.apache.org)
> > > > > For additional commands, e-mail: dev-help@maven.apache.org (mailto:dev-help@maven.apache.org)
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org (mailto:dev-unsubscribe@maven.apache.org)
> > > For additional commands, e-mail: dev-help@maven.apache.org (mailto:dev-help@maven.apache.org)
> > > 
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org (mailto:dev-unsubscribe@maven.apache.org)
> For additional commands, e-mail: dev-help@maven.apache.org (mailto:dev-help@maven.apache.org)
> 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message