[jboss-dev] jb-cl and fragments support

[Thomas Diesler]

http://community.jboss.org/message/522364#522364

Fragment support does not leak into the CL any more.

-thomas

On 01/26/2010 05:47 PM, Thomas Diesler wrote:
> 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