On Wed, Apr 29, 2009 at 6:29 PM, Raymond Feng <[email protected]> wrote: > Please see comments inline. > Thanks, > Raymond > > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Tuesday, April 28, 2009 12:55 AM > To: <[email protected]> > Subject: Re: Merging model and model-xml modules into one > >> On Mon, Apr 27, 2009 at 6:12 PM, Raymond Feng <[email protected]> wrote: >>> >>> What are the things that are not completely trivial? >> >> As i said in the previous mail the non-trivial ones remaining are: >> binding-ws-xml, contribution-xml, definitions-xml, >> implementation-java-xml, >> interface-java-xml > > Maybe my question wasn't clear. I was asking what are things in these > modules make it not trivial to merge them with > the model module. >
Ah ok i'd misunderstood. I didn't investigate. All i did was one by one merge all the old -xml modules into the model modules and most just worked except for those five. A quick look showed there was problems with things like cyclic dependencies. It may turn out that we need to keep some of those separate or we need to move classes about into more appropriate modules. Each module needs to be investigated, i've started on the binding-ws-xml one and posted that other thread about it, and there's now some conversation on this thread about the contribution-xml one too. If you'd like to help pick one of those other modules and try to do the merge. What would be good to end up with is a clear and common understanding of the type of function provided by each module and have that reflected in an as consistent as possible naming pattern and have a README in each module briefly summarizing its purpose. >> >>> Can you give us an example to show the runtime module is dragged in? >> >> See http://apache.markmail.org/message/tyvnziazg22or4lu > > I see the dependency is a bit involved. IMO, the databinding based schema > generation is OK as dependencies. > The J2W piece doesn't have to be viewed as runtime dependencies. Thats possibly true, i guess we just have to decide what functions we're trying to achieve with the modularization structure. On another thread we're talking about spiting out some Java introspection code into a separate pluggable piece with interfaces and factories, if we go that far just for some Java introspection you'd think we'd at least want to do something similar for this wsdl generation function - make the J2W implementation pluggable and binding-ws isn't dependent directly on our particular J2W implementation detail, so have an SPI extension point for wsdl generation which binding-ws-xml can use instead of directly calling a static method in binding-ws-wsdlgen. > > BTW, I don't see any dependencies to binding-ws-axis2 and > binding-ws-axis2-policy though. > LOL, thats precisely what i was saying earlier - these are hard to spot as soon as they're not from one explicit dependency in a single module pom.xml. The problem in this case is that it results in two cyclic dependencies - binding-ws-xml is merged to binding-ws so binding-ws gets a static method call to binding-ws-wsdlgen, binding-ws-wsdlgen has a dependency on binding-ws and binding-ws-axis2-policy, binding-ws-axis2 also depends on binding-ws-axis2-policy and binding-ws-axis2-policy depends on binding-ws - hence you can't build binding-ws until binding-ws-axis2-policy is built and vica-versa, and you can't build binding-ws-wsdlgen until binding-ws is built and visa-versa. ...ant
