You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scout-dev@ws.apache.org by Deepak Bhole <db...@redhat.com> on 2006/01/10 23:02:39 UTC

Proposed plan for commit of juddi decoupling + ebxml support

Hi,

Now that I have commit access, I plan to commit my previous two patches
into the repository. Relevant messages are here:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1606

and

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1607

The former is a patch that removes juddi dependency from scout. 

The latter, adds ebxml support.

The issue is that the ebxml changes are extensive. They change ALL
package names in scout (previously, everything was under
org.apache.ws.scout.* . However, ebxml code is different, which required
separation into org.apache.ws.uddi.* (everything from org.apache.ws.*)
and org.apache.ws.ebxml.*.

Commit of the first patch won't break anything (hopefully :)). However,
once the second one is in, other applications that use scout classes
directly, will have to be updated to use the newer structure.

I was thinking of tagging the repository after the first patch is
committed (suggestions for tag name are welcome), after which I would
upload the second set of changes. If there are any
objections/suggestions on better ways to handle this, please let me
know.

Cheers,
Deepak


---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Fernando Nasser <fn...@redhat.com>.
Davanum Srinivas wrote:
> Deepak,
> 
> +1 to #1 patch. Not so sure about #2. Can you please explain a bit
> more why ebxmlrr support is desired/necessary?
> 

#2 is necessary so we have a level 1 JAXR client, i.e., so that we can 
access both UDDI and ebXML registries.

The ebxmlrr code that was imported is an open source JAXR provider for 
ebXML -- we have the UDDI provider already, of course.  (the "providers" 
are chosen by using the specific Factory in JAXR).

According to a Sun's J2EE Evangelist (Prof. Sang Shin), people are using 
both, including the most common case of using a UDDI registry to find 
the ebXML registry.  This was two years ago, of course, and before UDDI 3.

Cheers,
Fernando

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Davanum Srinivas <da...@gmail.com>.
Deepak,

+1 to #1 patch. Not so sure about #2. Can you please explain a bit
more why ebxmlrr support is desired/necessary?

thanks,
dims

On 1/10/06, Deepak Bhole <db...@redhat.com> wrote:
> Hi,
>
> Now that I have commit access, I plan to commit my previous two patches
> into the repository. Relevant messages are here:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1606
>
> and
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1607
>
> The former is a patch that removes juddi dependency from scout.
>
> The latter, adds ebxml support.
>
> The issue is that the ebxml changes are extensive. They change ALL
> package names in scout (previously, everything was under
> org.apache.ws.scout.* . However, ebxml code is different, which required
> separation into org.apache.ws.uddi.* (everything from org.apache.ws.*)
> and org.apache.ws.ebxml.*.
>
> Commit of the first patch won't break anything (hopefully :)). However,
> once the second one is in, other applications that use scout classes
> directly, will have to be updated to use the newer structure.
>
> I was thinking of tagging the repository after the first patch is
> committed (suggestions for tag name are welcome), after which I would
> upload the second set of changes. If there are any
> objections/suggestions on better ways to handle this, please let me
> know.
>
> Cheers,
> Deepak
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.
Read my other note - I don't care what's off in an experimental branch. 
  I thought the idea was to split our main codeline into two...

geir

Davanum Srinivas wrote:
> Geir,
> 
> could you please wait for the branch and then help with
> comments/suggest alternatives.
> 
> thanks,
> dims
> 
> On 1/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> 
>>
>>Deepak Bhole wrote:
>>
>>>Hi,
>>>
>>>Now that I have commit access, I plan to commit my previous two patches
>>>into the repository. Relevant messages are here:
>>>
>>>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1606
>>>
>>>and
>>>
>>>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1607
>>>
>>>The former is a patch that removes juddi dependency from scout.
>>>
>>>The latter, adds ebxml support.
>>>
>>>The issue is that the ebxml changes are extensive. They change ALL
>>>package names in scout (previously, everything was under
>>>org.apache.ws.scout.* . However, ebxml code is different, which required
>>>separation into org.apache.ws.uddi.* (everything from org.apache.ws.*)
>>>and org.apache.ws.ebxml.*.
>>
>>Why?
>>
>>
>>>Commit of the first patch won't break anything (hopefully :)). However,
>>>once the second one is in, other applications that use scout classes
>>>directly, will have to be updated to use the newer structure.
>>>
>>>I was thinking of tagging the repository after the first patch is
>>>committed (suggestions for tag name are welcome), after which I would
>>>upload the second set of changes. If there are any
>>>objections/suggestions on better ways to handle this, please let me
>>>know.
>>>
>>>Cheers,
>>>Deepak
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: scout-dev-help@ws.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: scout-dev-help@ws.apache.org
>>
>>
> 
> 
> 
> --
> Davanum Srinivas : http://wso2.com/blogs/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Davanum Srinivas <da...@gmail.com>.
Geir,

could you please wait for the branch and then help with
comments/suggest alternatives.

thanks,
dims

On 1/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Deepak Bhole wrote:
> > Hi,
> >
> > Now that I have commit access, I plan to commit my previous two patches
> > into the repository. Relevant messages are here:
> >
> > http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1606
> >
> > and
> >
> > http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1607
> >
> > The former is a patch that removes juddi dependency from scout.
> >
> > The latter, adds ebxml support.
> >
> > The issue is that the ebxml changes are extensive. They change ALL
> > package names in scout (previously, everything was under
> > org.apache.ws.scout.* . However, ebxml code is different, which required
> > separation into org.apache.ws.uddi.* (everything from org.apache.ws.*)
> > and org.apache.ws.ebxml.*.
>
> Why?
>
> >
> > Commit of the first patch won't break anything (hopefully :)). However,
> > once the second one is in, other applications that use scout classes
> > directly, will have to be updated to use the newer structure.
> >
> > I was thinking of tagging the repository after the first patch is
> > committed (suggestions for tag name are welcome), after which I would
> > upload the second set of changes. If there are any
> > objections/suggestions on better ways to handle this, please let me
> > know.
> >
> > Cheers,
> > Deepak
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: scout-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Deepak Bhole wrote:
> Hi,
> 
> Now that I have commit access, I plan to commit my previous two patches
> into the repository. Relevant messages are here:
> 
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1606
> 
> and
> 
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1607
> 
> The former is a patch that removes juddi dependency from scout. 
> 
> The latter, adds ebxml support.
> 
> The issue is that the ebxml changes are extensive. They change ALL
> package names in scout (previously, everything was under
> org.apache.ws.scout.* . However, ebxml code is different, which required
> separation into org.apache.ws.uddi.* (everything from org.apache.ws.*)
> and org.apache.ws.ebxml.*.

Why?

> 
> Commit of the first patch won't break anything (hopefully :)). However,
> once the second one is in, other applications that use scout classes
> directly, will have to be updated to use the newer structure.
> 
> I was thinking of tagging the repository after the first patch is
> committed (suggestions for tag name are welcome), after which I would
> upload the second set of changes. If there are any
> objections/suggestions on better ways to handle this, please let me
> know.
> 
> Cheers,
> Deepak
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Fernando Nasser <fn...@redhat.com>.
Anil Saldhana wrote:

> 2) Bringing in ebxml support. Can we have a seperate branch for it so 
> that the trunk works off of juddi?  

Anil,

This change will not drop UDDI support (i.e. access to jUDDI), nor 
change in any way how it is accessed.  It is supposed to be completely 
transparent.

It only _adds_ support for ebXML access (JAXR level 1).

If you want to access ebXML, use the new Factory that is being added.

For UDDI (jUDDI), just use the same Factory that has always being used.

If you want to use both, create two objects, one to access UDDI and one 
to access ebXML, by using each of the Factories.

Regards,
Fernando

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Fernando Nasser wrote:
> Geir Magnusson Jr wrote:
> 
>> and if I want to use both?  How heavy is the ebxml stuff?  Seems like 
>> the convenient way is to have both in same jar.
>>
> 
> One can always add the second jar to the classpath, isn't it?

You can add individual classes too... :)

> 
> We can also provide two jars: a UDDI-only one (level 0) and a UDDI+ebXML 
> one (level 1) with both.

Sure.  Don't see the point though if there's no collsion and the size 
isn't too much...

geir

> 
> But the :how heavy" question is pertinent, if it is just a few bytes 
> them it can all go into the same jar.
> 
> Regards,
> Fernando
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.
Or, make things pluggable - naively, JAXR is JAXR and the backend 
provider should be pluggable....

Fernando Nasser wrote:
> Geir Magnusson Jr wrote:
> 
>> and if I want to use both?  How heavy is the ebxml stuff?  Seems like 
>> the convenient way is to have both in same jar.
>>
> 
> One can always add the second jar to the classpath, isn't it?
> 
> We can also provide two jars: a UDDI-only one (level 0) and a UDDI+ebXML 
> one (level 1) with both.
> 
> But the :how heavy" question is pertinent, if it is just a few bytes 
> them it can all go into the same jar.
> 
> Regards,
> Fernando
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Fernando Nasser <fn...@redhat.com>.
Geir Magnusson Jr wrote:
> and if I want to use both?  How heavy is the ebxml stuff?  Seems like 
> the convenient way is to have both in same jar.
> 

One can always add the second jar to the classpath, isn't it?

We can also provide two jars: a UDDI-only one (level 0) and a UDDI+ebXML 
one (level 1) with both.

But the :how heavy" question is pertinent, if it is just a few bytes 
them it can all go into the same jar.

Regards,
Fernando

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.
and if I want to use both?  How heavy is the ebxml stuff?  Seems like 
the convenient way is to have both in same jar.

Fernando Nasser wrote:
> Geir Magnusson Jr wrote:
> 
>>
>>
>> Just curious - why can't the be in the same jar?  You said we'll have 
>> different factories...
>>
> 
> Not a technical reason, it is just for convenience.  If someone just 
> wants to access UDDI registers (level 0 functionality only), he/she does 
> not theed the ebXML factory and related stuff.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Fernando Nasser <fn...@redhat.com>.
Geir Magnusson Jr wrote:
> 
> 
> Just curious - why can't the be in the same jar?  You said we'll have 
> different factories...
> 

Not a technical reason, it is just for convenience.  If someone just 
wants to access UDDI registers (level 0 functionality only), he/she does 
not theed the ebXML factory and related stuff.

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Fernando Nasser wrote:
> Geir Magnusson Jr wrote:
> 
>>
>>
>> Deepak Bhole wrote:
>>
>>> On Tue, 2006-01-10 at 14:29 -0800, Anil Saldhana wrote:
>>>
>>>> Deepak,
>>>>   1) Decoupling juddi -  I think u can go ahead.
>>>> 2) Bringing in ebxml support. Can we have a seperate branch for it so
>>>> that the trunk works off of juddi?  Also, you can do the packaging as
>>>> follows:
>>>>    org.apache.ws.scout.uddi.*
>>>>    org.apache.ws.scout.ebxml.*
>>>
>>>
>>>
>>>
>>> Yep, that is how I did them.
>>
>>
>>
>> Hang on - why is this separate?  Why doesn't packaging just solve it?
>>
> 
> These are for accessing different kinds of registries, which is the only 
> reason to have JAXR in the first place (otherwise one would just use the 
> registry specific interface, not an abstract API).
> 
> With regards to packing, that is an additional thing.  IMO the 
> org.apache.ws.scout.uddi.* should go in one JAR (the main scout JAR for 
> backward compatibility, unfortunately) and the 
> org.apache.ws.scout.ebxml.* in a scout-ebxml.jar.
> 

Just curious - why can't the be in the same jar?  You said we'll have 
different factories...


geir

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Fernando Nasser <fn...@redhat.com>.
Geir Magnusson Jr wrote:
> 
> 
> Deepak Bhole wrote:
> 
>> On Tue, 2006-01-10 at 14:29 -0800, Anil Saldhana wrote:
>>
>>> Deepak,
>>>   1) Decoupling juddi -  I think u can go ahead.
>>> 2) Bringing in ebxml support. Can we have a seperate branch for it so
>>> that the trunk works off of juddi?  Also, you can do the packaging as
>>> follows:
>>>    org.apache.ws.scout.uddi.*
>>>    org.apache.ws.scout.ebxml.*
>>
>>
>>
>> Yep, that is how I did them.
> 
> 
> Hang on - why is this separate?  Why doesn't packaging just solve it?
> 

