> Oh damn, I thought we just import OSGi API as a dependency :( . I'll
> roll back to previous version and think what we can do without OSGi
> API.
I decided to switch back [1] to the very first version of the OSGi
detection method - analyzing the name of the Camel Context. It is
primitive and sim
> Yes, otherwise non OSGI ppl have class not found exception when
> org.apache.camel.util is loaded.
> So it must be in that sub package if you use osgi imported coded.
Oh damn, I thought we just import OSGi API as a dependency :( . I'll
roll back to previous version and think what we can do witho
On Thu, Feb 20, 2014 at 3:57 PM, Henryk Konsek wrote:
>> -1 to this
>>
>> We cannot have osgi imports in the camel-core source code.
>> This is ONLY allowed in that special osgi sub package.
>
> You mean I can rely on OSGi API only in org.apache.camel.impl.osgi?
>
Yes, otherwise non OSGI ppl have
> -1 to this
>
> We cannot have osgi imports in the camel-core source code.
> This is ONLY allowed in that special osgi sub package.
You mean I can rely on OSGi API only in org.apache.camel.impl.osgi?
--
Henryk Konsek
http://henryk-konsek.blogspot.com
-1 to this
We cannot have osgi imports in the camel-core source code.
This is ONLY allowed in that special osgi sub package.
On Thu, Feb 20, 2014 at 3:39 PM, wrote:
> Repository: camel
> Updated Branches:
> refs/heads/master 9beec7470 -> a42a2ca95
>
>
> [CAMEL-7218] Rely on OSGi FrameworkUti
