Awhile back, I sent out an email asking for use cases where backward compatibility was broken from 2.1. This is obviously one of those...can we log a jira for this, so we can incorporate a test case or three to keep it from happening again?
I've found several issues with backward compatibility since I refactored the plugin, which is mainly what's been keeping me from releasing it. The more of these sorts of things we can incorporate in the unit- or integration-testing regimen, the better off we'll be for future releases. Thanks, John On 11/6/06, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
I am running 2.2-SNAPSHOT and will try the HEAD later today. Cheers, Stéphane On 11/6/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > > I had the same issue (the second one you mentioned), and I think I fixed it in revision 466968. > > Are you running with HEAD? (2.2 is still at SNAPSHOT). > > Let's try to find where it broke: can you svn up -r466968 the assembly plugin and check if that version works? > If so, it must have been broken afterwards. If not, I didn't fix it and we need to search back further. > (maybe I broke it?) > > -- Kenney > > Stephane Nicoll wrote: > > Hi, > > > > I don't know if this is made on purpose but I'm really having a hard > > time configuring my assembly descriptor with the latest snapshot > > version of the assembly plugin (2.2). > > > > The way dependencies are handled has really changed and I am stuck on > > a simple use case. > > > > Project A is a simple resources project and it depends on B > > Project B generates a standard lib and depends on 3 3rd partly libs > > (C,D,E). > > > > Now I want to expand project A in the root of the distribution > > (contains legacy ant build script for instance). With 2.1, it works, > > with 2.2 the assembly plugin unpacks B, C,D and E as well! > > > > In another section of the assembly, I would like almost all > > dependencies to be stored in a lib directory. The only one that does > > not need to be there is project A (since it has been unpacked in the > > root of the distribution). Again with 2.1 it works, with 2.2 B,C,D and > > E are excluded as well. > > > > I am sure the changes make sense but I really don't understand the way > > dependencies are handled now plus it's not backward compatible at all > > (?!). > > > > Thoughts? > > > > Stéphane > > > > --------------------------------------------------------------------- > > 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]