These are for accessing different kinds of registries, which is the only 
reason to have JAXR in the first place (otherwise one would just use the 
registry specific interface, not an abstract API).

With regards to packing, that is an additional thing.  IMO the 
org.apache.ws.scout.uddi.* should go in one JAR (the main scout JAR for 
backward compatibility, unfortunately) and the 
org.apache.ws.scout.ebxml.* in a scout-ebxml.jar.



> 
> Wait - please explain why we need a branch?  Sorry to belabor, but I 
> don't see why a branch is needed still.
> 

I don't see why a branch is needed either.


Best regards,
Fernando

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Davanum Srinivas wrote:
> Geir,
> 
> I'd like to see how it looks and feels and may be do it better in the
> HEAD. AFAIK "revolutionary" branches are allowed in all projects at
> apache or even at least to experiment.
> 

Oh, I see.  This is going to be done entirely in branch and it leaves 
the head alone.

I'm 100% fine with that.

I read it as now splitting the mainline Scout code into the jUDDI part 
and the ebXML part, which made no sense to me.

If this leaves the HEAD alone, he can do whatever he wants in a branch.

geir

> -- dims
> 
> On 1/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> 
>>
>>Deepak Bhole wrote:
>>
>>>On Tue, 2006-01-10 at 14:29 -0800, Anil Saldhana wrote:
>>>
>>>
>>>>Deepak,
>>>>
>>>>1) Decoupling juddi -  I think u can go ahead.
>>>>2) Bringing in ebxml support. Can we have a seperate branch for it so
>>>>that the trunk works off of juddi?  Also, you can do the packaging as
>>>>follows:
>>>>   org.apache.ws.scout.uddi.*
>>>>   org.apache.ws.scout.ebxml.*
>>>
>>>
>>>Yep, that is how I did them.
>>
>>Hang on - why is this separate?  Why doesn't packaging just solve it?
>>
>>
>>>
>>>>Do it in a branch, please..
>>>>
>>>>There is one ticket item (asynchronous support) before we can make a
>>>>Scout 1.0 release.
>>>
>>>
>>>Sure. Once Davanum's question re: ebxml is answered (fnasser can answer
>>>it better than I, so waiting on his reply...) and everything is clear, I
>>>will commit patch #1, tag, create branch, and commit the ebxml stuff
>>>into that branch.
>>
>>Wait - please explain why we need a branch?  Sorry to belabor, but I
>>don't see why a branch is needed still.
>>
>>geir
>>
>>
>>>Cheers,
>>>Deepak
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: scout-dev-help@ws.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: scout-dev-help@ws.apache.org
>>
>>
> 
> 
> 
> --
> Davanum Srinivas : http://wso2.com/blogs/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Davanum Srinivas <da...@gmail.com>.
Geir,

