Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Enhancing plugin dependencies classpath container
Enhancing plugin dependencies classpath container [message #1008360] Tue, 12 February 2013 03:00 Go to next message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
Hello,

I'm writing Eclipse plugins.

In certain circumstances, I have to directly embed librairies inside the plugins. For this I successfully use the "runtime classpath" feature which allows me to add the relative path inside my plugin project's directory.

So the "deployed / running" problem is a solved one.

Now I would like to ease the pain in the "development" side of things: when I want to both work on my plugin and on the contents of the library, I have the library as a regular (non OSGi, non Eclipse plugin) java project in the workspace.
This implies that everytime I make a change to the library's content, I need to re-package it and replace it inside my plugin.

What I'd like is to be able, during development, to have a project dependency : my plugin project --- depends on ---> my java library.

I don't want (don't have the possibility) to transform my library project into a plugin/fragment project.


What I would like is something like being able to extend the "Plugin Dependencies" Classpath Container with non-eclipse-plugin projects while developing.


Any help much appreciated,

--
Laurent Petit
Re: Enhancing plugin dependencies classpath container [message #1008371 is a reply to message #1008360] Tue, 12 February 2013 03:11 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5286
Registered: July 2009
Senior Member
There's a new extension point in 4.3 allowing you to contribute
List<IClassPathEntry> to the PDE-Classpath container.

I've backported the fix in my e(fx)clipse project and patch PDE on the
fly to make it work. You need to use the nightly builds and contribute
an IClasspathContributor.

The problem you'll afterwards have is that you'll still fail at runtime
but maybe the pde.core.bundleClasspathResolvers extension solves this
problem (I've not used it myself so maybe I'm completely wrong) if that
does not work. IIRC Equinox allows you to point to an external location
in the Bundle-Classpath using the external:-keyword.

Tom

[1] http://www.efxclipse.org/

Am 12.02.13 09:00, schrieb Laurent Petit:
> Hello,
>
> I'm writing Eclipse plugins.
>
> In certain circumstances, I have to directly embed librairies inside the
> plugins. For this I successfully use the "runtime classpath" feature
> which allows me to add the relative path inside my plugin project's
> directory.
>
> So the "deployed / running" problem is a solved one.
>
> Now I would like to ease the pain in the "development" side of things:
> when I want to both work on my plugin and on the contents of the
> library, I have the library as a regular (non OSGi, non Eclipse plugin)
> java project in the workspace.
> This implies that everytime I make a change to the library's content, I
> need to re-package it and replace it inside my plugin.
>
> What I'd like is to be able, during development, to have a project
> dependency : my plugin project --- depends on ---> my java library.
>
> I don't want (don't have the possibility) to transform my library
> project into a plugin/fragment project.
>
>
> What I would like is something like being able to extend the "Plugin
> Dependencies" Classpath Container with non-eclipse-plugin projects while
> developing.
>
>
> Any help much appreciated,
>
Re: Enhancing plugin dependencies classpath container [message #1008432 is a reply to message #1008371] Tue, 12 February 2013 07:57 Go to previous messageGo to next message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
Thank you Thomas,

I have great hopes in pde.core.bundleClasspathResolvers. Seems like it may indeed allow me to add "plain old java projects" to the container. Will give it a try ASAP.

--
Laurent
Re: Enhancing plugin dependencies classpath container [message #1008435 is a reply to message #1008432] Tue, 12 February 2013 08:29 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5286
Registered: July 2009
Senior Member
Please note that there are 2 things:

a) pde.core.bundleClasspathResolvers which is for runtime (available
with Juno) lookk up
b) a new extension point only in Kepler which allows to modify the
JDT-Classpath-Container so that your project compiles (available on
with Kepler or through my backport in e(fx)clipse)

Tom

Am 12.02.13 13:57, schrieb Laurent Petit:
> Thank you Thomas,
> I have great hopes in pde.core.bundleClasspathResolvers. Seems like it
> may indeed allow me to add "plain old java projects" to the container.
> Will give it a try ASAP.
>
Re: Enhancing plugin dependencies classpath container [message #1008552 is a reply to message #1008435] Tue, 12 February 2013 18:39 Go to previous messageGo to next message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
OK Thomas, thanks for the clarification.
Before I dig more into this, I'd like to have one more ambiguity (at least in my understanding) clarified:

Are both of your points a) & b) related to the development environment, or / or also when the bundle is installed in a final "production" environment. It's late here, so please excuse me if the question makes no sense.

Because I can ask my plugin developers to switch to Kepler (for instance), but not my user base.

