I do agree with the judgement that OSGi is hard to get started with. The
problem with OSGi is that it not only blatantly shows how unmodular your and
much open source code is, it even refuses to run your code. In many ways it is
like your compiler refusing to compile until you fixed the last of many
warnings. Though this is all for good reasons, in reality a lot of code is
actually running ok even though it is a mess on the inside.
So using standard classic Java patterns do not work very well, mostly due to
extensive dynamic loading to configure the app, which is fundamentally not
modular. This makes it really hard to get started with OSGi because a lot of
open source libraries do not work well with OSGi for this reason. And even if
they run, too few actually leverage OSGi
Last year I found out how hard it is to live outside an App server or not use
Spring. For a web app there is a lot of stuff that you have to think about that
is completely orthogonal to your domain: persistence, security, caching,
queuing, batching, etc. Unfortunately, those OSGi components that provide that
functionality are not there. Lots of open source libraries, but none work
really well in OSGi, they all have their own configuration models, life cycle,
etc., sticking out like sore thumbs. I also frequently have to cry when I look
how open source libraries try to use OSGi :-(
This is the exact reason the OSGi Alliance has hired me again. My task for the
foreseeable future is to develop a framework for web apps that leverages OSGi
to the hilt, i.e. it does it all in the OSGi way. The idea is to create a
skeleton around the OSGi µservice model and provide a concrete example how this
skeleton can be used to create web apps. All this extensively documented for
end users and not specification implementers. It also intent to have a full
modular development chain: IDE, build, ci, release, deployment. My goal is to
make web app development as easy and simple like PHP but as robust as OSGi (I
know, its ambitious).
I am currently writing an RFP to define the scope of this work, which is hard
since this is a very broad field. I'd love to get your ideas as input. The RFP
will become publicly available under our new process.
Looking forward to your input, kind regards,
Peter Kriens
On 18 jul. 2013, at 19:50, Krishnan Ganapathy wrote:
> Hi Scott,
> Am glad at this initiative. Very much needed I think. There is a lot of grey
> areas still.. I dont see how web application developers can become
> comformtable with OSGI concepts. At times it looks very fuzzy even to me. I
> would be glad to contribute my two cents to this.
>
> I dont know if this forum is appropriate for this discussion. Maybe someone
> can throw light here...
>
> Regards
> Krishnan
>
>
> On Thu, Jul 18, 2013 at 9:30 PM, <[email protected]> wrote:
> Send osgi-dev mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of osgi-dev digest..."
>
>
> Today's Topics:
>
> 1. 'OSGi is hard' (Scott Lewis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 17 Jul 2013 12:47:26 -0700
> From: Scott Lewis <[email protected]>
> To: OSGi Developer Mail List <[email protected]>
> Subject: [osgi-dev] 'OSGi is hard'
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Folks,
>
> I would like to start a public discussion around the
> comment/mis-perception that I've received several times from new OSGi
> adopters: 'OSGi is hard'.
>
> I know that there's a lot bound up in this comment (e.g. complexity of
> dependencies, modularity, tooling, unfamiliarity with key concepts,
> etc). I would eventually like to counter this comment with examples,
> tutorials, tooling, reading, presentations, sequencing of all these
> etc., etc...whatever is most effective...but before going further...is
> this the right forum for such a discussion? Or is there a better/more
> appropriate public OSGi forum?
>
> Thanks,
>
> Scott
>
>
>
>
> ------------------------------
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> End of osgi-dev Digest, Vol 81, Issue 6
> ***************************************
>
> _______________________________________________
> 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
