You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Berin Loritsch <bl...@d-haven.org> on 2003/09/30 15:08:27 UTC
More constructive criticism
With ANT 1.6 on the horrizon, it appears that there are some new issues
to worry about. For instance, the general impression that Maven is good
to you if you are good to Maven:
http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168
My question comes in this form: How much difference is there between
a Maven 1.0 and the next generation Maven that fixes a bunch of the issues
we already have?
I mean, will the existing plugins work? Is the repository compatible?
If so, then I highly recommend the NG Maven sooner than later. If not,
what can be done to make the plugins compatible? What work needs to be
done in that respect?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by Berin Loritsch <bl...@d-haven.org>.
dion@multitask.com.au wrote:
> news <ne...@sea.gmane.org> wrote on 01/10/2003 01:18:56 AM:
>
>
>>dion@multitask.com.au wrote:
>
> [snip]
>
>>>Have you looked at how Maven produces it's installation/distribution?
>>
>>:) Remember, I am playing devil's advocate here. I will look at it, but
>
> the
>
>>point is that I *shouldn't* have to.
>
>
> Oh, I get it, Maven is the tool you use without any other samples.....
>
> I see the point overall. Make the hard things easier.
>
> It would really help if someone would help out on Jelly and Jexl.
Yep. And as a neophyte to the whole Jelly/Jexl world, I just don't know
enough to help out here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by di...@multitask.com.au.
news <ne...@sea.gmane.org> wrote on 01/10/2003 01:18:56 AM:
> dion@multitask.com.au wrote:
[snip]
> > Have you looked at how Maven produces it's installation/distribution?
>
> :) Remember, I am playing devil's advocate here. I will look at it, but
the
> point is that I *shouldn't* have to.
Oh, I get it, Maven is the tool you use without any other samples.....
I see the point overall. Make the hard things easier.
It would really help if someone would help out on Jelly and Jexl.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by Berin Loritsch <bl...@d-haven.org>.
dion@multitask.com.au wrote:
<snip/>
>
>
>> Also, getting started--esp. if you have several smaller projects that make up
>> one larger project is not very easy. For instance I have my GUIApp project
>> using Maven. It works great, and the reactor (once I got it working)does its
>> job. Unfortunately, getting the parent project to create a distribution with
>> the proper documentation and packaging isn't set up. I'm somewhat at a loss
>> how to do this.
>
>
> Have you looked at how Maven produces it's installation/distribution?
:) Remember, I am playing devil's advocate here. I will look at it, but the
point is that I *shouldn't* have to.
>> Conversely, with ANT, while it can be painful, it is obvious how to get things
>> done.
>
>
> It's also DEAD easy to write Maven plugins.
My experience is a bit different in this matter. The chief accomplice to this
issue is the lack of any meaningful documentation on Jelly. You sort of have to
"discover" how it is used and what is legal syntax.
The thing is that with the pre/post goal operations, I can easily enhance
existing behavior, but certain things required me to change an existing
plugin--which should be happily part of the Maven RC1 by now. Remember that it
depends on *what* you want to do. Easy things are easy, but hard things are
seemingly impossible.
In fact, the pre/post goal thing is part of the reason for the emergent
behavior that I described. You see, if I call guiapp:install-snapshot,
the JARs created with my GUIApp plugin will have the meta-info I wanted.
If I call the jar:install-snapshot, I won't get the meta-info I wanted,
even though I provide a <preGoal name="jar:install-snapshot"/> entry.
It took me a while to figure this out. Also, how do you keep certain
plugins from interacting with the build if you don't want them to? I imagine
that eventually we will have some plugins that conflict with one another.
>> I think the best thing that describes developing a Maven plugin, and trying to
>> make it work the way you want it to is "emergent behavior". In
>
> [snip]
>
> You mean something like
> http://wiki.codehaus.org/maven/HowToCreateYourFirstPlugIn2 is "emergent
> behaviour"? You and I have very different opinions on that one.
How many plugins are that braindead? Any plugin that defines pre/post
goals that modify the behavior of an installed plugin in some way classifies
as emergent behavior. It's not a dig, but it is reality.
>
>> As it is, Maven is very usable, and I like it alot. I also think it can be
>> improved to provide some level of predictability.
>
> Speak to me in words I can use to create issues :-)
:)
Some of it comes from the need for strategy docs. The simple case is
documented, but what about the more complex sub-project style projects?
There is little to help in that regard. Some of it comes from using a
scripting language that has no meaningful documentation so unless you have
been initiated you are in the dark.
Other issues come from the loose pre/post goal type of issues. Its a hard
balance to walk. On one hand a rigid definition of build stages will help
to provide standard interfaces for making parts of the build happen in very
predictable manners. On the other hand, defining that rigid set of
interfaces is not easy, and doesn't allow for some truly flexible solutions
we can do now. I really have no advice on this. All I can do is play
devil's advocate, or explain the points of difficulty I have had.
To be fair, this community has been very helpful to me, and it is home to
a group of top notch folks. It's alot easier to manage my projects with
Maven than plain ANT, and have a level of consistency with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by di...@multitask.com.au.
news <ne...@sea.gmane.org> wrote on 01/10/2003 12:36:12 AM:
[snip]
> Some projects want to use Forrest. There are a lot of features for
Forrest
> that are really nice--if you know how to use them. There has been some
work
> to simplify the forrest integration, but it seems that Maven dist and
deploy
> want to use the Maven format for XDocs and its own document system.
There
> is no support for integrating with the Forrest XDocs format, or having
the
> dist target use the Forrest plugin.
Someone could take the xdocs plugin and use what Vincent has committed as
a 'caller' plugin, and work out how to get forrest to place nice with
Maven. This is OSS, and unless there's an itch for someone, it doesn't
happen.
> I imagine that certain things like that can be componentized so that
when
> we call the xdocs build targets, it deferrs either to the Maven or the
Forrest
> integration plugin. That would be preferred. However, how to do that
seems
> like a pipe dream with current Maven. It's as if there needs to be
> a "document
> plugin interface" of sorts.
It's easy enough to do. It just takes time, effort, and someone who
understands Maven and Forrest.
> Also, getting started--esp. if you have several smaller projects that
make up
> one larger project is not very easy. For instance I have my GUIApp
project
> using Maven. It works great, and the reactor (once I got it working)
does its
> job. Unfortunately, getting the parent project to create a distribution
with
> the proper documentation and packaging isn't set up. I'm somewhat at a
loss
> how to do this.
Have you looked at how Maven produces it's installation/distribution?
> Conversely, with ANT, while it can be painful, it is obvious how to get
things
> done.
It's also DEAD easy to write Maven plugins.
> I think the best thing that describes developing a Maven plugin,
andtrying to
> make it work the way you want it to is "emergent behavior". In
[snip]
You mean something like
http://wiki.codehaus.org/maven/HowToCreateYourFirstPlugIn2
is "emergent behaviour"? You and I have very different opinions on that
one.
> As it is, Maven is very usable, and I like it alot. I also think it can
be
> improved to provide some level of predictability.
Speak to me in words I can use to create issues :-)
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by Berin Loritsch <bl...@d-haven.org>.
Hmmm. I'm leaving the original post in for reference, but if you don't mind
I'm going to play the devil's advocate for a second. Don't get me wrong, I
like Maven, and I use it.
Some projects want to use Forrest. There are a lot of features for Forrest
that are really nice--if you know how to use them. There has been some work
to simplify the forrest integration, but it seems that Maven dist and deploy
want to use the Maven format for XDocs and its own document system. There
is no support for integrating with the Forrest XDocs format, or having the
dist target use the Forrest plugin.
I imagine that certain things like that can be componentized so that when
we call the xdocs build targets, it deferrs either to the Maven or the Forrest
integration plugin. That would be preferred. However, how to do that seems
like a pipe dream with current Maven. It's as if there needs to be a "document
plugin interface" of sorts.
Also, getting started--esp. if you have several smaller projects that make up
one larger project is not very easy. For instance I have my GUIApp project
using Maven. It works great, and the reactor (once I got it working) does its
job. Unfortunately, getting the parent project to create a distribution with
the proper documentation and packaging isn't set up. I'm somewhat at a loss
how to do this.
Conversely, with ANT, while it can be painful, it is obvious how to get things
done.
I think the best thing that describes developing a Maven plugin, and trying to
make it work the way you want it to is "emergent behavior". In short, it is an
Artificial Intelligence phrase to describe the complex interactions between
agents that operate by very simple rules. For example, research has shown that
a set of robots given a specific set of rules set loose in a room to collect
a specific set of blocks interact in surprising ways, even cooperating in
very complex ways to get the job done.
That's fine and dandy if we are trying to write a first person shooter game,
but for a build system we want a certain level of predictability. I don't think
Maven has that--which is why we have posts like the one I listed here.
As it is, Maven is very usable, and I like it alot. I also think it can be
improved to provide some level of predictability.
Jason van Zyl wrote:
> On Tue, 2003-09-30 at 09:08, Berin Loritsch wrote:
>
>>With ANT 1.6 on the horrizon, it appears that there are some new issues
>>to worry about. For instance, the general impression that Maven is good
>>to you if you are good to Maven:
>>
>>http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168
>>
>>My question comes in this form: How much difference is there between
>>a Maven 1.0 and the next generation Maven that fixes a bunch of the issues
>>we already have?
>>
>>I mean, will the existing plugins work?
>
>
> Yes. The current Maven will essentially be a component of its own. That
> is not a problem. How well they will interact with new plugins I'm not
> sure yet. But A lot of the standard plugins will more than likely just
> be rewritten.
>
>
>>Is the repository compatible?
>
>
> Yes, it will be. No plans to change the base structure.
>
>
>>If so, then I highly recommend the NG Maven sooner than later.
>
>
> After 1.0 is released it will be a steam train toward the next version
> and will be covered thoroughly in a book Bob and I hope to write. Bob
> and I are meeting in Amsterdam this week to go over the outline and we
> are going to keep users informed the whole way along which means getting
> lots of input on the next version from users.
>
>
>>If not,
>>what can be done to make the plugins compatible? What work needs to be
>>done in that respect?
>
>
> Essentially the current version of Maven will work as a component.
> Really it means making this version an encapsulated bean which I did
> work toward and Brett is actually integrating that code. Once 1.0 is out
> there will be a deluge of information and the book will be the initial
> impetus and I hope the motivation to complete to end where the book
> arrives around the release of the next version.
>
>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2003-09-30 at 09:08, Berin Loritsch wrote:
> With ANT 1.6 on the horrizon, it appears that there are some new issues
> to worry about. For instance, the general impression that Maven is good
> to you if you are good to Maven:
>
> http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168
>
> My question comes in this form: How much difference is there between
> a Maven 1.0 and the next generation Maven that fixes a bunch of the issues
> we already have?
>
> I mean, will the existing plugins work?
Yes. The current Maven will essentially be a component of its own. That
is not a problem. How well they will interact with new plugins I'm not
sure yet. But A lot of the standard plugins will more than likely just
be rewritten.
> Is the repository compatible?
Yes, it will be. No plans to change the base structure.
> If so, then I highly recommend the NG Maven sooner than later.
After 1.0 is released it will be a steam train toward the next version
and will be covered thoroughly in a book Bob and I hope to write. Bob
and I are meeting in Amsterdam this week to go over the outline and we
are going to keep users informed the whole way along which means getting
lots of input on the next version from users.
> If not,
> what can be done to make the plugins compatible? What work needs to be
> done in that respect?
Essentially the current version of Maven will work as a component.
Really it means making this version an encapsulated bean which I did
work toward and Brett is actually integrating that code. Once 1.0 is out
there will be a deluge of information and the book will be the initial
impetus and I hope the motivation to complete to end where the book
arrives around the release of the next version.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: More constructive criticism
Posted by di...@multitask.com.au.
news <ne...@sea.gmane.org> wrote on 30/09/2003 11:08:27 PM:
> With ANT 1.6 on the horrizon, it appears that there are some new issues
> to worry about. For instance, the general impression that Maven is good
> to you if you are good to Maven:
>
>
http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168
I think it's early days for Maven yet, and most people know Ant. I'm not
surprise they all run back to Ant when things get difficult.
> My question comes in this form: How much difference is there between
> a Maven 1.0 and the next generation Maven that fixes a bunch of the
issues
> we already have?
>
> I mean, will the existing plugins work? Is the repository compatible?
Yes on both counts I believe.
> If so, then I highly recommend the NG Maven sooner than later. If not,
Talk to Jason about Maven NG.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: More constructive criticism
Posted by Eric Pugh <ep...@upstate.com>.
I feel like something that needs to be better explained is that Maven is Not
Ant.. I think people see Maven, like how easy all the plugins make it to
tie in really intestesting reporting etc.. But, what they don't realize is
that part of what makes all the various plugins play nice with each other is
that there is a real structure to how things go together.
That means that maven is more then just a collections of plugins. It is
also all the interdendencies between the various plugins. Which is why when
you run war:webapp, all your unit tests are run.
The freedom to do everything by hand that is present in Ant is not present
in Maven. But, at least for many of my projects, I don't want that
freedom.. I would rather have an easy to setup, stable, well understood
build system with lots of reporting versus something that can be everything
to everybody, but requires lots of knowledge of the build system internals..
Where (I feel) that Ant shines is when you are doing something very complex,
very custom, and you want to do it your way, not any other way.
Eric
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Berin Loritsch
> Sent: Tuesday, September 30, 2003 3:08 PM
> To: users@maven.apache.org
> Subject: More constructive criticism
>
>
> With ANT 1.6 on the horrizon, it appears that there are some
> new issues
> to worry about. For instance, the general impression that
> Maven is good
> to you if you are good to Maven:
>
> http://blogs.codehaus.org/people/kevin/archives/2003/09/21/ind
> ex.shtml#000168
>
> My question comes in this form: How much difference is there between
> a Maven 1.0 and the next generation Maven that fixes a bunch
> of the issues
> we already have?
>
> I mean, will the existing plugins work? Is the repository compatible?
>
> If so, then I highly recommend the NG Maven sooner than
> later. If not,
> what can be done to make the plugins compatible? What work
> needs to be
> done in that respect?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org