----- Original Message ----- From: "Dan Diephouse" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 taken > 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 the > 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 it. 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 Axis > 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 awful. > It doesn't work an IDE like Eclipse at all. For example: the main code is in > src/java/package.name.here - however the tests are in src/package.name.here. > The tests should be in src/test/package.name.here..... 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 history? > > 6. A better looking website. Forrest. > > 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 axis > 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 jboss.net 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 way > 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 verification -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. -steve
