You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2002/09/06 07:16:10 UTC
[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.* ...)
Re: [wsif] first official WSIF release?
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
+1.
Sanjiva.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@xml.apache.org>
Cc: "Nirmal Mukhi" <nm...@us.ibm.com>; "Paul Fremantle" <pz...@uk.ibm.com>;
"Sanjiva Weerawarana" <sa...@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.* ...)
Re: [wsif] first official WSIF release?
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@xml.apache.org>
Cc: "Nirmal Mukhi" <nm...@us.ibm.com>; "Paul Fremantle" <pz...@uk.ibm.com>;
"Sanjiva Weerawarana" <sa...@us.ibm.com>
Sent: Thursday, September 05, 2002 10:16 PM
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.
+1
> 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.
+1 to probing and printing out urls to where to get stuff. Some of the ant
container stuff (maven?) try and do this auto download.
> * 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.
+1 yes. The trouble with including your own stuff is that people send
bugreps to the suppliers of the original libraries who never have a clue
what version they are talking about (and never fix anything other than
CVS_HEAD)
> * updated/tested documentation for samples and tests
> that includes description of what is required to run
> each sample (including dependencies)
+1 docs are always good.
> * 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.)
That I'm unsure about. WSIF should always build with the latest full release
of ant and that is enough. Life gets very confusing with >1 copy of ant in
the system, especially on the path, and team ant often field problems with
'get rid of old copies', usually related to tomcat btw.
> * 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 have no idea.
> I would like to hear comments and if it looks OK I would
> like to be release manager.
+1. Never turn down anyone offering to be a release manager.
Re: [wsif] first official WSIF release?
Posted by Davanum Srinivas <di...@yahoo.com>.
Alek,
+1 for stepping up to the plate.
Thanks,
dims
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> 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.* ...)
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com