[jboss-dev] jb-cl and fragments support

[Thomas Diesler]

Ok, let me look at this fragment issue again. I'm not so sure whether 
there was a compelling reason. When I am done, I'll give feedback in the 
forum.

Did you see Brian's mail WRT EAP. I agree that OSGi related changes 
should preferably be done in 2.2.x if possible in order not to affect 
the EAP branches.
Hence can we possibly release 2.2.x when we have an agreement on fragments?

-thomas

On 01/26/2010 03:09 PM, Ales Justin wrote:
> This boils down to fragments support - where, how and when we want them.
>
> I'm not a maintainer of JBCL sub-project, Adrian is.
> (one of the rare MC sub-projects I don't maintain/own)
>
> And since I explicitly remember his dislike when you introduced 
> fragments into the jb-cl code,
> I doubt he would be pleased to see them in the official/supported 
> version.
>
> You already had the fragments support in OSGi facade.
> What's stopping you now, to put it back there?
>
> For native lib support, we can push the SP1, as that's been agreed upon,
> but things we agreed are not properly done, should not be pushed 
> upstream.
>
> Thomas Diesler wrote:
>> We can continue the discussion of technical details off-line.
>>
>> Let's first agree what direction this is leading to and until when we 
>> can get this done
>>
>> #1 Are we both working on getting 2.0.9 into AS
>> #2 Are we going to provide a patched 2.0.8
>> #3 Are we going to provide a 2.2.x release
>>
>> cheers
>> -thomas
>>
>> On 01/26/2010 02:29 PM, Ales Justin wrote:
>>>> > Did we agree on fragments?
>>>>
>>>> This is the last I know of
>>>> http://community.jboss.org/thread/146751?tstart=0
>>>>
>>>> I also know that Adrian plans an approach that involves a kind of 
>>>> dynamic subdeployment in the deployers, which might replace the 
>>>> current approach in future.
>>>
>>> I'm saying we shouldn't use the current approach.
>>> Since once you use it, you cannot simply remove it from future 
>>> versions.
>>> Not to mention it is a quick and dirty hack. :-)
>>>
>>>> The current approach allows for fragment test coverage in our 
>>>> testsuites and fair amount of core TCK tests related to fragments 
>>>> that pass.
>>>
>>> This are all fairly valid reasons.
>>> But I still disagree that this should be part of jb-cl code.
>>>
>>> We already have a bunch of CL code that atm only lives in our OSGi 
>>> facade,
>>> currently making transparent OSGi addition impossible [1].
>>> So, rather than hacking away stable jb-cl project,
>>> we should just introduce this fragments only in OSGi facade - which 
>>> is something I think you already had at the beginning.
>>>
>>> [1] - it's possible to change some core components manually and it 
>>> will work,
>>> the final solution will allow for transparent addition.
>>>
>>>> > You also shouldn't update pom info to MC kernel, as this is meant 
>>>> for 2.2.x versions
>>>>
>>>> I believe there was a compile issue in classloading-vfs that made 
>>>> this necessary.
>>>
>>> Which compile issues?
>>>
>>>> Currently, the jboss-cl-2.0.x code base is used together with 
>>>> kernel-2.2.x in AS6.
>>>> I suppose that might justify this dependency update as well.
>>>
>>> I tested the old CL 2.0.8 with both Kernel versions, and there were 
>>> no problems.
>>> (there might be some with 2.2.0.Alpha1, as we prematurely removed 
>>> ControllerState ctor, but should be fine with 2.2.0.Alpha2)
>>>
>>> The MC components are loosely coupled, only "connecting" on spi/api,
>>> which shouldn't change for 2.x versions.
>>> Hence I don't see a problem with CL using the old one.
>>> I actually think it's even better that the 2.0.x CL also uses 2.0.x 
>>> Kernel.
>>> (might be different with VFS, as we spotted more bugz there, hence 
>>> needed to make more "drastic" changes, leading to API changes)
>>>
>>>
>>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx