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.rosenv...@gmail.com
> (mailto:kristian.rosenv...@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.we...@gmail.com
> > (mailto:dawid.we...@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 <and...@hammar.net
> > > (mailto:and...@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.rosenv...@gmail.com (mailto:kristian.rosenv...@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.rosenv...@gmail.com (mailto:kristian.rosenv...@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-unsubscr...@maven.apache.org
> > > > > (mailto:dev-unsubscr...@maven.apache.org)
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > (mailto:dev-h...@maven.apache.org)
> > > > >
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > (mailto:dev-unsubscr...@maven.apache.org)
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > (mailto:dev-h...@maven.apache.org)
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org
> (mailto:dev-h...@maven.apache.org)
>
>
