[jboss-dev] jboss-cvs-commits Digest, Vol 43, Issue 300

[Ales Justin]

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