ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sommers, Elizabeth" <Somme...@Pragmatics.com>
Subject RE: Maven vs. Ant?
Date Tue, 13 Jun 2006 13:27:37 GMT

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
sommerse@pragmatics.com

-----Original Message-----
From: Steve Loughran [mailto:stevel@apache.org]
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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


____________________________ 
http://www.pragmatics.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message