You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/05/03 00:43:38 UTC

[maven2] Anything Groovy in Maven2?

Hiya,

Was just wondering if there were any ideas regarding the use of Groovy 
with maven2 or is scripting totally out of the picture? 

I'm especially fond of any language that pays its respects to the 
mighty GString :-).

Alex 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 03 May 2004 23:20
> To: Maven Users List
> Subject: RE: [maven2] Anything Groovy in Maven2?
> 
> On Mon, 2004-05-03 at 15:03, Vincent Massol wrote:
> 
> > funnily, I'm running the JUnit task in embedded mode for the abbot
> > plugin I've checked in a few days ago and .... believe it or not...
it
> > works :-)
> >
> > Here's the url: http://tinyurl.com/2uy9b (look at the
> > executeAntJunitTestRunner method).
> 
> You are running that outside the context of an AntClassLoader? I think
> our notions of embedding are different i.e. I doubt something like
IDEA
> or Eclipse are using the Ant JUnitTask internally. I could never get
it
> work correctly without forking which I don't consider acceptable for
> embedding.

Just to be sure, I've printed the CL used. Here's the output:

Classloader = sun.misc.Launcher$AppClassLoader@e80a59

Also, you can notice in the code that I have:

// Do not fork so that we use the same classpath that was used to
// start this class.
junit.setFork(false);

oh... I think I know what could be your problem. I'm running with Ant
1.5.x and you must be using Ant 1.6.x. I've just checked the
JUnitTask.java code and it seems the Ant team has added some CL code for
Ant 1.6 which is not present for Ant 1.5.x. Maybe that's causing the
problem. I don't know why they did this. I'll ask.

[snip]

-Vincent



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 15:03, Vincent Massol wrote:

> funnily, I'm running the JUnit task in embedded mode for the abbot
> plugin I've checked in a few days ago and .... believe it or not... it
> works :-)
> 
> Here's the url: http://tinyurl.com/2uy9b (look at the
> executeAntJunitTestRunner method).

You are running that outside the context of an AntClassLoader? I think
our notions of embedding are different i.e. I doubt something like IDEA
or Eclipse are using the Ant JUnitTask internally. I could never get it
work correctly without forking which I don't consider acceptable for
embedding.

> [snip]
> 
> Anyway, let's stop the words and let's wait for some action! I'll start
> working on some java plugin as a proof of concept when I get back from
> TSSS2004.

I'm not going to stop you from writing plugins in any form you like, as
I said they just won't be part of the core if they depend on Ant.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 03 May 2004 17:11
> To: Maven Users List
> Subject: RE: [maven2] Anything Groovy in Maven2?
> 
> On Mon, 2004-05-03 at 10:00, Vincent Massol wrote:
> 
> > True. But that's my point: there's no voodoo if you reuse Ant tasks
only
> > (without reusing the Ant engine).
> 
> Try the JUnit task or the style task and see if that holds true. It
> doesn't and I know because I've tried. The surefire plugin I've
checked
> is was the only way I could get Junit tests to run in an embedded
> environment.
> 

funnily, I'm running the JUnit task in embedded mode for the abbot
plugin I've checked in a few days ago and .... believe it or not... it
works :-)

Here's the url: http://tinyurl.com/2uy9b (look at the
executeAntJunitTestRunner method).

[snip]

Anyway, let's stop the words and let's wait for some action! I'll start
working on some java plugin as a proof of concept when I get back from
TSSS2004.

Thanks
-Vincent



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> wrote on 04/05/2004 02:29:27 PM:

[snip]

> Read what was written, it is the POJO. The Plugin, AbstractPlugin,
> PluginExecutionRequest and PluginExecutionResponse are the 3k of
> dependencies mentioned in the previous email. The PluginExecutionRequest
> still have a reference to the core but not required except in one place.
> This is why the number of plugins has remained constant while these last
> bits are worked out.

I understand all that. I just think you're falling into the same trap as 
Ant did.

Why should the delete functionality be tied to these dependencies? It 
really doesn't need to be. 
The plugin should simply call code that has nothing to do with Maven. 
Stick the delete method into FileUtils or something.

Is this unclear or something?

Wouldn't it be easier to back port these to maven1, for example, if the 
code wasn't tied to Plugin class?