I'd like to see how it looks and feels and may be do it better in the
HEAD. AFAIK "revolutionary" branches are allowed in all projects at
apache or even at least to experiment.

-- dims

On 1/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Deepak Bhole wrote:
> > On Tue, 2006-01-10 at 14:29 -0800, Anil Saldhana wrote:
> >
> >>Deepak,
> >>
> >>1) Decoupling juddi -  I think u can go ahead.
> >>2) Bringing in ebxml support. Can we have a seperate branch for it so
> >>that the trunk works off of juddi?  Also, you can do the packaging as
> >>follows:
> >>    org.apache.ws.scout.uddi.*
> >>    org.apache.ws.scout.ebxml.*
> >
> >
> > Yep, that is how I did them.
>
> Hang on - why is this separate?  Why doesn't packaging just solve it?
>
> >
> >
> >>Do it in a branch, please..
> >>
> >>There is one ticket item (asynchronous support) before we can make a
> >>Scout 1.0 release.
> >
> >
> > Sure. Once Davanum's question re: ebxml is answered (fnasser can answer
> > it better than I, so waiting on his reply...) and everything is clear, I
> > will commit patch #1, tag, create branch, and commit the ebxml stuff
> > into that branch.
>
> Wait - please explain why we need a branch?  Sorry to belabor, but I
> don't see why a branch is needed still.
>
> geir
>
> >
> > Cheers,
> > Deepak
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: scout-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Deepak Bhole wrote:
> On Tue, 2006-01-10 at 14:29 -0800, Anil Saldhana wrote:
> 
>>Deepak,
>>   
>>1) Decoupling juddi -  I think u can go ahead.
>>2) Bringing in ebxml support. Can we have a seperate branch for it so
>>that the trunk works off of juddi?  Also, you can do the packaging as
>>follows:
>>    org.apache.ws.scout.uddi.*
>>    org.apache.ws.scout.ebxml.*
> 
> 
> Yep, that is how I did them.

