#1 gets us back into the realm of trying to decipher whether the behavior of version 2.1 has this as a *feature* or a *bug*. It's along the same lines as MASSEMBLY-194, IMO.
I understand the ramifications here: Maven (at times) will automatically select the version of a plugin to use by resolving the RELEASE meta-version...if this (new?) version is incompatible with the bug workarounds in your existing assembly descriptor, all hell breaks loose. Since we cannot fix the *real* problem here - which is that Maven blindly selects whatever RELEASE resolves to, which was a *design decision* that we made at one point - we're stuck with providing endless backward compatibility, regardless of whether we jump the assembly plugin up to version 3.0 or just 2.2. Even deprecation is a problem here, since (depending on when you use -U) you may completely skip the versions that mark a particular "feature" as deprecated. This is a MUCH bigger problem than we seem to recognize. Who wants to send the email to the users@ list to tell them that, oh, yeah, they need to specify versions for all of their plugins in the POM? I'm not wild about it, but I think that's the only way out...and I'm willing to send that email. -john On 4/10/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
+1 Brett, I think (1) is a feature. If (2) does not work, let's address it to a beta-2 please. We really need to release this, get feedback and prepare beta-2. Thanks, Stéphane On 4/8/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > +1 > > Dan > > On Friday 06 April 2007 10:55, John Casey wrote: > > Hi everyone, > > > > This is the third attempt, after fixing: > > > > * > > http://jira.codehaus.org/browse/MASSEMBLY-194<http://jira.codehaus.org > >/browse/MASSEMBLY-155> > > > > This bugfix actualy adds a new flag to the dependencySet, called > > useTransitiveFiltering, which allows you to enable filtering by > > matching a given pattern against the transitive dependency path of > > the given artifact (in addition to all the other ways). By default, > > this is disabled (useTransitiveFiltering == false), in order to > > preserve backward compat with version 2.1. > > > > So, let's try this one more time: > > > > I wanted to call a vote to release a beta version of the new assembly > > plugin. There are still some outstanding issues (though not as many as > > jira would have you believe; they just need tests), but I think we're > > at around 95-99% backward compatibility and the new features seem to > > be working well. It's been just sitting in SVN for quite awhile now, > > and many people are using it directly from there. I'd like to provide > > better support for those people, and start getting more feedback on > > exactly what's still broken. > > > > The change list is pretty large, but is mainly concerned with > > refactoring the plugin away from the old monolithic approach to one > > that uses phases to handle the different descriptor sections, along > > with common task classes to handle behavior shared between phases. > > > > Road Map: > > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&style > >Name=Html&version=12617 > > > > > > Tag: > > > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plug > >in-2.2-beta-1 > > > > > > Staging repository: > > > > http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/ > >%7Ejdcasey/stage/repo> > > > > So, let's try 72h +1/+0/-1. Please cast your votes! > > > > Here's my +1. > > > > -john > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > --------------------------------------------------------------------- > 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]
