On Wed, Apr 22, 2009 at 8:56 AM, ant elder <[email protected]> wrote: > > > On Wed, Apr 22, 2009 at 8:52 AM, Simon Laws <[email protected]> > wrote: >> >> On Wed, Apr 22, 2009 at 8:45 AM, ant elder <[email protected]> wrote: >> > >> > >> > On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende <[email protected]> >> > wrote: >> >> >> >> On Wed, Apr 22, 2009 at 12:29 AM, ant elder <[email protected]> >> >> wrote: >> >> >> Are we talking only about extensions (bindings and implementations) >> >> >> ? >> >> > >> >> > I'm suggesting everything. >> >> > >> >> >> >> >> >> For other modules, I'd suggest we check case by case, as I have the >> >> >> same concerns expressed by Raymond on this thread. >> >> >> >> >> > >> >> > But what are those concerns? No one has ever given any technical >> >> > reasons >> >> > for >> >> > keeping them separate that makes sense if we're not doing it >> >> > consistently. >> >> > >> >> >> >> Having the xml processors in a separate module would allow us execute >> >> the compatibility stuff for 2.x discussed in [1].... >> >> >> >> [1] http://markmail.org/message/2cez45rwmj43jxwa >> >> >> > >> > What specifically in there could we not do if the code was in a single >> > module? >> > >> > ...ant >> > >> > >> > >> >> My concern with this change would be backward compatibility. I had >> hoped we could use different versions of "?-xml" to loaded different >> spec namespaces into a single consistent model. Have been trying to >> finish up some other things to haven't got to doing any of this in 2.x >> other than I think Luciano created separate assembly-xml and >> assembly-xml-osoa modules. >> >> Simon > > Ok and thats the same as what Luciano just mentioned in another post to this > thread. So...if we had a way to enable/disable support for either namespace > independent of pulling modules in/out of the classpath would that address > this concern and then we would be ok to merge these modules? > > ...ant > Let me just be clear here. There is no technical requirement to have separate -xml modules assuming that the processor classes are in unique packages. Even to support backward compatibility. The switch is made by the entries in META-INF/services and it doesn't matter if those entries are in one module or three. This is a question of clarity and, as you point out, the ability to enable/disable features by adjusting the classpath. I think it's clearer to have these modules separate. Certainly at the moment while we are not so advanced on the backward compatibility issue.
Simon
