Hi Anil,
Anil Saldhana wrote:
Scout 0.5 release will be done the way it is.
0.5?
But your trunk/etc/project.xml already says
<currentVersion>1.0-SNAPSHOT</currentVersion>
As a result Apache Geronimo and ObjectWeb JOnAS, as well as Red Hat
RHAPS and the JPackage.org RPM of Scout have all been labeled
1.0-SNAPSHOT (+date).
Going back to anything less then 1.0 now will break everybody's
dependency checks.
Can't you continue to use 1.0-SNAPSHOT until you are ready for 1.0?
Once we add the asynchronous feature required by the
JAXR 1.0 spec, we will do the Scout 1.0 release.
Before we do the 1.0 release, we can see if there is
really any major incentive in removing the juddi data
types and bringing in XMLBeans.
A major incentive: not bringing the juddi jar into the classloader space
of anyone who wants to use Scout, perhaps even with some other Directory
service different from jUDDI.
I was talking to Guillaume on irc and we think that a complete
separation between Scout and jUDDI would be ideal.
At Scout and jUDDI, we have always fostered pluggable
deployments.
But in this specific case, there doesn't seem to be any advantage at all
in providing pluggable _internal_ types.
Using juddi data types is an internal implementation
detail of Scout. So there are no issues with using
XMLBeans as an internal implementation detail. But we
need to investigate and test.
Right. We would be willing to help changing the types if everyone is in
accordance with that.
I will have to look at XMLBeans a bit further.
Thank you.
Best regards,
Fernando
--- Fernando Nasser <[EMAIL PROTECTED]> wrote:
Davanum Srinivas wrote:
Fernando,
then folks who primarily use juddi and want to use
scout on the client
will have one less library to deal with :)
Are you saying that you agree with using XMLBeans
and dropping the jUDDI
types (on both sides, Scout and jUDDI of course)?
-- dims
On 8/17/05, Fernando Nasser <[EMAIL PROTECTED]>
wrote:
Dims,
I may be missing something because I don't know
all the details, so
please forgive me if it is a silly question.
If we have APL more or less standard types from
Apache XMLBeans, why do
we need to have the option of using jUDDI own
types?
Why not just drop the non-standard jUDDI types and
plainly switch
everything to use XMLBeans only ( a "de facto"
standard)?
Best regards,
Fernando
Davanum Srinivas wrote:
As long as it's pluggable (use XMLBeans OR
jUDDI), Am ok.
thanks,
dims
On 8/12/05, Guillaume Sauthier
<[EMAIL PROTECTED]> wrote:
Hi guys
We want to integrate Scout in JOnAS as a
replacement for the JAXR
Reference Implementation.
With Scout we can get ride of JAXB-RI too (used
by JAXR-RI) and use OSS :)
Scout has been very easily embed in JOnAS as a
ResourceAdapter and seems
to work very well, thanks to your hard work: )
We can see that Scout depends on jUDDI, and
jUDDI depends on many
jakarta commons libs.
Given the JOnAS ClassLoader architecture, the
Scout RA (and all
depending libs : scout, juddi, common-*, ...)
will be loaded in a
'commons' ClassLoader, this is a top level
Loader.
So, if a user package his/her application/webapp
with a lib already
provided by JOnAS (version can differ) there can
be a conflict!
More, if a user want to change the jUDDI
(webapp) version, he can't do
that (classes in top level loader are always
loaded first) !
As we want to interfere a minimum with the
classes packaged in our
user's application, in order to avoid conflicts,
we want to remove the
dependency on jUDDI.
To do this, we will have to rewrite some kind of
RegistryProxy, avoid
the use of jUDDI's handlers and datatypes, ...
We thought to use xmlbeans as a replacement for
UDDI datatypes
I want to know what do you think of this
proposal ?
I think it can be useful for geronimo guys too
(and for the same
classloader reasons).
Regards
Guillaume
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
