commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: unmavenising Commons projects
Date Mon, 24 Jun 2002 06:50:46 GMT wrote on 06/24/2002 04:27:34 PM:

> All I'm saying is that Gump proves it is technically possible to
> accomodate each project build file and style of tracking dependencies,
> without any pain on the projects themself.

Maven does not try to do what Gump does, i.e. use the existing build file
and add a new document to tell it how to run. It does something different.
It tries to remove the need for duplicate hand coded build files along with
a load of other stuff.

> Gump is hard to use and the implementations is very bad - but
> it _can_ build the entire jakarta without changing a single
> file or 'deprecating' ant build files.
So it should, that's it's goal.

> Nobody ever sugested that Gump would be used by a regular user -
> but I'm willing to wait for a easy to use tool that have the same
> power as gump.
> And if Maven can't do it - it's clearly not the tool for me, it
> doesn't solve my itches. And I don't think it's a right tool
> for commons.
What 'power' does Gump have? 'All' it does is run existing build files. If
that's your itch, you should stick to Gump. Maven is not what you need.

> Well, replacing the build.xml and the established conventions
> a project uses is not necesarily a 'value'. Gump may be ugly, but
> it provides a value - without most people even knowing about
> it.
Maven doesn't have to replace the existing build file. This is just your
bitch about how it was implemented in commons. In theory we could say the
same thing about ant 1.5 features moving into build files.

> All apache ( java ) projects are 'gump'-ised, and we just had to
> change some properties here and there.
What a load of it. I've had to produce the gump descriptor and
dependencies, track down bugs in Xerces, deprecations in JDOM and more.
This is not just change a few properties. I'm happy to do this, but please
don't tell me Gump comes at little cost. Maybe you've not had to do it.

> :-) I know how amazingly painfully it is, had few problems in tomcat. But

> it's a value we really need.
100% agreed.

> I think that too. But I have to accept that other people have different
> tastes and other projects have different needs.
> I usually use a wrapper or just gump - I'm not happy about that, but
> that's how things are.
That's not acceptable. Would you like me to -1 any changes on commons build
files that take them away from some standard? That would 'fix' the problem
and bring some consistency to the build files.

> Then why does it mess with the build.xml and the build process ?? When
> it can do builds and what gump does, we can discuss about using it
> to build commons components, tomcat, whatever.
This just shows your lack of understanding about what Maven is and how it
works. It doesn't *have* to mess with the build file, that's just how it
was implemented here.

> For all the other features  - if they are not too hard to use from a
> build.xml with ant and some taksdefs, I'll be happy to try and see them
> in commons and all jakarta projects.
Again, that's not the way Maven works. it's not just a collection of
Taskdefs. It's a set of build files that perform all the standard stuff
that happens in a project: jar, compile, test, javadoc, dist, docs,
deploy-site, send announcements etc.... They are very easy to use from a
build file with ant, they are effectively just targets to add to your
standard build file.

> Just don't try to present ant as 'legacy' and replace the build.xml
> and the conventions we use with something else.
Who is? Where has someone declared ant as 'legacy'? And please tell me
about the consistent conventions used across commons....

> I can't 'select' a build.xml format, and I don't think you or
> maven can, and I don't think it's even right.
Why not? Taglibs did....

> It is perfectly possible to use gump-like descriptors to wrap
> any possible build.xml style and provide a consistent behavior
> and build process. That's already proven.
And that's not the point of Maven. Why make people write build files when
the functionality they want is bog standard and has been written a million
times before. Maven reduces the friction of project startup by removing the
need to write all those targets yourself.

> Set some standard target names and rules in maven, and
> make build-maven.xml _wrap_ the original component's build.xml.
> Then users can call maven and have the consistent build.
That's what we already have, Costin. It's just that the person implementing
it here decided to replace rather than augment the existing build file.

> There is no standard way to write a makefile, and it'll never
> be. Build systems like RPM are just adapting to the build
> process, and so does gump. You can build almost any linux
> package with 'rpm -ba', and you can build any jakarta project
> with the gump's ' project-name'.
After 6 weeks worth of setting up gump maybe.

> I can't believe it's impossible to implement the gump features
> in a user-friendly way and with java instead of .bash. If Maven
> can't do it, we'll just have to wait for something else.
Maven != Gump for the thousandth time. Maven is not trying to be Gump. Man,
I sound like a broken record.

dIon Gillard, Multitask Consulting

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message