Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » Re-Exporting external library best practice
Re-Exporting external library best practice [message #663919] Wed, 06 April 2011 15:49 Go to next message
Sebastian  is currently offline 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

Re: Re-Exporting external library best practice [message #664047 is a reply to message #663919] Thu, 07 April 2011 05:57 Go to previous messageGo to next message
Johan Schulz is currently offline Johan Schulz
Messages: 20
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
Re: Re-Exporting external library best practice [message #664212 is a reply to message #664047] Thu, 07 April 2011 16:38 Go to previous messageGo to next message
Sebastian  is currently offline 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 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
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


Re: Re-Exporting external library best practice [message #666772 is a reply to message #663919] Fri, 22 April 2011 08:31 Go to previous message
Sebastian  is currently offline 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
Previous Topic:Dynamic cacading menu items
Next Topic:Toolbar Change Image Command When Pressed
Goto Forum:
  


Current Time: Sat Aug 23 15:32:21 EDT 2014

Powered by FUDForum. Page generated in 0.08720 seconds