We've settled on Maven for managing new projects. However, we have an extensive set of existing Ant-based projects.
The thing about Maven is that it's best for new green field projects where you can shape your approach to the way Maven likes to do things. That's the best way to have success with Maven. However, for existing Ant projects, it can sometimes be a formidible undertaking to adapt them to Maven's approach - and a time sink. So instead, I'm taking a different tact. We'll use the Maven Ant task to get Maven to manage our .jar library dependencies on behalf of our Ant build.xml project files. We'll therefore leave the ant build files pretty much as is - just modify them to use Maven pom.xml to get classpath definition for .jars and some basic directory definitions and such. Here are two links for a small experimental project involving ANTLR parser where I've melded Maven and Ant together in that manner: http://vossnet.org/build.xml http://vossnet.org/pom.xml We're also using Artifactory repository at our internal network as well. The declarations for that are dealt with in our $HOME/.m2/ settings.xml file (located in each developer's workstation - and build server - local Maven repository folder). We tried Ivy but gave it up. This approach is so far working out much better. The nice thing about have a pom.xml for all our projects (both new and legacy) is that I can easily do this: mvn eclipse:eclipse to generate the .project and .classpath files for the Eclipse IDE. We don't check these files into source control as we're a strictly IDE- agnostic shop. Every project must build from the command line (or Hudson plugin) via Ant or Maven (nothing pertaining to any IDE should ever be checked in per association with any project). So it's nice that it's very easy to get the IDE project files quickly and easily generated on the fly when they're needed. Course for pure Maven projects, one can then use the Maven plugins for either Eclipse or NetBeans, which includes browsing and searching repositories to associate dependencies when they're needed for the first time. On Nov 26, 3:29 am, Peter Andersen <[EMAIL PROTECTED]> wrote: > Phil I see a problem of mixing your build code with the production > codebase, > if you separate them the clean_db build code can be compiled (or fully > build - as it own project) before > it is needed in the test part of the production build. > > I know that you mostly compare rake and ant - but you also bring maven > into the picture. > Although ant and maven both use xml to specify the build, maven work > on a much higher abstractions level. > I just started using maven after years using ant - hopefully i do not > need to go back. > > I agree with Dick - If it was more flexible it was easier to work > with. > If it was possible the disable lifecycles directly from the pom - a > disabling of the install phase would had helped Dick with his big war > files. > The deploy plugin has such a skip property - the install plugin has > not - direct liftcycle control will make it possible to override > plugin behavior. > > It is ok that the build is defined in xml - as long as it is done at > the right abstraction level. > Scripting is ok - but it must not bring us back to defining all of the > "what to do" instead of "what to get" with standard layout, > conventions, and configuration. > > /peter > > On Nov 26, 4:08 am, "Mark Derricutt" <[EMAIL PROTECTED]> wrote: > > > Given this thread it'd be great if the posse could get Kelly O'Hair to > > talk about JMake: > > >http://blogs.sun.com/kto/entry/jmake_source_repository_formerly_called > > > "This was formerly called the javamake utility > > fromhttp://www.experimentalstuff.com/Technologies/JavaMake/index.html. > > This tool's functionality is analogous to the "smart checking" feature > > of Borland JBuilder or the dependency analysis feature of IBM Jikes. > > However, it is a command line tool that is not tied to any IDE, can be > > used with any Java compiler, and can run as a task in the popular Ant > > make system." > > > It'd be interesting to hear about, esp. with the ties to JBuilder. > > > On Wed, Nov 26, 2008 at 3:54 PM, Bill Robertson > > > <[EMAIL PROTECTED]> wrote: > > > > How is rake (dependency checking + ruby) better than make (dependency > > > checking + shell commands)? Or is rake more than that? I guess it > > > might be more portable. > > > > Did anybody watch the 50 in 50 talk? Were they comparing rake to JCL? > > > > On Nov 25, 12:39 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > > wrote: > > >> On Nov 24, 9:00 pm, Casper Bang <[EMAIL PROTECTED]> wrote: > > > >> > Why the requirement it be interpreted? > > > >> it makes it difficult to leverage the proejct code. If a build is > > >> compiled and it references existing code then the build won't compile > > >> until the existing code is compiled. I ran into this exact scenario > > >> with Gant. What I have to do is have two scripts, one that just > > >> compiles the code with no references to project code (just a compile > > >> task) and another build script that references the project code. > > > >> It's awkward and confusing.... > > > -- > > "It is easier to optimize correct code than to correct optimized > > code." -- Bill Harlan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
