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 asse
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 assemblyPhases;
With maven 3.2.3 this will evaluate to an order of repository >
de
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 i
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 wrote:
> Wouldn't it make sense to fail the build in case o
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
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 wi
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'
