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 16:56:25 GMT
On Mon, 24 Jun 2002 wrote:

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

If this is the case - I'm out of this discussion.

What I need is a build tool that does what gump does, but is easier to 
use. If Maven is not intended for that - I have no issue with it.

All I can do is wait for a tool that can do what I need, and then we can
discuss making that tool a standard for Commons ( or jakarta ) build.
Until this happens I'll stick with gump ( and maybe start contributing
to it, as Jon sugested ).


> > 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
> Work:
> Developers:
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message