Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: <000501c25748$fb5ea1a0$3bba400c@lankabook2>
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: <axis-dev@xml.apache.org>
References: <3D783A1A.91AE4042@cs.indiana.edu>
Subject: Re: [wsif] first official WSIF release?
Date: Sat, 7 Sep 2002 18:06:36 +0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit

+1.

Sanjiva.

----- Original Message -----
From: "Aleksander Slominski" <aslom@cs.indiana.edu>
To: <axis-dev@xml.apache.org>
Cc: "Nirmal Mukhi" <nmukhi@us.ibm.com>; "Paul Fremantle" <pzf@uk.ibm.com>;
"Sanjiva Weerawarana" <sanjiva@us.ibm.com>
Sent: Friday, September 06, 2002 11:16 AM
Subject: [wsif] first official WSIF release?


> hi,
>
> 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
> http://www.alphaworks.ibm.com/tech/wsif ...). 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 Open3.org ...)
>
> I would like to hear comments and if it looks OK I would
> like to be release manager.
>
> Thanks,
>
> Alek
>
> 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
org.apache.wsif.util.*
> or org.apache.wsif.base.* ...)