Re: [jboss-dev] jb-cl and fragments support

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) >> >> >