> -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 04 May 2004 07:55 > To: 'Maven Developers List' > Subject: RE: [maven2] Anything Groovy in Maven2? > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > Sent: 04 May 2004 03:47 > > To: [EMAIL PROTECTED] > > Subject: RE: [maven2] Anything Groovy in Maven2? > > > > Jason van Zyl <[EMAIL PROTECTED]> wrote on 04/05/2004 01:11:12 AM: > > > > > > > It's easy to solve, don't code things as Ant tasks. If you're doing > > > something new then there is absolutely no reason to bind your code > to > > > Ant. Make POJO and wrap it. > > > > Can we do the same for Maven2 then? i.e. > > > > "It's easy to solve, don't code things as Maven2 plugins. If you're > doing > > something new then there is absolutely no reason to bind your code to > > Maven2. Make POJO and wrap it." > > > > To me it looks like Maven2 is going the same way as Ant in this > regard. > > E.g. If we refactor out the 'delete' functionality from Ant (or the > clean > > m2 plugin) into a POJO, and simply call that from a plugin wrapper it > > would make more sense. And they should be very thin wrappers too, so > that > > the POJOs are reusable elsewhere. > > > > That way we'd be building up reusable code (like the jar and other > plugins > > are in m2). > > Big +1 from me. Actually, there's a TaskAdapter in Ant for doing exactly > this.
Several things: - when you talk about "refactoring out", do you mean refactor out within the Ant project or copy-paste the code somewhere else? - Refactoring out is not that easy (but possible) as the Ant tasks are quite linked to the Project class. - What would the refactoring buy us? Ant tasks can already be reused outside of the context of Ant, from any java code. There are some gotchas in some cases (for tasks that require some classloader) but this is mostly done in the task code itself and not generally across Ant's code base. I've talked to Stefan and he's very open to work with us, task by task to make change to accommodate us should it be required. 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) Thanks -Vincent > > Thanks > -Vincent > > > > --------------------------------------------------------------------- > 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]
