Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » Fun with fragments...
Fun with fragments... [message #835701] Tue, 03 April 2012 11:09 Go to next message
Daniel Krügler is currently offline Daniel Krügler
Messages: 853
Registered: July 2009
Senior Member
I'm observing unexpected compile behaviour for my "home-brewed"
bundle/fragment pair, I'm working with Eclipse 3.7.2 64-bit Classic
with an x86 JRE set.

a) I have a very simple host bundle, let's name it abc, with the
following manifest.mf:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %Bundle-Name
Bundle-Vendor: %Bundle-Vendor
Bundle-SymbolicName: abc;singleton:=true
Bundle-Version: 1.0.0.-SNAPSHOT
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.eclipse.swt,
org.eclipse.swt.dnd,
org.eclipse.swt.graphics
Bundle-ActivationPolicy: lazy
Eclipse-ExtensibleAPI: true
Export-Package: abc

Please note that the host bundle itself has no sources, because the
complete implementation is provided by a single fragment (This is very
similar to the swt bundle). It nonetheless exports package "abc",
because that is the public API expected to be published by the fragment.

b) I have also written a corresponding fragment restricted for
win32-win32-x86, the manifest.mf is defined:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %Bundle-Name
Bundle-Vendor: %Bundle-Vendor
Bundle-SymbolicName: abc.win32.win32.x86;singleton:=true
Bundle-Version: 1.0.0.-SNAPSHOT
Fragment-Host: abc
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
Eclipse-BundleShape: dir
Import-Package: org.eclipse.swt.internal.ole.win32,
org.eclipse.swt.internal.win32
Export-Package: abc,
abc.win32;x-internal:=true

This fragment bundle contains all the code, in particular the public API
within package abc.

If I have this bundle+fragment as a project in my Eclipse IDE,
everything is fine, which means that any depending plugins (using an
import directive), can resolve the "abc" package.

But when I set a target platform, which contains above bundle plus the
fragment and if I remove the aforementioned projects from the Eclipse
workspace, the expected package resolution does not succeed. I already
tried reloading the target-platform, cleaning the dependent projects
etc. This behaviour differs from all other (non-fragment) bundles that
are part of the target platform.

Does anyone have an idea what is going wrong here? (Let me repeat that I
have checked that the Java-runtime set matches the target platform
requirements, thus it is also an x86 JRE).

Any launcher based on the bundle+fragment starts and uses the
bundle+fragment successfully, so I'm yet not observing any runtime
problems. The real problem for me is, that all developers working at the
dependent bundles have also to ensure that they have the bundle+fragment
project in their workspace. Now, for swt a similar procedure is not
required, even though the architecture is quite similar. Is their
something wrong with any of the manifest.mf's or could that be an
Eclipse-PDE defect?

I would appreciate any suggestions!

Thanks & Greetings from Bremen,

Daniel Krügler
Re: Fun with fragments... [message #855127 is a reply to message #835701] Tue, 24 April 2012 10:47 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6850
Registered: July 2009
Location: Ottawa
Senior Member

When the bundle+fragment are part of your target platform, do you remove both projects from your workspace?

PW


Re: Fun with fragments... [message #855156 is a reply to message #855127] Tue, 24 April 2012 11:10 Go to previous message
Daniel Krügler is currently offline Daniel Krügler
Messages: 853
Registered: July 2009
Senior Member
On 2012-04-24 16:47, Paul Webster wrote:
> When the bundle+fragment are part of your target platform, do you remove
> both projects from your workspace?

I observed problems during two tests consistently:

a) Create a new workspace without importing the corresponding projects,
and set the target platform which contains these. Any project that
depends on the bundle behaves as if the packages where not exported.
Current workaround is to get these projects (both).

b) As the developer of the bundles these were initially part of my
workspace, therefore I did not notice that w/o them resolution did not
work. To test this, I simply closed the corresponding projects and the
same resolution problem as in (a) occurs. Reopening ensures resolution
again.

Putting the things together it seems that both tests give the consistent
but unfortunate result that all my coworkers need both projects checked
out. There is some evidence that this is no normal "caching" problem,
because the problem initially occured at the workspaces of my coworkers
who were not aware of both bundles but simply updated the new target
platform (which contained these bundles, I verified that).

Can anyone confirm or reject this observation?

Thanks,

Daniel Krügler
Previous Topic:Updating a toolbar
Next Topic:Eclipse Help System German
Goto Forum:
  


Current Time: Wed Apr 16 15:53:03 EDT 2014

Powered by FUDForum. Page generated in 0.02517 seconds