Hang on - why is this separate?  Why doesn't packaging just solve it?

> 
> 
>>Do it in a branch, please.. 
>>
>>There is one ticket item (asynchronous support) before we can make a
>>Scout 1.0 release. 
> 
> 
> Sure. Once Davanum's question re: ebxml is answered (fnasser can answer
> it better than I, so waiting on his reply...) and everything is clear, I
> will commit patch #1, tag, create branch, and commit the ebxml stuff
> into that branch.

Wait - please explain why we need a branch?  Sorry to belabor, but I 
don't see why a branch is needed still.

geir

> 
> Cheers,
> Deepak
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Deepak Bhole <db...@redhat.com>.
On Tue, 2006-01-10 at 14:29 -0800, Anil Saldhana wrote:
> Deepak,
>    
> 1) Decoupling juddi -  I think u can go ahead.
> 2) Bringing in ebxml support. Can we have a seperate branch for it so
> that the trunk works off of juddi?  Also, you can do the packaging as
> follows:
>     org.apache.ws.scout.uddi.*
>     org.apache.ws.scout.ebxml.*

Yep, that is how I did them.

> Do it in a branch, please.. 
> 
> There is one ticket item (asynchronous support) before we can make a
> Scout 1.0 release. 

Sure. Once Davanum's question re: ebxml is answered (fnasser can answer
it better than I, so waiting on his reply...) and everything is clear, I
will commit patch #1, tag, create branch, and commit the ebxml stuff
into that branch.

