Re: [jboss-dev] jboss-cvs-commits Digest, Vol 43, Issue 300
> 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)