> > So 4 out of 7 look ok. If Maven2 is supposed to fix the issues that 
> > cropped up in Maven1, we really need to do it right from the outset.
> 
> I'm not sure what issues you're referring to.

Reusability of code. Readable code. Magic-less code.

--
dIon

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 22:55, dion_gillard@multitask.com.au wrote:
> Jason van Zyl <jv...@maven.org> wrote on 04/05/2004 12:17:13 PM:
> 
> [snip good stuff]
> 
> > 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 )
> 
> I must be seeing things then.

More likely you don't fully comprehend what's there or what it does
exactly, but that's why we're having this discussion.

> I had looked at the code already. 
> CleanPlugin extends AbstractPlugin, and doesn't wrap a POJO from what I 
> can tell. It does all the deleting itself.

Read what was written, it is the POJO. The Plugin, AbstractPlugin,
PluginExecutionRequest and PluginExecutionResponse are the 3k of
dependencies mentioned in the previous email. The PluginExecutionRequest
still have a reference to the core but not required except in one place.
This is why the number of plugins has remained constant while these last
bits are worked out.

> So 4 out of 7 look ok. If Maven2 is supposed to fix the issues that 
> cropped up in Maven1, we really need to do it right from the outset.

I'm not sure what issues you're referring to.

> Maybe they could be run without plexus or maven, but they're not really 
> reusable without the plugin setup code in a couple of cases. We should 
> draw the line.

They are all usable without Maven at all. You can create a Map of
parameters for any of them and use them stand-alone. All the plugin
configuration mechanism does is extract the values from the POM and make
the Map from those values. Whether the Map is generated from within
maven or from some other mechanism it doesn't matter.

Also note some of the plugins do use Plexus components, like the
compiler plugin, and it is still usable as a POJO. We are using that
strategy for Wagon and SCM to make a POJO facade essentially over a set
of components. So what the user ends up using is something like:

WagonManager wagonManager = new WagonManager();

And all the plexus goop is hidden. This doesn't really matter inside
maven2 as it is a plexus application but reuse namely in the form of
real embeddability is something I've considered for a long time.

The Mevenide folks are helping with embeddabiltity of maven2 itself by
integrating it into their tools and Trygve is doing the same with maven2
in Continuum. Wagon and Maven SCM are also serving as use cases for
Plexus components that can be used as POJOs and Ant tasks as well. So
there is excellent coverage for the testing of embeddability. But it's
an iterative process and not something you're going to "up front" but
the system has to be past a threshold in order to be able to make
iterative changes that are effective and using something like plexus
makes this possible.

> > What you are thinking of as most sensible is in fact exactly what I'm
> > doing.
> 
> In part, yes. I still think the line's been crossed in a few cases.

There's nothing that can ever be done about that. No design is ever
going to be adequate to begin with. But there are already 4 or 5 people
who understand what's there which is already better than what we have
with maven1 and those numbers will only improve in favour of the newer
code.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> wrote on 04/05/2004 12:17:13 PM:

[snip good stuff]

> 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 )

I must be seeing things then.

I had looked at the code already. 
CleanPlugin extends AbstractPlugin, and doesn't wrap a POJO from what I 
can tell. It does all the deleting itself.
CompilerPlugin extends AbstractPlugin is close to a wrapper but it does 
checks that I would expect the POJO to do, like checking the source 
directory exists.
JarPlugin is a POJO
ResourcesPlugin is a POJO
SCMPlugin is a POJO
SurefirePlugin is a POJO
XdocPlugin is implements the Plugin interface and does things I'd expect 
the POJO to do, e.g. copy images, stylesheets and add items to the Nav 
bar.

So 4 out of 7 look ok. If Maven2 is supposed to fix the issues that 
cropped up in Maven1, we really need to do it right from the outset.

> 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.

Maybe they could be run without plexus or maven, but they're not really 
reusable without the plugin setup code in a couple of cases. We should 
draw the line.

> What you are thinking of as most sensible is in fact exactly what I'm
> doing.

In part, yes. I still think the line's been crossed in a few cases.
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 21:46, dion_gillard@multitask.com.au wrote:
> Jason van Zyl <jv...@maven.org> 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
jason@maven.org
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 4 May 2004, Vincent Massol <vm...@pivolis.com> wrote:

> I've talked to Stefan and he's very open to work with us,

he is 8-)  And he's been subscribed to maven-dev for many months.

> - lifecycle IF (that can be solved easily by saying all tasks are
> thread safe)