Cheers,
Deepak



---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Re: Proposed plan for commit of juddi decoupling + ebxml support

Posted by Anil Saldhana <an...@yahoo.com>.
Deepak,
     
  1) Decoupling juddi -  I think u can go ahead.
  2) Bringing in ebxml support. Can we have a seperate branch for it so  that the trunk works off of juddi?  Also, you can do the packaging  as follows:
      org.apache.ws.scout.uddi.*
      org.apache.ws.scout.ebxml.*
  Do it in a branch, please.. 
  
  There is one ticket item (asynchronous support) before we can make a Scout 1.0 release. 
  
  Regards,
  Anil

Deepak Bhole <db...@redhat.com> wrote:  Hi,

Now that I have commit access, I plan to commit my previous two patches
into the repository. Relevant messages are here:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1606

and

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=juddi-dev@ws.apache.org&msgNo=1607

The former is a patch that removes juddi dependency from scout. 

The latter, adds ebxml support.

The issue is that the ebxml changes are extensive. They change ALL
package names in scout (previously, everything was under
org.apache.ws.scout.* . However, ebxml code is different, which required
separation into org.apache.ws.uddi.* (everything from org.apache.ws.*)
and org.apache.ws.ebxml.*.

Commit of the first patch won't break anything (hopefully :)). However,
once the second one is in, other applications that use scout classes
directly, will have to be updated to use the newer structure.

I was thinking of tagging the repository after the first patch is
committed (suggestions for tag name are welcome), after which I would
upload the second set of changes. If there are any
objections/suggestions on better ways to handle this, please let me
know.

Cheers,
Deepak 
  


		
---------------------------------
Yahoo! Photos
 Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.