commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject RE: unmavenising Commons projects
Date Mon, 24 Jun 2002 17:21:58 GMT
So talk to Jon who committed the changes.....

He didn't have to make the changes he did. He could have had a migration 
period there, but he didn't.

Why didn't you -1 his changes back on April 30? There has been almost 2 
months since this change was committed. You'd think someone would have 
noticed by now if they were actively developing without Maven installed.

Let me repeat it again, building with Maven doesn't mean giving up your 
existing build files *unless you want to*.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers

Steve Downey <steve.downey@netfolio.com> wrote on 06/25/2002 02:37:18 AM:

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


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