This page is no longer maintained — Please continue to the home page at www.scala-lang.org

OSGi-fying Scala

4 replies
Heiko Seeberger 2
Joined: 2009-04-05,
User offline. Last seen 42 years 45 weeks ago.
Hi,
I am currently working on different "OSGi on Scala" projects, e.g. ScalaModulesLift (OSGi-fying Lift) and BindForge. I do not know how well OSGi is known in the Scala space, but it will be a very serious thing for Java and in my opinion also very useful for Scala. To keep things simple: It is a dynamic module system which allows to develop and deploy modular Java/Scala systems. Basically there is some metadata specified in a JAR's manifest declaring things like module ID and version, public API, dependencies, etc. Hence all that is needed to OSGi-fy an existing library is adding the necessary manifest headers.
For the above mentioned projects me and my mates have created OSGi-fied versions of the Scala libraries (scala-lang and scala-compiler so far). But that is redundant work! We would like to create these OSGi-fied Scala libraries in ONE common project and publish these to ONE central Maven repository. So far I have been talking to David Pollak and we decided to go for:
"org.scala-lang" as group id and "scala-library-osgi", "scala-compiler-osgi", etc. as artifact ids.
This naming resembles the "original" Scala libraries and makes clear that you will find OSGi inside.What do you think? Any other ideas?
Heiko
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 6 days ago.
Re: OSGi-fying Scala
Heiko,

I've been working on OSGi support in scala, specifically 2 things:

1) OSGi-ifying scala standard libraries isn't too bad.  I have project which does this: http://github.com/jsuereth/scala-jigsaw/tree/master  I'd like to add this to the standard scala build so there is no  more differentation between an OSGi version of scala and a non-OSGi version.   Currently all this does is use BND to add a few entries to the manifests of each library.  The issue here would be updating the eclipse plugin so that dogfooding is still possible (the current method breaks it).  I haven't had the time to invest in fixing this yet.

2) A method of enforcing module visibility inside the compiler.  I've started a scalac plugin: http://github.com/jsuereth/osgi-scalac-plugin/tree/master to make this happen.   Currently it only pays attention to libraries that declare "packge-export" in their manifest and warns for all other import types.  Help here would be appreciated if anyone is interested!!!

Whatever is decided would be great!  Recently I haven't had as much time as desired to hack on these and bring them up to "production ready".   So, if they are handy in whatever we decide to do, great!

I would prefer not having different artifacts for "OSGi scala" vs. "non-OSGi scala".  ( The main reason is that the same maven plugin could be used in both cases ;) )


-Josh

On Sun, Apr 5, 2009 at 11:37 AM, Heiko Seeberger <fightgravity [at] me [dot] com> wrote:
Hi,
I am currently working on different "OSGi on Scala" projects, e.g. ScalaModulesLift (OSGi-fying Lift) and BindForge. I do not know how well OSGi is known in the Scala space, but it will be a very serious thing for Java and in my opinion also very useful for Scala. To keep things simple: It is a dynamic module system which allows to develop and deploy modular Java/Scala systems. Basically there is some metadata specified in a JAR's manifest declaring things like module ID and version, public API, dependencies, etc. Hence all that is needed to OSGi-fy an existing library is adding the necessary manifest headers.
For the above mentioned projects me and my mates have created OSGi-fied versions of the Scala libraries (scala-lang and scala-compiler so far). But that is redundant work! We would like to create these OSGi-fied Scala libraries in ONE common project and publish these to ONE central Maven repository. So far I have been talking to David Pollak and we decided to go for:
"org.scala-lang" as group id and "scala-library-osgi", "scala-compiler-osgi", etc. as artifact ids.
This naming resembles the "original" Scala libraries and makes clear that you will find OSGi inside. What do you think? Any other ideas?
Heiko

channingwalton
Joined: 2008-09-27,
User offline. Last seen 2 weeks 1 day ago.
Re: OSGi-fying Scala

Hi,
this is interesting to me as I intend to OSGI-ify something
(www.flyobjectspace.com). Is adding a manifest all that is required? I am
familiar with eclipse plugin development but am not clear of the
differences, if any, with OSGi.

I'd appreciate any pointers you have.

Channing

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 6 days ago.
Re: OSGi-fying Scala
Channing,

The details of OSGi is a can of worms that perhaps will take some time to dive into.   The basics are, yes you can OSGi-ify things by adding a manifest, but there are some subtleties depending on how modular you would like to make your code.

If all you want is a versioned library, of which users could enforce particular versions for particular modules (and your library doesn't look up classes outside *its* dependencies, via reflection or other magic), then yes it's just an OSGi header.

If you'd like your module to provide an "OSGi Service" which users can make use of (one such use being that an OSGi Service would be a more standard API where you can pick and choose implementations based on needs), then you should take a look at OSGi Services API (or perhaps Spring's Dynamic Module support).

Heiko could probably provide more details, however it would help if you detailed how you'd like to modularize flyobjectspace.  From my understanding of your software you would certainly want to look into some of OSGi's more advanced features for providing a "Space" service.  There may already be a specification.  I haven't kept as in touch with OSGi since migrating to my latest project.


- Josh

On Sun, Apr 5, 2009 at 3:31 PM, Channing Walton <channingwalton [at] mac [dot] com> wrote:

Hi,
this is interesting to me as I intend to OSGI-ify something
(www.flyobjectspace.com). Is adding a manifest all that is required? I am
familiar with eclipse plugin development but am not clear of the
differences, if any, with OSGi.

I'd appreciate any pointers you have.

Channing
--
View this message in context: http://www.nabble.com/OSGi-fying-Scala-tp22895117p22897650.html
Sent from the Scala - User mailing list archive at Nabble.com.


channingwalton
Joined: 2008-09-27,
User offline. Last seen 2 weeks 1 day ago.
Re: OSGi-fying Scala

Thanks Josh I'll look into that.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland