buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Young <ayo...@redhat.com>
Subject Re: Idea: Maven Plugin Support
Date Mon, 26 Apr 2010 14:31:52 GMT
My gut says:  There be Dragons.  If people want to use Maven, let them.  
People come to buildr to get away from a lot of that stuff.  Just 
because something is possible, doesn't mean you should do it.

That said, it would be funny if Buildr ended up being a better Maven 
than Maven itself.  Still, I'd wait and see what the Maven 3 team comes 
up with before looking in to integrations too closely.  The solutions 
will likely be cleaner for the reasons you list below.




On 04/26/2010 08:44 AM, Daniel Spiewak wrote:
> Over the weekend, I spent a little time dredging through Maven's
> highly-diffuse documentation and I have come to the conclusion that we could
> actually add support for running Maven plugins (mojos).  In theory, this
> integration could be fairly tight, making it possible to configure a Maven
> plugin in the scope of a particular project and then use the relevant goals
> as plain-old Rake tasks (e.g. test.enhance('surefire:report'), to pick a
> really pointless example).  There are a couple of problems though.
>
>     1. Maven2 was designed before Java 5, and so Mojos use non-standard
>     doclet annotations (parsed with Qdox) to define goals, parameters, etc.
>     This is tricky, because I *think* this means that Maven has to actually
>     download a plugin's source in order to execute it, but documentation on this
>     point seems to be sparing.  Anyone care to shed some light?
>     2. The Mojo API seems to have *scads* of undocumented features (like
>     gaining access to a MavenProject instance).  A lot of these are mentioned
>     in passing on the wiki, but I'm not confident that we could track them all
>     down, meaning we would have holes and incompatibilities in our Maven Plugin
>     support (we wouldn't be able to support some plugins, and we wouldn't really
>     know which ones).  Undocumented behavior sucks.
>     3. At the very least, we need to be able to define our own implementation
>     of the MavenProject class, and this is potentially the biggest roadblock of
>     them all.  In a nutshell, we need to extend MavenProject, implementing all
>     (or as many as possible) of its methods in terms of the Buildr API.
>     Unfortunately, RJB doesn't seem to allow for extension of Java classes.  I
>     suppose we could extend MavenProject in Java code and somehow sneak
>     callbacks across the barrier, but this seems both ugly and disaster-prone.
>     JRuby *does* allow for the extension of Java classes, so we could still
>     conceivably do this, but it would mean that Maven Plugin support would not
>     be available when running under MRI.
>
> Any thoughts?  Does anyone else think this is worth pursuing?  (with the
> knowledge that my spare time is...sparing, so this won't get done quickly)
>
> Daniel
>
>    


Mime
View raw message