I had an offline discussion with Kurt.
It is certainly worth the effort to do code generation for the uddi types as
part of the build. This will remove dependence on juddi to a larger extent.
But please have the build use the source code generated for the types (mainly
for debugging reasons). Kurt said this is possible. The generated types need to
have the same packaging as the scout classes (org.apache.ws.scout.uddiv2 ???)
Kurt T Stam <[EMAIL PROTECTED]> wrote: 1. How are they static? Don't
they change with every rev of the uddi version?
2. Also the branch is using the jUDDI proxy classes. On the trunk there are
scout versions of these (3) classes. I prefer having these classes in scout.
>So then what do we actually need to do?
Well I still see no harm is generating the bindings from the uddi xsd (what is
the issue with this?). If we'd agree to keep (1) and (2) we 're looking at a
merge from the branch into trunk?
--Kurt
Anil Saldhana wrote: The question of uddi types arose due to plain uddi types
(which juddi provided us). But someone had issues with having a dependence on
juddi due to classloading issues. So brought in xmlbeans to generate the uddiv2
types.
In the long run, since the uddi types are static and will not change, scout
can create its own uddi types. Then there is no dependence on juddi or xmlbeans
for that.
Kurt T Stam <[EMAIL PROTECTED]> wrote: I actually have been
working with the trunk code and in fact *like* that it does not depend on the
juddi jar (other then for testing). What is the issue with xmlbeans? It seems
to do the trick just fine.
After looking at the v0.7rc3 code base and understanding the background I
think we should keep the trunk code, and *merge* in the branch fixes.I'm sorry
for flip flopping here..
My 2 cents
--Kurt
Anil Saldhana wrote: Ok, here is the background.
I asked Kurt to take care of synchronizing rc3 to trunk yesterday and I was
supposed to open a VOTE for it today. But because he works in a timezone
earlier than me, he broached the topic on the list.
The reason the trunk has gone stale is because it contains the xmlbeans
related refactoring done last year, which really did not make it to any of the
releases.
Geir cut the v0.5 release - I made a v0.7rc1 branch out of it and released
v0.7rc1 (after a vote ofcourse). Then another branch v0.7rc2 was cut from
v0.7rc1 to include bug fixes and released.
So yesterday I made a copy of trunk in archives. After a vote, the branch
v0.7rc2/rc3 was supposed to be synched up with trunk.
Finally, once we are ready - we can do a v0.7 release that takes care of
JEE1.4 JAXR requirements(UDDI/Capability level 0 ).
Immediate items:
a) Sync trunk and active development happens there.
b) Release Scout into maven repos. ( I think I did this for v0.7rc2)
Also, I want to introduce Kurt as someone who will take juddi and Scout to the
next level because he has a lot of ideas.
"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: Again, who asked
you to do this?
geir
On Jan 4, 2007, at 8:49 AM, Kurt T Stam wrote:
> No a vote was not done, I guess the prevailing wisdom is that the most
> recent development was done on the branches and not on the trunk.
>
> --Kurt
>
> Davanum Srinivas wrote:
>> "was asked" - By Who?
>>
>> Please start a VOTE for doing this. (or was there a vote done
>> already?)
>>
>> thanks,
>> dims
>>
>> On 1/4/07, Kurt T Stam wrote:
>>> Hi guys,
>>>
>>> I was asked to *replace* the trunk with the code in the v0.7rc3
>>> branch.
>>> The trunk was archived yesterday afternoon, but before I do this
>>> I want
>>> to make sure there are no objections to this. The idea is to have
>>> the
>>> trunk contain the latest code again. Note that this would be a
>>> replace,
>>> not a merge.
>>>
>>> I will send out another email before starting the work, but I'd
>>> like to
>>> it today.
>>>
>>> Thank you,
>>>
>>> --Kurt
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
