felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Felix M2 Plugin feedback
Date Mon, 19 Sep 2005 18:19:26 GMT
Niclas Hedhman wrote:
> On Monday 19 September 2005 17:11, Daniel Fagerstrom wrote:
>>This far when I have built bundles with Ant I have exploded bundles with
>>embeded jars and put the embeded one on the classpath, but that is
>>obviously not a satisfying solution. How can this be solved with M2? Is
>>it possible to give a classloader to the compiler rather than an
>>ordinary classpath, so that we can use an OSGi aware classloader while
>>compiling? If we use "packaging" the plugin could also chose to embed
>>dependencies that has package type "jar" and not embed dependencies of
>>type "osgi-bundle".
> Maybe I am a total idiot and doesn't understand how complicated life is, but I 
> don't see a problem.
>  1. Separate the codebase properly into an API jar and an IMPL bundle jar.
>  2. All other bundles depending on an API, puts it inside their bundle and
>     export it with correct versioning (which I agree can be tricky for 
>     non-endorsed APIs).
> Where is the problem, exactly?? If you are talking about "messy 3rd party", my 
> recommendation is library bundles exporting the whole sha-bang, and try to 
> influence the project to clean up their act (Cocoon included ;o)  ). I do 
> realize the extent of Cocoon 3rd party dependencies, and getting them all to 
> change is not realistic, but...

I would much prefer if all code was cleanly separated in API and 
implementation. Unfortunatly most of the 50+ "soon to become bundles" 
that Cocoon consist of nor the 100+ libraries it depend on is organized 
that way. With jars containing both API and implementation, your point 2 
above becomes less attractive. And to clean up all these jars from 
numerous organizations seem not only extremely boring but also unrealistic.

To me it seem much easier to reuse the classloader mechanism that 
allready must be part of any OSGi framework, for bundle building. 
Especially as, at least the Eclipse version, seem to be designed to be 


View raw message