> -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 04, 2004 8:53 AM > To: 'Maven Developers List' > Cc: 'Stefan Bodewig' > Subject: RE: [maven2 [...]
> Agreed. It's almost there but a little push towards even better > separation from Ant core is required I think. But again we must do it > with the Ant team. I know Stefan is keen to help. > > I've started a discussion on the Ant ML which is ATM geared towards > reusing the JUnit Task in embedded mode. > > > BTW: It's not probably the well known fact by Peter Donald has (long time ago) proposed his vision of ant2. http://ant.apache.org/ant2/actionlist.html Some (most?) of this points is quite close to what we are planning to do with m2. ant2 development has never really started but is rather clear that it is a very different animal then ant1 and the code as a whole cannot be reused. The design goals are different. AFAIK the reason why ant2 development has never pick up was that most of ant developers believe that ant1 is good enough and people who didn't agree with that simply don't care that much anymore. > > > The problem with refactoring out is that you still need to expose > the > > > following: > > > - configuration IF (that can be solved easily by having setters) > > > - lifecycle IF (that can be solved easily by saying all tasks are > thread > > > safe) > > > - classloading IF (that can be solved by having a > > > setClassLoader(ClassLoader) as this IF already exists in the JDK > > > - logging IF (this is the hardest one, unless we decide to use the > JDK > > > 1.4 logging IF but then I'm not sure everyone would agree) > > > > Yes, and things like consistent logging etc need to be solved for > Maven2 > > before it goes too far and we end up with a System.out.println fest. > > commons-logging is the best match I can think of for now. > I don't think it's the best option. Logging is often used as a substitute for proper exception handling and for debugging. With Log4J/JDK Logger and such libraries the problems might appear when hierarchy of class loaders is more complicated (this is generally the problem with the singleton design pattern). Design Patterns like Monitor (that's what was used already in Wagon) seems much more appropriate and less intrusive. Debugging mode can be also easily implemented with AOP programming (all calls to plugins method can be easily registered and written to a log). It should be not that hard to do this with plexus and classworlds (this mode can be enabled on demand when maven is started and bundle of jars which allows this can be optional). Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]