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

[Anil Saldhana]

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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]&msgNo=1606

and

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&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 whi ch 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.