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]

Reply via email to