My answers below
2013/8/26 Dridi Boukelmoune <dridi.boukelmo...@zenika.com> > >> Point 2 : Even if there is no much activity, i suggest to keep backward > >> compatibility > > > > fine for me. > > Not necessary from my point of view. My only advice is to avoid legacy > (or technical debt ;) at such early time. > > I was suggesting to keep backward compatibility mainly because easyant is build by easyant :). Though we need "older" plugins to build the new easyant and "vice et versa". > >> Point 3 : By two steps i meant running a global resolve (for all plugins > >> and buildtypes including transitive ones). And then have a second class > >> invoked to perform individual import of ant build file by picking them > from > >> the ResolveReport. > > > > ok I see. This make totally sense. > > This is where I'm lost. Actually the whole issue of dependencies > conflicts between plugins. > > Here is the behavior I think I've observed with Maven: > - maven resolves project dependencies and does a shitty job at > conflicts resolution > - maven resolves plugins dependencies one by one and downloads them lazily > - each plugin is executed with its own classloader, and doesn't care > about other plugins dependencies > - I can get a dozen versions of the infamous[1] plexus-utils in a single > build > > My point is, given proper isolation, is it a real issue to have > different plugins depending on different versions of the same modules > ? > The main point is to avoid having dozen version of jars :). But we also have a internal limitation, ant doesn't load a buildfile two times. So if we have many plugins relying on abstract ones, abstract ones must be uniquely resolved. -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