This should be true for Ant tasks since they could get nested into
<parallel>s, but I wouldn't bet on it.  The way <parallel> works in
Ant, you'd still have one task instance per thread which makes static
stuff the major concern in Ant.

> - classloading IF (that can be solved by having a
> setClassLoader(ClassLoader) as this IF already exists in the JDK

Probably the part that would require most changes inside Ant if you
want to reuse tasks as a whole.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 04/05/2004 04:53:29 PM:

> Hmmm.... I think we need to talk more about this and involve the Ant
> team in the discussion as we need their help anyway. I'd prefer it to be
> in the Ant codebase (provided they are ok - If not I agree it could be
> done in Maven code base or elsewhere).

That works ok for me.

[snip]
> I've started a discussion on the Ant ML which is ATM geared towards
> reusing the JUnit Task in embedded mode.

Whereabouts?

> > 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.
Yep.
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: dion_gillard@multitask.com.au
[mailto:dion_gillard@multitask.com.au]
> Sent: 04 May 2004 08:34
> To: Maven Developers List
> Subject: RE: [maven2] Anything Groovy in Maven2?
> 
> "Vincent Massol" <vm...@pivolis.com> wrote on 04/05/2004 04:14:03
PM:
> 
> > Several things:
> > - when you talk about "refactoring out", do you mean refactor out
within
> > the Ant project or copy-paste the code somewhere else?
> 
> Initially into the Maven code base. But later on, sharing with Ant
would
> be a goal.

Hmmm.... I think we need to talk more about this and involve the Ant
team in the discussion as we need their help anyway. I'd prefer it to be
in the Ant codebase (provided they are ok - If not I agree it could be
done in Maven code base or elsewhere).

> 
> > - Refactoring out is not that easy (but possible) as the Ant tasks
are
> > quite linked to the Project class.
> 
> Yes, I think we'd both need to work on that. Ant and Maven.

Definitely.

> 
> > - 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.
> 
> Common code for use anywhere. If we worked together with Ant on a case
by
> case basis, and made the code we do write easily reusable, it would
make
> adoption by Ant a lot easier.

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.

> 
> > 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.

-Vincent



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 04/05/2004 04:14:03 PM:

> Several things:
> - when you talk about "refactoring out", do you mean refactor out within
> the Ant project or copy-paste the code somewhere else?

Initially into the Maven code base. But later on, sharing with Ant would 
be a goal.

> - Refactoring out is not that easy (but possible) as the Ant tasks are
> quite linked to the Project class.

Yes, I think we'd both need to work on that. Ant and Maven.

> - 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.

Common code for use anywhere. If we worked together with Ant on a case by 
case basis, and made the code we do write easily reusable, it would make 
adoption by Ant a lot easier.

> 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.

--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: 04 May 2004 07:55
> To: 'Maven Developers List'
> Subject: RE: [maven2] Anything Groovy in Maven2?
> 
> 
> 
> > -----Original Message-----
> > From: dion_gillard@multitask.com.au
> [mailto:dion_gillard@multitask.com.au]
> > Sent: 04 May 2004 03:47
> > To: dev@maven.apache.org
> > Subject: RE: [maven2] Anything Groovy in Maven2?
> >
> > Jason van Zyl <jv...@maven.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: dion_gillard@multitask.com.au
[mailto:dion_gillard@multitask.com.au]
> Sent: 04 May 2004 03:47
> To: dev@maven.apache.org
> Subject: RE: [maven2] Anything Groovy in Maven2?
> 
> Jason van Zyl <jv...@maven.org> 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.

Thanks
-Vincent



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> 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).
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 10:00, Vincent Massol wrote:

> True. But that's my point: there's no voodoo if you reuse Ant tasks only
> (without reusing the Ant engine). 

Try the JUnit task or the style task and see if that holds true. It
doesn't and I know because I've tried. The surefire plugin I've checked
is was the only way I could get Junit tests to run in an embedded
environment.

> I'm doing this in Cactus land and I
> can tell you I've never had to do any voodoo stuff. It's all plain,
> clean, easy. Now I admit that I may have been lucky and there may be
> cases more complex. But I'm positive we can solve them with the Ant
> team.

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.

> I've always taken ownership of whatever I've coded so of course I'll
> take ownership of whatever I code in the future too. Anyway, I'm not
> talking about developing a framework layer for plugins. I'm simply
> talking about reusing some Ant tasks from java plugin code.

