Eclipse Community Forums: Rich Client Platform (RCP) » Re-Exporting external library best practice

Help

Home

Home » Eclipse Projects » Rich Client Platform (RCP) » Re-Exporting external library best practice

Show: Today's Messages :: Show Polls :: Message Navigator

Re-Exporting external library best practice [message #663919]

Wed, 06 April 2011 15:49

Sebastian
Messages: 5
Registered: April 2011

Junior Member

Hello,

I want to achieve the following:
I have a number of external libraries each living in a normal plugin created from an existing JAR.
As I need a set of them in various plugins, I would like to create a base plugin having the set of plugins as dependencies and exporting them.

As this approach works fine with normal bundles it fails for external libraries. The dependency page allows me to mark a Jar package to be exported as well.

I would like to know, if this is possible and how or which alternative strategies are available.

Below you can see the MANIFEST from the plugin which requires the set (its only one) of plugins containing external libraries.

Best Regards

Sebastian

Here ist the MANIFEST.MF:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Base
Bundle-SymbolicName: sample.base
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: sample.base.Activator
Require-Bundle: org.eclipse.core.runtime,
sample.commons-collections;bundle-version="1.0.0";visibility:=reexport
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: sample.base

Report message to a moderator

Re: Re-Exporting external library best practice [message #664047 is a reply to message #663919]

Thu, 07 April 2011 05:57

Johan Mising name
Messages: 19
Registered: November 2010

Junior Member

Hi,

there is an Wizard you can use "Create Plugin from existing Jar-Archive".
You can select all jars you like to provide to your other plugins and it creates an nice plugin for which you just have to add the dependency in the other plugins.

Works quite well, the only point i miss, i have to remove the class files manually or recreate the hole plugin if one of the containing jars change or i want to add/remove one.
If you figure that out drop an reply Smile

Regards
Johan

Report message to a moderator

Re: Re-Exporting external library best practice [message #664212 is a reply to message #664047]

Thu, 07 April 2011 16:38

Sebastian
Messages: 5
Registered: April 2011

Junior Member

Hello Johan,

thank you for your reply, but it doesn't help me.

I have probably badly explain my case. Creating a plugin from a Jar is what I do.

My base plugin depends on a number of plugins created from existing JARS.

My problem is that the reexport from the base plugin does not work.

Best Regards

Sebastian

[Updated on: Thu, 07 April 2011 16:39]

Report message to a moderator

Re: Re-Exporting external library best practice [message #664337 is a reply to message #664212]

Fri, 08 April 2011 08:19

Paul Webster
Messages: 6831
Registered: July 2009
Location: Ottawa

Senior Member

So you have pluginA (exports package a) and pluginB (exports b). You
create pluginC which requires pluginA and pluginB and you mark them as
re-export.

the problem: pluginD requires pluginC, yet can't see a.RunAway and
b.Whatever ?

The above works for me. Things you can check: 1) is your pluginA
exporting the package? 2) your pluginC requires-bundle pluginA and
re-exports? 3) your pluginD requires-bundle your pluginC?

In the OSGi world, import-package is preferred as a best practice over
require-bundle.

You've effectively tied your bundles to pluginC version 1.0.0. If you
need to supply a patch to pluginA to 1.0.1, you'll have to up-version
pluginC 1.0.1 and make sure everyone can consume it.

ex: pluginC version will change with *every* deployment that includes
one or more changes in the libraries below it. You can never bump a
re-exported library version without also bumping pluginC.

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Platform_Expression_Framework
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Re-Exporting external library best practice [message #666772 is a reply to message #663919]

Fri, 22 April 2011 08:31

Sebastian
Messages: 5
Registered: April 2011

Junior Member

Hello Paul,

thank you for sharing the details. I will improve my project following this idea.

The problem I had initially is by the way more trivial. When creating a plugin from an existing JAR, choosing the unzip option will need to a non functional plugin. It just misses the dot in the bundle classpath.
Solution:
On the runtime tab in the plugin view, choose the new button and input a dot.
As a consequence the MANIFEST.MF should contain the following line of code

Bundle-ClassPath: .

I would consider this a minor bug which teases fresh users of eclipse RCP.

Best Regards
Sebastian

Report message to a moderator

Previous Topic:	Dynamic cacading menu items
Next Topic:	Toolbar Change Image Command When Pressed

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Jun 18 01:34:48 EDT 2013