axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hughes" <>
Subject Re: [wsif] first official WSIF release?
Date Fri, 06 Sep 2002 15:09:17 GMT

Thanks for kicking this off. I would like to ask that we use 1.2.0 as the 
first version. This sounds strange so I'll explain. WSIF started in IBM 
(which I'm sure you know since you wrote some of it!) with version 1.0. It 
then went through another rev to v1.1 so rather than calling this first 
Apache version 1.0 (which would be confusing to those who've used older 
levels of WSIF when it was, I would like 1.2.0.

Also, JMS API is downloadable separately at (v1.0.2b)

You suggest including the Ant package, is that normal ... I have tended to 
just take the latest from the Ant site and use that across all projects 
that require Ant. I guess, for convenience it would be good, but will need 
maintenance whenever Ant upgrades.

In terms of your P.S. note. org.apache.wsif.* (no sub packages) should be 
all that is needed to use WSIF.

+1 to everything else.

Thanks again,

Aleksander Slominski <>
06/09/2002 06:16
Please respond to axis-dev

        To:     "" <>
        cc:     Nirmal Mukhi/Watson/IBM@IBMUS, Paul Fremantle/UK/IBM@IBMGB, Sanjiva 
        Subject:        [wsif] first official WSIF release?



as WSIF is now open source and it seems to be stable 
so it seems to be a good idea to get WSIF nicely packaged 
and released: providing code base that is well documented, 
tested and that can be built easily.

This would allow to remove confusion and essentially graduate/retire
WSIF from Alphaworks (there are still people sending questions to ...). A stable open
source release of WSIF will allow to close down Alphaworks WSIF
(and to have a link to the stable version on apache website).

So those are things that are needed in my opinion:

* build.xml that will work out of the box even if no libraries
for providers are available (axis, apache soap, JMS, ...)
and will print warning specifying what is needed.

That will require to split built process into separate tasks
that compiles first core WSIF and than separately each provider.
(to make sure that there is no dependency of WSIF core on
providers or optional libraries and between  providers)
We should also have ability to build WSIF core jar without 
any providers and then each provider as a separate jar file 
but this can be done later - first we need to get first 
release of WSIF out ...

* all jar files that are required (not optional) for WSIF should
be checked into CVS to allow to retrieve old versions of WSIF 
from CVS without need to checkout other dependent projects from past
(and try to build them and they may depend on other projects...)

I think that currently it is just: WSDL for Java API (WSDL4J),
and Apache Common Logging, essentially: 
wsdl4j.jar, qname.jar, commons-logging.jar, more?

* it would be nice to keep version numbers in jar files and
README files (in separate directory?) describing where jar files 
can be obtained and what is license.

* updated/tested documentation for samples and tests
that includes description of what is required to run
each sample (including dependencies)

* as of building: it would be very useful also to have ANT jar
and all dependent libraries needed to build WSIF checked in
- that should greatly improve user experience when working
with WSIF source code (instead of hunting for correct version of ANT etc.)

* finally: i am not sure if it is possible to provide just 
JMS API (very handy) without need to require users to 
get whole J2EE (maybe we could use some open source JMS
runtime for automatic tests such as ...)

I would like to hear comments and if it looks OK I would 
like to be release manager.



ps. I think that in longer term for WSIF success it is crucial
to separate public API from not exactly public but nonetheless
available utility classes. This will make easier to write user
code that uses WSIF without need to worry that some minor
changes in WSIF utility classes will break user code.

The ideal situation would be to define what is stable WSIF API 
that can be relied upon (such as WSIFOperation) and
what is just utility/support classes that are not part of official API
and should not be used in user code (such as classes in 
or org.apache.wsif.base.* ...)

View raw message