Hear hear! Very good advice.
I ran into the situation quite often that people first want to figure out OSGi
with manifest, service references, bundle objects etc. This is imho absolutely
the wrong way. If there was one thing I think we did totally wrong in the
framework then it is that we left out DS from the start. DS should have been
integral to the framework.
OSGi without DS is like programming with a Java assembler instead of using ecj.
Maybe fun for masochists but not for getting the hang of what OSGi is really
about.
Now do not get me wrong, I still believe the OSGi API is very concise and
elegant but the domain is middleware. When you make building blocks to simplify
the life of application developers, the OSGi API is an almost perfect domain.
If you however write app software doing tax returns you should NOT see OSGi API
anywhere.
Kind regards,
Peter Kriens
On 10 nov 2010, at 12:43, [email protected] wrote:
> 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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
