Quantcast

ToolingAPI as OSGi bundle

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ToolingAPI as OSGi bundle

Radim Kubacki
Should we build our Tooling API JAR with OSGi compatible manifest? IMO this would be a good thing and it can simplify bundling into OSGi containers/Eclipse. 

We would only need to add some attributes

Export-Package:
Implementation-Title:
Implementation-Version: 
Bundle-Version:
Bundle-Name: 
Bundle-SymbolicName:
Import-Package: org.slf4j

Note that the only direct dependency SLF4J-API is already OSGi compatible (and slf4j-simple too).

-Radim

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ToolingAPI as OSGi bundle

Ioan Eugen Stan
H,

I think that's a good thing since you'll be able to see the
dependencies more clearly. I can help with this, coding or just
testing . My recommendation is to use bnd [1] to build the manifest.
It uses code and bytecode introspection to solve all imports/exports.
It does the right job 99% cases for me. I use gradle bundle plugin in
my projects which relies on bnd, however it's defaults are to make
packages private.

Regards,

[1] http://aqute.biz/Code/bnd
[2] https://github.com/TomDmitriev/gradle-bundle-plugin

2014-11-11 14:40 GMT+02:00 Radim Kubacki <[hidden email]>:

> Should we build our Tooling API JAR with OSGi compatible manifest? IMO this
> would be a good thing and it can simplify bundling into OSGi
> containers/Eclipse.
>
> We would only need to add some attributes
>
> Export-Package:
> Implementation-Title:
> Implementation-Version:
> Bundle-Version:
> Bundle-Name:
> Bundle-SymbolicName:
> Import-Package: org.slf4j
>
> Note that the only direct dependency SLF4J-API is already OSGi compatible
> (and slf4j-simple too).
>
> -Radim
>



--
Ioan Eugen Stan
0720 898 747

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ToolingAPI as OSGi bundle

Radim Kubacki
Thanks, I originally thought about adding the attributes manually because toolingApi has customized build that takes output of jar task and runs jarjar to create self-contained binary. The manifest updated by bnd is lost in that transformation. But using the plugin [2] and restoring manifest content seems like best way to produce expected content. 

BTW: we should ask the plugin author to put it on plugins.gradle.org so I filed https://github.com/TomDmitriev/gradle-bundle-plugin/issues/20 :-)

Radim

On Tue, Nov 11, 2014 at 2:23 PM, Ioan Eugen Stan <[hidden email]> wrote:
H,

I think that's a good thing since you'll be able to see the
dependencies more clearly. I can help with this, coding or just
testing . My recommendation is to use bnd [1] to build the manifest.
It uses code and bytecode introspection to solve all imports/exports.
It does the right job 99% cases for me. I use gradle bundle plugin in
my projects which relies on bnd, however it's defaults are to make
packages private.

Regards,

[1] http://aqute.biz/Code/bnd
[2] https://github.com/TomDmitriev/gradle-bundle-plugin

2014-11-11 14:40 GMT+02:00 Radim Kubacki <[hidden email]>:
> Should we build our Tooling API JAR with OSGi compatible manifest? IMO this
> would be a good thing and it can simplify bundling into OSGi
> containers/Eclipse.
>
> We would only need to add some attributes
>
> Export-Package:
> Implementation-Title:
> Implementation-Version:
> Bundle-Version:
> Bundle-Name:
> Bundle-SymbolicName:
> Import-Package: org.slf4j
>
> Note that the only direct dependency SLF4J-API is already OSGi compatible
> (and slf4j-simple too).
>
> -Radim
>



--
Ioan Eugen Stan
0720 898 747

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Loading...