camel-blueprint, camel-scr and camel-core-osgi relationship

[Quinn Stevenson <qu...@pronoia-solutions.com>]

While I was trying to track down another issue, I discovered that the the dependencies on the classes in camel-core-osgi are handled differently by camel-blueprint and camel-scr.

The camel-blueprint bundle includes the class files from camel-core-osgi (and camel-core-xml for that matter), while camel-scr declares a dependency on the package and uses the camel-core-osgi bundle.

Shouldn’t the classes in camel-core-osgi be used the same way?

Re: camel-blueprint, camel-scr and camel-core-osgi relationship

[Quinn Stevenson <qu...@pronoia-solutions.com>]

Thanks for the background Claus - I completely understand how software can evolve in interesting ways.

It really threw me for a while when I was debugging because I was changing camel-core-osgi and re-deployig it to Karaf - but my changes wouldn’t show up.  I had to build both camel-core-osgi and camel-blueprint and then update camel-blueprint to get my changes in - that’s when I came across this.

Do you think this would be worth creating a JIRA for addressing?  Do you think the containers have matured enough now that the duplication could be eliminated?  

I think it would be nice if everything that needed the classes from camel-core-osgi and camel-core-xml could just use the bundles, but I understand that may not be possible.

> On Mar 13, 2016, at 1:04 AM, Claus Ibsen <cl...@gmail.com> wrote:
> 
> Hi
> 
> OSGi is complicated, in fact a lot.
> 
> Camel has been supporting osgi for almost all its lifetime. And back
> then, only spring-dm was available for running camel on servicemix.
> And then later blueprint came, and they needed to share some code,
> hence core-osgi and core-xml.
> 
> And back then the osgi containers was also more buggy and could not
> work well when you had core-osgi and core-xml as separate bundles.
> Also split packages problems and other endless problems.
> 
> And then recently scr came along.
> 
> Bottom line historical, osgi problems and whatnot makes the world as today.
> 
> 
> 
> On Sat, Mar 12, 2016 at 6:36 PM, Quinn Stevenson
> <qu...@pronoia-solutions.com> wrote:
>> While I was trying to track down another issue, I discovered that the the dependencies on the classes in camel-core-osgi are handled differently by camel-blueprint and camel-scr.
>> 
>> The camel-blueprint bundle includes the class files from camel-core-osgi (and camel-core-xml for that matter), while camel-scr declares a dependency on the package and uses the camel-core-osgi bundle.
>> 
>> Shouldn’t the classes in camel-core-osgi be used the same way?
>> 
>> 
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: camel-blueprint, camel-scr and camel-core-osgi relationship

[Claus Ibsen <cl...@gmail.com>]

Hi

OSGi is complicated, in fact a lot.

Camel has been supporting osgi for almost all its lifetime. And back
then, only spring-dm was available for running camel on servicemix.
And then later blueprint came, and they needed to share some code,
hence core-osgi and core-xml.

And back then the osgi containers was also more buggy and could not
work well when you had core-osgi and core-xml as separate bundles.
Also split packages problems and other endless problems.

And then recently scr came along.

Bottom line historical, osgi problems and whatnot makes the world as today.



On Sat, Mar 12, 2016 at 6:36 PM, Quinn Stevenson
<qu...@pronoia-solutions.com> wrote:
> While I was trying to track down another issue, I discovered that the the dependencies on the classes in camel-core-osgi are handled differently by camel-blueprint and camel-scr.
>
> The camel-blueprint bundle includes the class files from camel-core-osgi (and camel-core-xml for that matter), while camel-scr declares a dependency on the package and uses the camel-core-osgi bundle.
>
> Shouldn’t the classes in camel-core-osgi be used the same way?
>
>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2