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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> >06/24/02 06:27 PM >Please respond to "Jakarta Commons Developers List" > > >To >"Jakarta Commons Developers List" <[EMAIL PROTECTED]>, >"Jakarta Commons Developers List" <[EMAIL PROTECTED]> >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, [EMAIL PROTECTED] wrote: > > > >[EMAIL PROTECTED] 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:[EMAIL PROTECTED]> > >For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
