From my maven project.xml:1. Building axis from day to day becomes much easier. Dependencies are
taken
care of automatically by Maven.
which dependencies? wsdl & logging?
ant, bsf, castor, commons-discovery, commons-httpclient, commons-logging, commons-net, httpunit, jaf, jaxrpc, jimi, javax.jms, saaj, javamail, oro, servletapi, wsdl4j, xalan, and xml-security
As well as the sonicmq jms stuff....that I know zero about
By my count to build and test axis you need roughly 19 jars. Granted you configured some of these as optional, but you still need those 19 jars.
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.
The bad things:
- ugly site
- non xml format for docs: this means they can't be transformed or the style can't change with time
- no automatic javadoc and source cross-referencing that maven does
3. It will increase the number of people who are able to contribute to the
Axis
project.
not proven.
Nah, its not, but I will let you be the judge. If you think it hinders it or it doesn't improve things at all then Axis shouldn't use it.
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.
I'm not going to boycott because of your ant use.
Also,
- I think it would be easier to do testing with a better testing set up (see the bottom of the email)
- I would like to contribute to Axis and am working on familiarizing myself with it all. It is a large beast and SOAP is finicky. Part of the added benefit of messing with the build is familiarizing myself with it.
4. Decreased maintenance of the build.xml file(s)
the core build is low maintenance; testing is a diferent matter.
Yes core maintenance is low, so I think we are establishing that testing needs some work.
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?
It wouldn't, but it mandates that kind of coherent directory layout. As Sanjiva pointed out these directories can be moved - but there are consequences. At some point you will have to deal with those consequences. There is always the "Attic" :)
6. A better looking website.
Forrest.
Yup. Forrest can do it too. In fact, I believe I could even get forrest working with maven.. I also believe the documentation format is somewhat compatabile. Anyway, I volunteered to do xdocs, not 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
That is an alternative too.
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
Ok, be patient with me as I am new to the axis project and don't know all the historical ins and outs. How does the Websphere build process integrate with Axis that we need to worry about? Also, I do not follow what you mean by "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."
I understand that Maven is considered dangerous. So, now that I am becoming familiar with more of the Axis project I would think it should be considered after Maven hits 1.0 which should be approximately the same time that Axis hits 1.2.
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.
After playing with the tests I would tend to agree. These things would be great. However, it will be a week or so of playing/testing before I have more thoughts on this.
Regards,
- Dan
-- Dan Diephouse http://junktoast.com
