commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject RE: unmavenising Commons projects
Date Mon, 24 Jun 2002 16:37:18 GMT
Take a look at, for example, the util project, and the difference between
version 1.12 and 1.13 of the build.xml. That's a revolution.

It can't be built without maven. 

> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Monday, June 24, 2002 10:45 AM
> To: Jakarta Commons Developers List
> Subject: Re: unmavenising Commons projects
> 
> 
> Noone is trying to stage a revolution. Maven seamlessly works 
> on top of 
> ant.... I don't get the fear - where is it coming from, what 
> is it about?
> --
> dIon Gillard, Multitask Consulting
> Work:      http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
> 
> Juozas Baliuka <baliuka@mwm.lt> wrote on 06/25/2002 12:06:41 AM:
> 
> > 
> > Yes, sorry I was confused by this thread.
> >   It always happens with migration to new tools.
> >   I think our users will be confused too. We must find some way to 
> migrate 
> > without revolution.
> > 
> > At 23:56 2002.06.24 +1000, dion@multitask.com.au wrote:
> > >Maven does not remove build files or ant.
> > >--
> > >dIon Gillard, Multitask Consulting
> > >Work:      http://www.multitask.com.au
> > >Developers: http://adslgateway.multitask.com.au/developers
> > >
> > >
> > >
> > >Juozas Baliuka <baliuka@mwm.lt>
> > >06/24/02 06:27 PM
> > >Please respond to "Jakarta Commons Developers List"
> > >
> > >
> > >To
> > >"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
> > >"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > >cc
> > >
> > >bcc
> > >
> > >Subject
> > >Re: unmavenising Commons projects
> > >
> > >
> > >
> > >
> > >Hi,
> > >Found this about Maven and Ant.
> > >Maven: "Maven is a Java project management and project 
> comprehension
> > >tool."
> > >Ant:     "Apache Ant is a Java-based build tool."
> > >
> > >   It must not be problem to integrate "Maven + Ant", "Maven +
> > >ANY_BUILD_TOOL", "Ant + ANY_IDE_OR_project_management_TOOL".
> > >   It must be no problems for integration, Ant is already  
> integrated 
> with
> > >the most known tools.
> > >   Is it some political problems ?
> > >
> > >   I use a lot of tools some of them are "bad" and some 
> are "good", it 
> is
> > >not a problem to use a new one,
> > >   but I am not going to use it if it "replaces" Ant,  It 
> because Ant 
> is
> > >standard to build my projects.
> > >   I don't have a good project management tool and I see 
> Maven is this
> > >tool,
> > >   I like Maven, but I can't use it, if I will need to 
> remove my build 
> tool
> > >
> > >or it is impossible to build my project without project 
> management tool
> > >   and build code without documentation generator.
> > >
> > >   Do, I need to write build files myself for "mavenised" 
> projects, or 
> I
> > >*must* to download, install and read "How to" to build 
> some "util" ?
> > >   I think, I will write this "util" myself, if I can't 
> use standard 
> way to
> > >
> > >build it.
> > >
> > >
> > >
> > >
> > >At 16:50 2002.06.24 +1000, dion@multitask.com.au wrote:
> > >
> > >
> > > >costinm@covalent.net 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 'build.sh 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:      http://www.multitask.com.au
> > > >Developers: http://adslgateway.multitask.com.au/developers
> > > >
> > > >
> > > >
> > > >--
> > > >To unsubscribe, 
> > > e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > >For additional commands, e-mail: 
> > > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail: 
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail: 
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail: 
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message