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 <fightgrav...@me.com>wrote: > Hi, > I am currently working on different "OSGi on Scala" projects, e.g. > ScalaModules <http://www.scalamodules.org>, Lift <http://www.liftweb.net> > (OSGi-fying > Lift) and BindForge <http://www.bindforge.org>. 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 > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
