Hello Philipp,

"Don't program to the OSGi api" !!!

In our very first osgi steps my team and I had made more often this mistake.

In my solid experience you have to use (micro) Services (declarative
services, blueprint, ...) directly !

You can start with your "non-osgi" application, launching an embedding
osgi framework (see core spec) and aggregating the first parts into a
service/component approach, step by step.

Lately I have been doing this technique successfully many times.

Good luck from germany,

Oliver (aka boeffi)

On Wed, Nov 10, 2010 at 11:25 AM, Peter Kriens <[email protected]> wrote:
> In practice, working from scratch with anything but the most trivial program 
> results in lots of wasted time and usually a disaster. However tempting it 
> sometimes can be. Just make your app works as a single monolithic bundle then 
> carve out whatever you can carve out. No need to make things fragments btw. 
> The final goal is to make the monolith an empty shell but all along the way 
> you have working code.
>
> Most important, focus on the 盜ervices. OSGi is a pain in the ass when you try 
> to stick to the static factories that are prevalent in Java. These factories 
> require global visibility and a single class space, the anathema of 
> modularity. Once you have a 盜ervice based design, it will be easy to remove 
> dead weights by more optimized components if that is worth the effort. 
> However, those changes can then be gradually made. Having a working product 
> along the way is worth more than any gain you could get by starting from 
> scratch.
>
> Kind regards,
>
>        Peter Kriens
>
>
>
> On 10 nov 2010, at 08:32, Philipp Kursawe wrote:
>
>> Hello,
>>
>> are there any recommendations on how to convert a massive Java application 
>> that uses a lot of native library code and custom classpathes to OSGi?
>>
>> I think there are 2 ways.
>>
>> 1. Put everything that is Java into one bundle and everything native into a 
>> fragment bundle. Then start to extract smaller parts of the app into their 
>> own bundles and replace custom class-path loading.
>>
>> 2. Choose parts of the app that can be grouped together into bundles easily 
>> and rebuild the app "from scratch" using bundles.
>>
>> Any experiences from the people here which solution is to favor? I tend to 
>> think 1 is easier to accomplish. But it would also drag in a lot of old 
>> code, whereas with the second way you could rewrite code and kick out old 
>> code.
>>
>> Thanks for your inputs on this,
>> Phil
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to