Re: [sbt] [sbtosgi] Adding Export-Package header

[Heiko Seeberger]

sbt-osgi is based on bnd. Please take a look at the bnd docs, then you will find that you have to use * to "capture" the package in question and all sub packages: http://www.aqute.biz/Bnd/Bnd

Heiko

On Nov 20, 2012, at 1:56 AM, Raman Gupta <rocke...@gmail.com> wrote:

I figured out the problem, or at least a work-around. For some reason sbt needs exportPackage to be a wildcard, at which point it includes those packages in the output jar and adds the right headers.

      OsgiKeys.importPackage := Seq(

        "akka*;version=\"[2.1.0,3.0.0)\"",

        "scala*;version=\"[2.10.0,2.11.0)\"",

        "journal.io.api;version=\"[1.2,2.0)\";resolution:=optional",

        "org.fusesource.leveldbjni;version=\"[1.4.1,2.0.0)\";resolution:=optional",

        "org.iq80.leveldb;version=\"[1.4.1,2.0.0)\";resolution:=optional",

        "*"

      ),

      OsgiKeys.exportPackage := Seq(

        "org.eligosource*"

      ),

Strange behavior. The way exports are defined in the maven bundle plugin is more intuitive.

Regards,

Raman

On Sunday, November 18, 2012 2:49:37 AM UTC-5, Raman Gupta wrote:

Using sbt-osgi 0.5.0-snaphsot.  sbt-osgi insists on adding a Private-Package header in lieue of an Export-Package header. If I specify an empty privatePackage := Seq("") then the output jar is empty. This is not the way regular bnd works, so I don't really understand what sbt-osgi is doing.

Here are the settings that do not result in an export-package header -- instead sbt-osgi creates a Private-Package header (!):

  .settings(osgiSettings: _*)

  .settings(

    OsgiKeys.exportPackage := Seq(

      "org.eligosource.eventourced.core;version=\"0.5.0.vivo_1\"",

      "org.eligosource.eventourced.journal;version=\"0.5.0.vivo_1\"",

      "org.eligosource.eventourced.util;version=\"0.5.0.vivo_1\""

    ),

    OsgiKeys.importPackage := Seq(

      "akka*;version=\"[2.1.0,3.0.0)\"",

      "scala*;version=\"[2.10.0,2.11.0)\"",

      "journal.io.api;version=\"[1.2,2.0)\";resolution:=optional",

      "org.fusesource.leveldbjni;version=\"[1.4.1,2.0.0)\";resolution:=optional",

      "org.iq80.leveldb;version=\"[1.4.1,2.0.0)\";resolution:=optional",

      "*"

    )

  )

Regards,

Raman

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/HSwFGQxaA74J.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Raman Gupta]

Agreed, but the default behavior of maven-bundle-plugin is far more intuitive than the default behavior of sbt-osgi, in the way that the plugin configures the default bnd settings for Export-Package and Private-Package. Please see "Default Behavior" at the page: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

The big difference is that the plugin assumes the packages created by the source are to be exported (except for "impl" and "internal"), whereas sbt-osgi assumes they are private.

Regards,

Raman

[Heiko Seeberger]

On Nov 20, 2012, at 4:10 PM, Raman Gupta <rocke...@gmail.com> wrote:

Agreed, but the default behavior of maven-bundle-plugin is far more intuitive than the default behavior of sbt-osgi, in the way that the plugin configures the default bnd settings for Export-Package and Private-Package. Please see "Default Behavior" at the page: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

The big difference is that the plugin assumes the packages created by the source are to be exported (except for "impl" and "internal"), whereas sbt-osgi assumes they are private.

Agreed. Please open a ticket and (now it starts getting interesting) provide a patch ...

Heiko

[Raman Gupta]

Issue opened: https://github.com/sbt/sbt-osgi/issues/2

I took a look to see what would be involved in a patch, but its not obvious to me how to get SBT to provide the same type of meta-data to the plugin that Maven provides to the maven-bundle-plugin. I've never written an SBT plugin before, and my SBT experience is limited. Any assistance would be appreciated.

Regards,

Raman

[Heiko Seeberger]

On Nov 20, 2012, at 10:30 PM, Raman Gupta <rocke...@gmail.com> wrote:

Issue opened: https://github.com/sbt/sbt-osgi/issues/2

I took a look to see what would be involved in a patch, but its not obvious to me how to get SBT to provide the same type of meta-data to the plugin that Maven provides to the maven-bundle-plugin. I've never written an SBT plugin before, and my SBT experience is limited. Any assistance would be appreciated.

Could you describe the expected behavior?

Heiko

[Raman Gupta]

At least to start with, lets say I try to replicate the default behavior of maven-bundle-plugin Export-Package, which is: "assumed to be the set of packages in your local Java sources, excluding the default package '.' and any packages containing 'impl' or 'internal'". Here are some of the maven-bundle-plugin source (see http://svn.apache.org/viewvc/felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java?revision=HEAD&view=markup for example). Looking at that source again, it appears I was incorrect about it using maven meta-data to figure out the default export packages... it seems it is just scanning the actual source directory. Presumably, the source director(ies) are available to SbtOsgi via "someVariableIDontKnowYet in Compile" -- I need to do more investigation on this...

Regards,

Raman

[Heiko Seeberger]

In Scala we can't use the names of the directories to get the package names, because there need not be a 1:1 mapping.

A simplistic solution would use the sources setting (jn Compile configuration) which lists all the source files. Then we could read the package clauses and take it from there.

There might be better ways, though, to get the packages ...

Heiko

[Mark Harrah]

One way is to use the result of compilation, which provides package names:

TaskKey[Seq[String]]("packages") <<= compile in Compile map { analysis =>
for {
(srcFile, srcAPI) <- analysis.apis.internal.toSeq
pkg <- srcAPI.api.packages
} yield
pkg.name
}

I don't think there are any caveats to this, but you should check that it works for Java sources (bug if it doesn't). See also:

http://www.scala-sbt.org/release/api/index.html#sbt.inc.Analysis

-Mark

>
> Heiko

>
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.

[Heiko Seeberger]

On Nov 21, 2012, at 6:38 PM, Mark Harrah <dmha...@gmail.com> wrote:

> One way is to use the result of compilation, which provides package names:
>
> TaskKey[Seq[String]]("packages") <<= compile in Compile map { analysis =>
> for {
> (srcFile, srcAPI) <- analysis.apis.internal.toSeq
> pkg <- srcAPI.api.packages
> } yield
> pkg.name
> }
>
> I don't think there are any caveats to this, but you should check that it works for Java sources (bug if it doesn't). See also:
>
> http://www.scala-sbt.org/release/api/index.html#sbt.inc.Analysis

Thanks for the fast reply.

Heiko