axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Axis Build System - Possible conversion to Maven
Date Fri, 14 Mar 2003 19:51:45 GMT

----- Original Message -----
From: "Dan Diephouse" <>
To: <>
Sent: Friday, March 14, 2003 13:00
Subject: Axis Build System - Possible conversion to Maven

> Since I have started working with Axis I have nothing but problems with
the ant
> build system.  It is very complicated as I'm sure you all know.  I would
like to
> propose that the Axis project move to Maven for the following reasons:
> 1. Building axis from day to day becomes much easier.  Dependencies are
> care of automatically by Maven.

which dependencies? wsdl & logging?

> 2. It is *very* easy to create a release, and then deploy a new version of
> website.  No more linking to docs in CVS.  To deploy a new version of the
> website you just do: "maven site:deploy".  That is really all there is too

The nice thing about linking to CVS and/or Gump created content
is that anyone can commit changes and have it propagate to the site.

> 3. It will increase the number of people who are able to contribute to the
> project.

not proven.

To increase contribs to the axis project we need.

-people willing to learn WSDL, JAX-RPC, JAX-M and SOAP specs,
then fix axis as appropriate
-people with their own 'itches' : discovery, management, performance
-better javadocs and docs to give people the confidence to edit the code
-a means of adding plug-ins to extend axis out the core
-build a community of people adding new 'handlers', a way of providing
self contained contribs to Axis
-easier and faster testing

Unless there is a pent up collection of maven users who boycott ant
projects, then I dont see that Maven brings all this.

> 4. Decreased maintenance of the build.xml file(s)

the core build is low maintenance; testing is a diferent matter.

> 5. A coherent directory structure.  Right now the directory structure is
>   It doesn't work an IDE like Eclipse at all.  For example: the main code
is in
> src/java/ - however the tests are in
> The tests should be in src/test/

This is not an ant fault, it is a historical defect of the structure. If
CVS could move directories and files without losing history, we'd have
done it.

How would moving to maven improve the dir structure without losing CVS

> 6. A better looking website.


> Anyway, I will volunteer to:
> 1. Convert the main build to maven.
> 2. Create component builds for the components that are deemed not
necessary for
> inclusion in the main build (jms, image, net)
> 3. Convert the existing documentation to XDocs.  This will create a nice
> web site for once.

What we really need is the core docs in a format (DocBook) that produces
good printable docs, so that people like IBM, Macromedia and
can include it in their docs. The web site should be created from dbk

> 4. Help anyone who needs helping getting familiar with maven.
> I have a working version that compiles all the main code, but am only part
> converting the tests.  Since there are so many tests and a lot of them
need work
> to convert to maven, I would like some input before I convert the build.
> Thoughts, questions?

I agree I need to look at maven. And Centipede. But dont want to move
Axis to it.

Axis is reused by many major projects, who integrate it into their
ant based builds. We had trouble moving from ant1.4 to ant1.5 because
the changes broke the websphere build process. For the same reason, we
dont add any post ant1.5.0 stuff to the build. Otherwise I'd replace the
XML entity inclusion with <import>, the <foreach> hackery with <subant>,
etc etc. But I wont, because people depend on ant 1.5 builds using axis
as a small component, and on IDEs (eclipse, IDEA, NetBeans) that
integrate with release versions of Ant.

Binding to Maven, that is in an earlier stage of evolution is
dangerous. Even for us we'll have the 'did axis break in gump, or is it
maven' discussion every morning.

One thing to look at in the Axis1.2 timeframe is the test system.

I have an uncommitted rework of test.xml that used better patterns to
provide an online/offline switch, but leakages in ant1.5.1 and sun.javac
kept it out. Even though ant1.6 fixes the leak in <exec>, I still cant
commit it, and now I am thinking of a better approach: glens.

We all need to sit down and design a better test framework, one with
-cached WSDL of various endpoints
-template based (velocity?) generation of test messages and response
-functional tests on tomcat, jetty, jboss
-functional tests against .net & other soap implementations, testing
stuff beyond what the soapbuilders test.

I dont think rewriting the test/**/build.xml to maven-land is the right
solution here. We need to be more revolutionary in test thinking -but
still run on ant1.5 for the sake of everyone.


View raw message