On Mon, 2004-05-03 at 21:46, [EMAIL PROTECTED] wrote: > 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.
Absolutely, which is what I've done with the surefire plugin which I backported this morning in an attempt to use it with Groovy to make it build faster. I will also do the same with the xdoc plugin. > "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." Maven2 can absorb three forms of POJOs and another which can use an integrated form of a plugin that requires a 3k dependencies in order to work in a long-lived process. They are currently in the maven-core repository but it's a set of interfaces for a POJO which can communicate with other POJOs and work in long-lived processes. But this integrated form is not required. > To me it looks like Maven2 is going the same way as Ant in this regard. No, if you actually looked at code you'll see it's not. There are tests for the 4 varieties and even the fourth variety only requires a 3k dep which does not really have anything to do with Maven2. They are interfaces which are the minimum needed for a POJO to interact with a client system. The integrated form is essentially: execute( request, response ) And that is really it, the slightest bit of glue which allows this form of POJO to operate from the CLI or any embedded environment. > 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's exactly what I'm doing. If you look at the plugins in m2 only one of references maven-core only because I haven't bothered to fix it. But how they work is that Maven extracts the parameters required to execute the plugin by using OGNL pull the values out of the POM. No binding to Maven2. Save but one of the m2 plugins could be integrate into anything without requiring plexus or maven. > That way we'd be building up reusable code (like the jar and other plugins > are in m2). I plan for something like a checkstyle plugin to work from within m2, a proxy to run it as an Ant task, and with the notion of long-lived processes it can be integrated in IDE plugins. And not only that with some adapters hopefully provided by the Mevenide folks there will only be one (though this may not be possible given Swing/SWT variances). By that I mean the checkstyle IDE plugin migth itself have a panel for operation so it does the execute( request, response ) and what might come is a model of source files with violations. This information would be standard and there could be adapters provided by Mevenide could provide a general way, to say, move to a source line in a buffer where a violation occurred and highlight the line. You get the idea anyway. The maven2 plugins are not analagous to ant tasks becasue they are not bound to the MavenProject whereas ant tasks are heavily bound to ant constructs. The movement of parameters in m2 is entirely mediated by OGNL which allows the m2 plugins to be used anywhere outside the context of Maven. What you are thinking of as most sensible is in fact exactly what I'm doing. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
