commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juozas Baliuka <bali...@mwm.lt>
Subject Re: unmavenising Commons projects
Date Mon, 24 Jun 2002 14:06:41 GMT

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>


Mime
View raw message