after investigation (everything is described in details in MASSEMBLY-777), these exclusions were necessary when using File based filtering, creating temporary files with extensions
but Kristian fixed the filtering by switching from File based filtering to Reader based filtering for maven-assembly-plugin 2.5.1 Thank you Kristian :) I then removed the exclusions without any fear: now unused hack Regards, Hervé Le mardi 14 juillet 2015 18:11:59 Sander Verhagen a écrit : > Interesting, the commit for "**/*.filtered" says: "Based on patch > provided...". But the patch does NOT exclude the .filtered, while the > commit does. That makes it a very unclear whether the .filtered was > actually so much related to MASSEMBLY-154. The unit test (change) does also > not address this detail of the code change. I could see how this is all > *so* sketchy that you'd just want to get rid of it. If you choose to keep > it, you could change it from an undocumented feature into a documented > feature, easy enough, though :) > > > Sander Verhagen > [ [email protected] ] > > NOTICE: my e-mail address has changed. Please remove [email protected] now > and start using [email protected] from now on. Please update your > address book. Thank you! > > > > -----Original Message----- > > From: Hervé BOUTEMY [mailto:[email protected]] > > Sent: Tuesday, July 14, 2015 10:53 > > To: Maven Developers List > > Subject: Re: Intend to release maven-assembly-plugin 3.0.0 > > > > blame done and found the inital commit for the 2 excludes: > > see https://issues.apache.org/jira/browse/MASSEMBLY-777 > > > > Regards, > > > > Hervé > > > > Le mardi 14 juillet 2015 17:19:30 Sander Verhagen a écrit : > > > > > I'm not much of a stakeholder in this but after following the > > > discussion I'm getting curious if there's any hints to why this was > > > introduced? Is there a VCS "blame" to do that links to a JIRA issue of > > > some kind? This could uncover at least a few (reasonable or not) use > > > cases for this (admitted, seemingly strange) micro-behavior. > > > > > > > > > > > > > > > > > > Sander Verhagen > > > [ [email protected] ] > > > > > > > > > > > > NOTICE: my e-mail address has changed. Please remove > > > [email protected] now and start using [email protected] > > > > from > > > > > now on. Please update your address book. Thank you! > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Benson Margulies [mailto:[email protected]] > > > > Sent: Tuesday, July 14, 2015 10:05 > > > > To: Maven Developers List > > > > Subject: Re: Intend to release maven-assembly-plugin 3.0.0 > > > > > > > > > > > > > > > > > > > > > If it’s easy to make compatible why would you not do it? > > > > > > > > > > > > > > > > > > > > Really, this is the only interesting point of disagreement here. > > > > It's easy for > > > > _me_ to make it compatible. It's hard for readers of the assembly > > > > > > descriptor documentation to digest and understand yet another option > > > > that tweaks yet another micro-behavior. One user out of 10,000 might > > > > be disturbed by the arrival of a foo.filtered file. 9,999 users out > > > > of > > > > 10,000 will have to wade through the extra doc. And some unknown > > > > number of people will run into the (to me) bizarre current behavior. > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > - 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] >
