incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: [PROPOSAL] Next Steps
Date Wed, 05 Sep 2007 15:01:23 GMT

On Sep 5, 2007, at 10:30 AM, Daniel Kulp wrote:

> My expectation is that Harmony would be using CXF (or Axis, though I
> obviously would prefer they use CXF since CXF is already standalone
> JAX-WS certified compliant) for the WebServices stuff they need.   I
> don't see why they would write another webservices stack.  Or are you
> suggesting that CXF also get merged into Harmony?   Are we following
> Sun's lead and jamming all the projects into the JRE?   That doesn't
> make sense to me.

I wasn't suggesting that CXF get merged into Harmony, or at least  
didn't mean too ;-)  If it makes sense to move the bindings to CXF  
that would be fine with me.  The only concern I would have is that  
the tooling should be transparent enough that CXF isn't the only  

> Also, the WebServices stuff Harmony needs definitely does NOT  
> include a
> CORBA binding for the JAX-WS stuff.   That isn't part of the specs  
> they
> need.  Thus, it really doesn't make sense to me to put that part  
> there.
> The commiters that have contributed to the binding since Jan are:
> bravi
> dmiddlem
> enolan
> mvescovi - 2 commits to add a couple tests and 1 commit to fix a build
> failure
> rickmcguire  - 3 commits related to mvn build things (release preps)
> dblevins - 1 commit related to continuum setup
> lkuehne - 1 commit to apply a patch from JIRA
> adc - just some maven build things
> If you add the tooling that goes with the binding (idl2wsdl,  
> wsdl2idl),
> then mvescovi and lkuehne have a few more.   (Note, there isn't a idlj
> tool, so your mention of that is relatively irrelevant.  There is a
> start of a pre-processor in the tools module that would be the first
> part of a idlj, but that's it.)   In anycase, from the bindings  
> part, it
> would just be the 3 or 5 of them, depending on if they are  
> interested or
> not.  (we'd obviously give them a chance to opt-out if they want).

I was following up on an earlier e-mail on this topic but you  
provided more detail here.  Again, I thre out the strawman to get the  
discussion going so please think of this as a stream of  
conciousness.  My experience is if someone says we should do  
something no one comments.  If one says let's do this then everyone  
has an opinion and we move forward.  If the Yoko project committers  
prefer the division then I'm fine with it.  As you know the challenge  
with a lot of this is inter-project dependency when trying to release  
but that's a problem no matter where we put stuff so...

> -- 
> J. Daniel Kulp
> Principal Engineer
> P: 781-902-8727    C: 508-380-7194

View raw message