On Wed, Apr 22, 2009 at 8:56 AM, ant elder <antel...@apache.org> wrote:
>
>
> On Wed, Apr 22, 2009 at 8:52 AM, Simon Laws <simonsl...@googlemail.com>
> wrote:
>>
>> On Wed, Apr 22, 2009 at 8:45 AM, ant elder <antel...@apache.org> wrote:
>> >
>> >
>> > On Wed, Apr 22, 2009 at 8:39 AM, Luciano Resende <luckbr1...@gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Apr 22, 2009 at 12:29 AM, ant elder <antel...@apache.org>
>> >> 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

Reply via email to