I'm not going to stop you, but when you run into a classloading problem
that is a result of using an Ant task when you could have easily avoided
the whole problem by using a POJO and adapting it for different
environments I'm going to say "I told you so".

> I'll take the challenge of writing m2 plugins in java and reusing some
> Ant tasks. It won't impact any other plugin nor any architectural code.
> Just a standalone plugin.

That's fine, you can do whatever you like outside the core. But no core
plugins will depend on Ant.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 03 May 2004 15:23
> To: Maven Users List
> Subject: Re: [maven2] Anything Groovy in Maven2?
> 
> On Mon, 2004-05-03 at 07:36, dion_gillard@multitask.com.au wrote:
> 
> > If someone gave me the choice between 1 line of Ant and 164 lines of
> > custom Java code with throws Exception throughout and a whole load
of
> > empty catch blocks I know which I'd choose.
> 
> For anyone who wants to try to embed Ant that's your perogative. When
> you try it, which I'm sure you and Vincent want to you be responsible
> for all that entails. Up to this point you and Vincent have never been
> responsible for any of the Ant voodoo required to make Ant work in
> Maven.

True. But that's my point: there's no voodoo if you reuse Ant tasks only
(without reusing the Ant engine). I'm doing this in Cactus land and I
can tell you I've never had to do any voodoo stuff. It's all plain,
clean, easy. Now I admit that I may have been lucky and there may be
cases more complex. But I'm positive we can solve them with the Ant
team.

I've always taken ownership of whatever I've coded so of course I'll
take ownership of whatever I code in the future too. Anyway, I'm not
talking about developing a framework layer for plugins. I'm simply
talking about reusing some Ant tasks from java plugin code.

> 
> I've taken code from the commons, ant and other places in order to
> provide a small set of plugins that are self-contained, easy to test,
> easy to embed. The bottom line is that you've never done of the Ant
> integration and it's not fun and it's not productive.
> 
> That said I am working with James to extract the Ant embedding
solution
> that is present in groovy so that it can also be used in Maven. But my
> priority for plugins is clarity, economy of size, speed, having as few
> dependencies as possible, the ability to work in long-lived process,
the
> ability for plugins to communicate with each other during a long-lived
> process and code that reflects the simplicity provided by maven's
> directory structure. As far as the core goes, with it's plugins it
will
> be entirely free from Ant and Jelly. Ant just wasn't design well for
> embedding and the Jelly/Ant tag library is clear evidence of that as
is
> the groovy ant code.
> 
> There is nothing that would stop you from from using Ant code but you
> get the fun of integrating it and then we'll see how much you like it.


I'll take the challenge of writing m2 plugins in java and reusing some
Ant tasks. It won't impact any other plugin nor any architectural code.
Just a standalone plugin.

> I
> personally don't although I am in the process of extracting the ant
> groovy stuff for use in maven generally that can be used in a layer
> outside the core. If groovy is integrated into maven2 then we'll get
ant
> integration for free anyway. But a scripting option will be layered
upon
> the core which will be as small, fast as possible with as few
> dependencies as humanly possible.

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 07:36, dion_gillard@multitask.com.au wrote:

> If someone gave me the choice between 1 line of Ant and 164 lines of 
> custom Java code with throws Exception throughout and a whole load of 
> empty catch blocks I know which I'd choose.

For anyone who wants to try to embed Ant that's your perogative. When
you try it, which I'm sure you and Vincent want to you be responsible
for all that entails. Up to this point you and Vincent have never been
responsible for any of the Ant voodoo required to make Ant work in
Maven.

I've taken code from the commons, ant and other places in order to
provide a small set of plugins that are self-contained, easy to test,
easy to embed. The bottom line is that you've never done of the Ant
integration and it's not fun and it's not productive.

That said I am working with James to extract the Ant embedding solution
that is present in groovy so that it can also be used in Maven. But my
priority for plugins is clarity, economy of size, speed, having as few
dependencies as possible, the ability to work in long-lived process, the
ability for plugins to communicate with each other during a long-lived
process and code that reflects the simplicity provided by maven's
directory structure. As far as the core goes, with it's plugins it will
be entirely free from Ant and Jelly. Ant just wasn't design well for
embedding and the Jelly/Ant tag library is clear evidence of that as is
the groovy ant code.

