RE: [maven2] Anything Groovy in Maven2?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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