After investing quite a bit of time in a maven/ant solution to our build problems we have dropped maven. We found something new had broken every Monday (they seem to release new plugins on the weekend). We are still using it for downloads, but will probably stop that as will, as our repository is now in subversion.
The quality of the maven/eclipse code was simply not up to our standards, and we had a major problem with the lack of documentation. Our repository is still in maven2 format, and we are describing our dependencies in an attenuated pom. We will continue using these well-thought out parts of maven, but cannot afford to use the poorly tested code in our builds. Liz Sommers [EMAIL PROTECTED] -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 6:32 AM To: Ant Users List Subject: Re: Maven vs. Ant? Antoine Levy-Lambert wrote: > Hi, > > I am interested by this thread, as the project I am working for might need a tool able to manage inter-project dependencies and a repository. > > Has anyone compared maven and ivy ? And what about dpml ? > > Regards, > > Antoine > Antoine, the forthcoming second edition of Java Development with Ant will have a whole chapter on library management using the maven2 tasks, consuming stuff from the repository, producing stuff in there as a way of gluing stuff together. I will send you a draft chapter if you promise to correct all the mistakes :) Right now library management is something we have not built into Ant. For a few months there was some repository stuff in CVS, but I pulled it as I didnt have it right, and felt that people who knew what they were doing (maven2, ivy) could handle it better. I have many issues with the quality of the m2 poms, they often pull in too much stuff, stuff you end up having to exclude a lot of stuff you dont need, or you end up pulling around too much baggage. Here is my code to create a pom for a soap stack <target name="m2-make-pom" depends="m2-init" <echo message="Creating Pom ${target.pom}" level="verbose"/> <echoxml file="${target.pom}"> <project> <modelVersion>4.0.0</modelVersion> <groupId>${m2.groupID}</groupId> <artifactId>${artifact.name}</artifactId> <packaging>jar</packaging> <version>${Version}</version> <dependencies> <dependency> <groupId>commons-httpclient</groupId> <artifactId>commons-httpclient</artifactId> <version>${commons-httpclient.version}</version> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit</artifactId> </exclusion> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging-api</artifactId> <version>${commons-logging.version}</version> <dependency> <groupId>xerces</groupId> <artifactId>xercesImpl</artifactId> <version>${xerces.version}</version> </dependency> <dependency> <groupId>xerces</groupId> <artifactId>xmlParserAPIs</artifactId> <version>${xerces.version}</version> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging-api</artifactId> <version>${commons-logging.version}</version> </dependency> <dependency> <groupId>servletapi</groupId> <artifactId>servletapi</artifactId> <version>${servletapi.version}</version> </dependency> <dependency> <groupId>xom</groupId> <artifactId>xom</artifactId> <version>${xom.version}</version> <exclusions> <exclusion> <groupId>dom4j</groupId> <artifactId>dom4j</artifactId> </exclusion> <exclusion> <groupId>jdom</groupId> <artifactId>jdom</artifactId> </exclusion> <exclusion> <groupId>xalan</groupId> <artifactId>xalan</artifactId> </exclusion> <exclusion> <groupId>jaxme</groupId> <artifactId>jaxme</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project> </echoxml> </target> I save this to a file then use it in the m2 tasks and to publish the artifact itself. I am also not over-happy with the M2 ant tasks. They have the feel of a bit of an afterthought, so there are no unit tests, sometimes they ship broken (as in m2 2.0.1), and they are a bit clunky to use. Error messaging is particularly bad. The underlying cause is that they are a very thin wrapper around the maven wagon code, and not coupled that well to ant. Someone could sit down and make them much smoother, which is something I may have to do myself. In their defence, they do work, I use them not only to fetch stuff, but to publish things. And now that a lot of the sun jars have snuck over into the OSS repository from glassfish, you can even get mail.jar and activation.jar via the tasks. Property-driven library switching is nice indeed. If a new version of a library comes out, to test build against it you edit your build.properties, rebuild and retest, and, if happy, update the SCM-managed libraries.properties file. -steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ____________________________ http://www.pragmatics.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