There is nothing that would stop you from from using Ant code but you
get the fun of integrating it and then we'll see how much you like it. I
personally don't although I am in the process of extracting the ant
groovy stuff for use in maven generally that can be used in a layer
outside the core. If groovy is integrated into maven2 then we'll get ant
integration for free anyway. But a scripting option will be layered upon
the core which will be as small, fast as possible with as few
dependencies as humanly possible.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Trygve Laugstøl <tr...@student.matnat.uio.no> wrote on 03/05/2004 
08:43:15 PM:
[snip]
 
> I relly don't thinkt this is so bad. Most of the plugins are much more 
than
> one liners and as you can see the overhead for each file here is 4 
lines.

4 lines, and it's not as functional. The Maven2 clean plugin is over 100 
lines of java. The jelly version is just over 10. We're talking orders of 
magnitude more code, and the Ant codebase is well tested, as evidenced by 
the copying of bizarre code from it into Maven2.

> On the upside the plugins will be much easier to test and will run fast 
as
> hell.

Definitely, but this doesn't help people write them first time. 

> There are quite a bit of very good file handing methods in commons-io 
but
> I totally agree with you. We might wan't to create a maven-plugin-utils
> library for making plugin development easier.

commons-io is painfully thin on the sort of code you could use in a build 
tool. And plexus FileUtils is pretty much just a copy of Ant's code.

Take the jar plugin in Maven2. It's 164 lines of java code. 
Compare it to the one in Maven1. It's 295 lines of Jelly.

The Maven2 plugin simply creates a jar file of the current directory 
excluding package.html files. It is functionally equivalent to

<jar destfile="${outputDirectory}/${jarName}.jar" basedir="${basedir}" 
excludes="**/package.html"/>

For the extra 131 lines of code in the Maven1 plugin, you get an 
incredible amount more including goals to deploy the artifact (deploy, 
deploy-snapshot, install, install-snapshot) and a whole lot of 
customisation. Let's compare apples to apples.

If someone gave me the choice between 1 line of Ant and 164 lines of 
custom Java code with throws Exception throughout and a whole load of 
empty catch blocks I know which I'd choose.
--
dIon

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Trygve Laugstøl <tr...@student.matnat.uio.no>.
On Mon, 3 May 2004 14:06:27 +1000, <di...@multitask.com.au> wrote:

> Jason van Zyl <jv...@maven.org> wrote on 03/05/2004 01:03:57 PM:
>
>> On Sun, 2004-05-02 at 21:10, dion_gillard@multitask.com.au wrote:
>>
>>> Given the vast amount of ant build scripts out there, there must be a
>>> few.
>>
>> Yes, but that's a result of there never being a choice. If someone had
>> made a build tool using something like beanshell during the time ant was
>> becoming popular I do wonder what the population of XML build files
>> would be. Maybe a lot, maybe not. I'm used to them now as I've been
>> exposed to them for quite a while like most but it doesn't mean they are
>> optimal or ideal.
>
> Another thing to consider is the IO model for Ant is a lot less verbose
> than plain Java.
>
> Groovy is a step ahead in this regard, but still standard Java is very
> verbose and a large effort compared to a build snippet to do copies,
> moves, xml transforms on multiple files.
>
> Compare:
> -----ant approach----
> <project>
> <delete dir="${maven.build.dir}"/>
> </project>
>
> ant
> -----ant approach----
>
> with
> ----- java approach----
>
> public class Clean {
>         public static void main(String[] args)
>         {
>                 new java.io.File(args[0]).delete();
>         }
> }
> javac Clean.java
> java Clean target
> -----java approach----

I relly don't thinkt this is so bad. Most of the plugins are much more than
one liners and as you can see the overhead for each file here is 4 lines.

On the upside the plugins will be much easier to test and will run fast as
hell.

>
> ----- windows shell approach----
> rmdir target /q /s
> ----- windows shell approach----
>
> And the java approach doesn't handle simple stuff like deleting non-empty
> directories.
>
> The real issue is a lack of decent libraries for doing typical build
> tasks. If java-based plugins are to be a success, we'll need to beef up
> the existing libraries to handle common tasks.

There are quite a bit of very good file handing methods in commons-io but
I totally agree with you. We might wan't to create a maven-plugin-utils
library for making plugin development easier.

