axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: Axis Build System - Possible conversion to Maven
Date Sun, 16 Mar 2003 07:25:15 GMT
Steve Loughran wrote:
>>1. Building axis from day to day becomes much easier.  Dependencies are
> taken
>>care of automatically by Maven.
> which dependencies? wsdl & logging?
 From my maven project.xml:

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
> 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.

- 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/ - however the tests are in
> src/
>>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
> 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
> 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.


- Dan

Dan Diephouse

View raw message