And also because I intend to not necessarily use the PDE (nor Tycho) to "build" my plugin+feature+updatesite deliverable (I may come up with a simplified toolchain of my own) => so what's present while developing may not be what's present when deployed (when deployed, I'll have the binary products of the depended upon java projects embedded inside my plugin).
Re: Enhancing plugin dependencies classpath container [message #1008553 is a reply to message #1008552] Tue, 12 February 2013 19:07 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5286
Registered: July 2009
Senior Member
Both extension points work SOLELY at dev-time when you export your
product you need to bundle the external lib like do you already today!

Might I ask why you are not developing the external lib as an
OSGi-Bundle, all an OSGi has is the META-INF-Entries so it why not
simply make it a PDE-Project?

Tom

Am 13.02.13 00:39, schrieb Laurent Petit:
> OK Thomas, thanks for the clarification.
> Before I dig more into this, I'd like to have one more ambiguity (at
> least in my understanding) clarified:
>
> Are both of your points a) & b) related to the development environment,
> or / or also when the bundle is installed in a final "production"
> environment. It's late here, so please excuse me if the question makes
> no sense.
>
> Because I can ask my plugin developers to switch to Kepler (for
> instance), but not my user base.
>
> And also because I intend to not necessarily use the PDE (nor Tycho) to
> "build" my plugin+feature+updatesite deliverable (I may come up with a
> simplified toolchain of my own) => so what's present while developing
> may not be what's present when deployed (when deployed, I'll have the
> binary products of the depended upon java projects embedded inside my
> plugin).
Re: Enhancing plugin dependencies classpath container [message #1008557 is a reply to message #1008552] Tue, 12 February 2013 19:44 Go to previous messageGo to next message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
Thomas,

I played with pde.core.bundleClasspathResolvers.

I was able to add/contribute an additional absolute IPath to the pde required plugins classpath container:
    			entries = jProject.getRawClasspath();
			for (int i = 0; i < entries.length; i++) {
				IPath source = entries[i].getPath();
				if (source.toString().equals("org.eclipse.pde.core.requiredPlugins")) {
					l.add(new Path("/Users/laurentpetit/.m2/repository/org/eclipse/jetty/jetty-server/7.6.1.v20120215/jetty-server-7.6.1.v20120215.jar"));
					m.put(source,l);
				}
			}

but at runtime, no luck, trying to instanciate a jetty Server() fails Sad

Seems my fallback solution for runtime is the external: for Bundle-Classpath. A little bit unfortunate since I hoped I would not have to manipulate the MANIFEST between development phase and deployment phase.

[Updated on: Tue, 12 February 2013 19:44]

Report message to a moderator

Re: Enhancing plugin dependencies classpath container [message #1008559 is a reply to message #1008553] Tue, 12 February 2013 20:02 Go to previous messageGo to next message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
Thomas Schindl wrote on Tue, 12 February 2013 19:07

Might I ask why you are not developing the external lib as an
OSGi-Bundle, all an OSGi has is the META-INF-Entries so it why not
simply make it a PDE-Project?


Sure.

I maintain Counterclockwise, a plugin for developing Clojure in Eclipse.
A large part of Counterclockwise itself is written in Clojure.
A "Clojure runtime" ties together all namespaces in the classloader where Clojure is started.
The current design of Counterclockwise is a bunch of Eclipse plugins.

E.G.
ccw.core ---> depends on --> ccw.clojure
ccw.debug ---> depends on ---> ccw.core (which exports its packages)
ccw.core ---> depends on --> paredit (which provides paredit support for the editor, but is also made available in maven repos for other Clojure tools)

And to make all this work, a lot of tricky things are done so that code, executed "normally" from the ccw.clojure bundle classloader, etc. (we once used Buddy policy mechanism, etc.)

It now appears that there is still some instability in this construction, and I want to cut down on extra maintenance / bug hunting costs and come back to the core added value of Counterclockwise.

So I'm experimenting with doing a compromise with "OSGi purity" in favor of a simpler to reason about and maintain design:

- a single bundle, ccw.core
- for managing complexity, some current bundles will not have their source code merged with ccw.core sources. They will just become plugin fragments with ccw.core as their hosts.
- more and more "classic" clojure libraries, available in maven repositories, are used by CCW. I don't want to manually or automatically create OSGi versions of these dependencies. I just want to use them -> so I created a simple automation task which unzips them all in the ccw.core/lib/ folder, and add this folder to the runtime classpath of ccw.core.

The next step is why I'm asking questions here: during development, it is sometimes easier to have one or more of ccw.core's maven dependencies as regular java projects, managed by maven, and not in an "exploded binary form" in the ccw.core/lib/ folder.
I can easily change my automation task to not add some libraries to the ccw.core/lib/ folder during development.
And now I'm trying to make my development environment aware of the presence of the dependency in a workspace project instead ...

Hope this is clear ...
Re: Enhancing plugin dependencies classpath container [message #1008581 is a reply to message #1008557] Wed, 13 February 2013 02:59 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5286
Registered: July 2009
Senior Member
Well you can trick the classloader in Equinox using Adapter Hooks but I
don't think this is a good solution to your problem, another option to
not modify the MANIFEST.MF is to add your external stuff as a fragment
because those will share the same classloader.

Tom

Am 13.02.13 01:44, schrieb Laurent Petit:
> Thomas,
> I played with pde.core.bundleClasspathResolvers.
>
> I was able to add/contribute an additional absolute IPath to the pde
> required plugins classpath container:
>
> entries = jProject.getRawClasspath();
> for (int i = 0; i < entries.length; i++) {
> IPath source = entries[i].getPath();
> if
> (source.toString().equals("org.eclipse.pde.core.requiredPlugins")) {
> l.add(new
> Path("/Users/laurentpetit/.m2/repository/org/eclipse/jetty/jetty-server/7.6.1.v20120215/jetty-server-7.6.1.v20120215.jar"));
>
> m.put(source,l);
> }
> }
>
> but at runtime, no luck, trying to instanciate a jetty Server() fails :(
>
> Seems my fallback solution for runtime is the external: for
> Bundle-Classpath. A little bit unfortunate since I hoped I would not
> have to manipulate the MANIFEST between development phase and deployment
> phase.
Re: Enhancing plugin dependencies classpath container [message #1008592 is a reply to message #1008581] Wed, 13 February 2013 03:52 Go to previous messageGo to next message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
Thomas Schindl wrote on Wed, 13 February 2013 02:59
Well you can trick the classloader in Equinox using Adapter Hooks but I
don't think this is a good solution to your problem, another option to
not modify the MANIFEST.MF is to add your external stuff as a fragment
because those will share the same classloader.

Tom


Hello Tom,

yes, I want to avoid Equinox Adapter Hooks because AFAICT, I would then impose on all my userbase the burden of having a specific launch configuration for Eclipse (something to place in a config.ini file) => Seems unacceptable, since I'm not writing an RCP app but a regular Eclipse plugin.

As far as the fragments are concerned: that is indeed the solution I've adopted for still splitting parts of CCW internals into several easier-to-manage Eclipse projects.
I'm not sure I want to do that for all the dependencies of CCW. I'll think about it again, maybe with a little bit of automation ...
Re: Enhancing plugin dependencies classpath container [message #1008603 is a reply to message #1008592] Wed, 13 February 2013 04:15 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5286
Registered: July 2009
Senior Member
Am 13.02.13 09:52, schrieb Laurent Petit:
> Thomas Schindl wrote on Wed, 13 February 2013 02:59
>> Well you can trick the classloader in Equinox using Adapter Hooks but I
>> don't think this is a good solution to your problem, another option to
>> not modify the MANIFEST.MF is to add your external stuff as a fragment
>> because those will share the same classloader.
>>
>> Tom
>
>
> Hello Tom,
> yes, I want to avoid Equinox Adapter Hooks because AFAICT, I would then
> impose on all my userbase the burden of having a specific launch
> configuration for Eclipse (something to place in a config.ini file) =>
> Seems unacceptable, since I'm not writing an RCP app but a regular
> Eclipse plugin.

If you install your plugins using p2 it makes the adapter hook entry for
you! e(fx)clipse use adapter hooks and it works perfectly.

Tom
Re: Enhancing plugin dependencies classpath container [message #1008964 is a reply to message #1008603] Thu, 14 February 2013 03:16 Go to previous message
Laurent Petit is currently offline Laurent Petit
Messages: 21
Registered: December 2010
Junior Member
Hello Thomas,

Now that I know (thanks to you!) that Hooks can be discovered without user intervention, I'm beginning to consider a "clever" (or is it?) way to do things in the deployed environment: why not create a generic Hook whose purpose would be to read a maven dependencies descriptor available at runtime for my bundle, and have it enhance the bundle classpath "on the fly" with maven dependencies located in the user's ~/.m2/repository local repository ? Thanks to maven Aether which could be embedded into my hook plugin, I could also download from the Internet, "on the fly", the missing dependencies (probably not much after the plugin has been downloaded from a regular p2 updatesite, so Internet access would probably be there anyway, and this would have to happen only once in a while, e.g. when installing a new version of the plugin, or after the user has manually scratched its ~/.m2/repository for some reason ...) ?
Previous Topic:sequenceNumber in target platform file
Next Topic:How can I create a "Source Folder" browser
Goto Forum:
  


Current Time: Sat Aug 23 09:29:59 EDT 2014

Powered by FUDForum. Page generated in 0.06236 seconds