> --
> dIon Gillard, Multitask Consulting
>

-- 
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 17:39, dion_gillard@multitask.com.au wrote:
> Jason van Zyl <jv...@maven.org> wrote on 03/05/2004 11:27:06 PM:

> Will Groovy end up as an unmaintained project like Jelly has?

Unlikely now that it has been accepted as a JSR. But if we're going to
pick an Ant bridge to maintain the one in Groovy right now is in better
shape. As it stands now Mauro Televi and myself are going to take the
AntBuilder and extract it from groovy so hopefully in that form it can
be used within Groovy and we can wrap it for use in maven1 which means
we'll have updated Ant support. And we can also use it in maven2 which
is also good.

> --
> dIon Gillard, Multitask Consulting
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> wrote on 03/05/2004 11:27:06 PM:

> On Mon, 2004-05-03 at 09:00, Incze Lajos wrote:
> 
> > That's why I would consider groovy, as it has an ant builder (almost 
the
> > same way as jelly has)

Will Groovy end up as an unmaintained project like Jelly has?
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-05-03 at 09:00, Incze Lajos wrote:

> That's why I would consider groovy, as it has an ant builder (almost the
> same way as jelly has)

Not quite but that is exactly piece I'm extract with some advice from
Strachan. Once free from groovy dependencies it can be used in groovy
obviously, but also in Maven. It could be given back to Ant to make
embedding much more simple. 

Clear evidence of embedding problems is the fact that most IDEs that I
have seen the Ant integration for resort to executing Ant from the
command line because embedding Ant is like pulling out your own teeth
with pliers. If anyone wants to witness the fun take a look at the
AntBuilder in groovy: not many folks would have been able to write that
beast. Hopefully we can benefit from what Strachan went through writing
it and reuse it.

> , has decent xml processing and building tools (anyway,
> the same guy stands behind it as behind jelly, and many ideas were
> transferred) + it's a compilable, interpretable, embeddable terse language.
> 
> The main drawback for me was that it is in a state of the continous flux.

I'll take the AntBuilder for now! :-)

> incze
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Incze Lajos <in...@mail.matav.hu>.
> > Yep, and that's what Ant is trying to remedy (IMO). Thus it makes sense
> > to me to reuse Ant task from our java plugin.
> > 
> > Yes, I know, I'm repeating myself... ;-)
> > 
> > I've had Jason's opinion on this idea of reusing Ant tasks from our java
> > plugin but not other's. What do you think guys?
> 
> I think it's a viable alternative.
> 
> I can't see how the current set of Maven2 plugins is an advantage, for all 
> the speed and testability on offer you have to balance that against the 
> effort required to make it user friendly.
> 
> There are lots of issues Ant covers well I don't think we've even begun to 
> look at.

That's why I would consider groovy, as it has an ant builder (almost the
same way as jelly has), has decent xml processing and building tools (anyway,
the same guy stands behind it as behind jelly, and many ideas were
transferred) + it's a compilable, interpretable, embeddable terse language.

The main drawback for me was that it is in a state of the continous flux.

incze

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 03/05/2004 09:12:42 PM:

> 
> 
> > -----Original Message-----
> > From: dion_gillard@multitask.com.au
> [mailto:dion_gillard@multitask.com.au]
> > Sent: 03 May 2004 06:06
> > To: Maven Users List
> > Subject: Re: [maven2] Anything Groovy in Maven2?
> > 
> 
> [snip]
> > 
> > And the java approach doesn't handle simple stuff like deleting
> non-empty
> > directories.
> > 
> > The real issue is a lack of decent libraries for doing typical build
> > tasks. If java-based plugins are to be a success, we'll need to beef
> up
> > the existing libraries to handle common tasks.
> 
> Yep, and that's what Ant is trying to remedy (IMO). Thus it makes sense
> to me to reuse Ant task from our java plugin.
> 
> Yes, I know, I'm repeating myself... ;-)
> 
> I've had Jason's opinion on this idea of reusing Ant tasks from our java
> plugin but not other's. What do you think guys?

I think it's a viable alternative.

I can't see how the current set of Maven2 plugins is an advantage, for all 
the speed and testability on offer you have to balance that against the 
effort required to make it user friendly.

