ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil Saldhana <anilsaldh...@yahoo.com>
Subject Re: replacing the trunk with branch-v0.7rc3
Date Mon, 08 Jan 2007 16:05:43 GMT
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 <kstam@redhat.com> 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 <kstam@redhat.com> 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." <geir@pobox.com> 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: 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
 >
         
         
 ---------------------------------------------------------------------
 To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
 For additional commands, e-mail: scout-dev-help@ws.apache.org
         
                
        __________________________________________________
 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 
Mime
View raw message