axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: cvs commit: xml-axis/java/test/wsdl Wsdl2javaAntTask.java
Date Fri, 23 Aug 2002 18:28:12 GMT

----- Original Message -----
From: "Matt Seibert" <mseibert@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Friday, August 23, 2002 6:55 AM
Subject: Re: cvs commit: xml-axis/java/test/wsdl Wsdl2javaAntTask.java


>
> Steve,
>
> Let me know about moving wsdl2java into a tools\ant structure, as this
> would actually be a better place for test\functional\ant and test\foreach
> to live also......

this would be a good time to think about what is a good structure there.

1. have a tools dir under java
2. start with an ant subdir, leave options open for tools/xdoclet,
tools/taglib, whatever people add
3. each tool builds its own jar, axis-ant.jar, axis-taglib.jar etc.
4. have build files, src and test subdirectories under each, so that they
have their own build and test processes.
5. What would be a good package naming scheme for code ?
org.apache.axis.tools.ant,  org.apache.axis.tools.taglib would seem OK.

I think we may want to keep the extra test tasks like foreach in the
sidelines, by requiring an explicit <typedef> to pull them in, even if they
are in the same jar. Rationale: they are more for axis internal dev than
external use, so we can change them as needed, and we dont want name clash
with ant-contrib <foreach>

The ant task migration needs

-a properties file to declare the tasks with their new names axis-java2wsdl,
axis-wsdl2java, so they can run side-by-side with the old ones.

-change some of the default settings to be more end-user centric (like the
behavior to not fail on any error related to  a network URL)

-add some way to spec the namespace to package file

-xdoc generated documentation (more to the point, a build process to do this
automatically, maybe even in GUMP)

-unit tests (needs someone to tease out the jakarta-ant unit test classes
into their own jar). All we have now are uses of the task to verify it works
on correct parameters, not to explore behavior in the failure modes.

the buildTests.xml file could also be set up to use <available> to probe for
the ant jar, build it if needed,






Mime
View raw message