There are lots of issues Ant covers well I don't think we've even begun to 
look at.
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [maven2] Anything Groovy in Maven2?

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: dion_gillard@multitask.com.au
[mailto:dion_gillard@multitask.com.au]
> Sent: 03 May 2004 06:06
> To: Maven Users List
> Subject: Re: [maven2] Anything Groovy in Maven2?
> 

[snip]
> 
> And the java approach doesn't handle simple stuff like deleting
non-empty
> directories.
> 
> The real issue is a lack of decent libraries for doing typical build
> tasks. If java-based plugins are to be a success, we'll need to beef
up
> the existing libraries to handle common tasks.

Yep, and that's what Ant is trying to remedy (IMO). Thus it makes sense
to me to reuse Ant task from our java plugin.

Yes, I know, I'm repeating myself... ;-)

I've had Jason's opinion on this idea of reusing Ant tasks from our java
plugin but not other's. What do you think guys?

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> wrote on 03/05/2004 01:03:57 PM:

> On Sun, 2004-05-02 at 21:10, dion_gillard@multitask.com.au wrote:
> 
> > Given the vast amount of ant build scripts out there, there must be a 
few.
> 
> Yes, but that's a result of there never being a choice. If someone had
> made a build tool using something like beanshell during the time ant was
> becoming popular I do wonder what the population of XML build files
> would be. Maybe a lot, maybe not. I'm used to them now as I've been
> exposed to them for quite a while like most but it doesn't mean they are
> optimal or ideal.

Another thing to consider is the IO model for Ant is a lot less verbose 
than plain Java.

Groovy is a step ahead in this regard, but still standard Java is very 
verbose and a large effort compared to a build snippet to do copies, 
moves, xml transforms on multiple files.

Compare:
-----ant approach----
<project>
<delete dir="${maven.build.dir}"/>
</project>

ant
-----ant approach----

with
----- java approach----

public class Clean {
        public static void main(String[] args)
        {
                new java.io.File(args[0]).delete();
        }
}
javac Clean.java
java Clean target
-----java approach----

----- windows shell approach----
rmdir target /q /s
----- windows shell approach----

And the java approach doesn't handle simple stuff like deleting non-empty 
directories.

The real issue is a lack of decent libraries for doing typical build 
tasks. If java-based plugins are to be a success, we'll need to beef up 
the existing libraries to handle common tasks.
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-05-02 at 21:10, dion_gillard@multitask.com.au wrote:

> Given the vast amount of ant build scripts out there, there must be a few.

Yes, but that's a result of there never being a choice. If someone had
made a build tool using something like beanshell during the time ant was
becoming popular I do wonder what the population of XML build files
would be. Maybe a lot, maybe not. I'm used to them now as I've been
exposed to them for quite a while like most but it doesn't mean they are
optimal or ideal.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> wrote on 03/05/2004 10:48:22 AM:

> On Sun, 2004-05-02 at 18:43, Alex Karasulu wrote:
> > Hiya,
> > 
> > Was just wondering if there were any ideas regarding the use of Groovy 

> > with maven2 or is scripting totally out of the picture? 
> > 
> > I'm especially fond of any language that pays its respects to the 
> > mighty GString :-).
> 
> A plugin in maven2 can be anything that there is plexus component
> factory for which pure java is obviously a choice along with these:
> 
> http://cvs.plexus.codehaus.org/plexus/plexus-component-factories/
> 
> So, yes, plugins in maven2 could be written in Groovy. It's not a
> technical limitation it's more a matter of deciding what we promote.
> It's something that will be addressed in user surveys for maven2. I'm
> curious to see how many people actually like xml scripting.

Given the vast amount of ant build scripts out there, there must be a few.
--
dIon Gillard, Multitask Consulting


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [maven2] Anything Groovy in Maven2?

Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-05-02 at 18:43, Alex Karasulu wrote:
> Hiya,
> 
> Was just wondering if there were any ideas regarding the use of Groovy 
> with maven2 or is scripting totally out of the picture? 
> 
> I'm especially fond of any language that pays its respects to the 
> mighty GString :-).

A plugin in maven2 can be anything that there is plexus component
factory for which pure java is obviously a choice along with these:

http://cvs.plexus.codehaus.org/plexus/plexus-component-factories/

So, yes, plugins in maven2 could be written in Groovy. It's not a
technical limitation it's more a matter of deciding what we promote.
It's something that will be addressed in user surveys for maven2. I'm
curious to see how many people actually like xml scripting.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org