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;
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 <[email protected]>:
> 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 <[email protected]>:
>> 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 <[email protected]> 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 <
>>> [email protected]> 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 <
>>>> [email protected]>:
>>>> > 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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> 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]
