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]
