Home » Eclipse Projects » Plugin Development Environment (PDE) » Enhancing plugin dependencies classpath container
|
Re: Enhancing plugin dependencies classpath container [message #1008371 is a reply to message #1008360] |
Tue, 12 February 2013 08:11 |
Thomas Schindl Messages: 6651 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 #1008559 is a reply to message #1008553] |
Wed, 13 February 2013 01:02 |
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 #1008964 is a reply to message #1008603] |
Thu, 14 February 2013 08:16 |
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 ...) ?
|
|
|
Goto Forum:
Current Time: Tue Sep 24 17:48:45 GMT 2024
Powered by FUDForum. Page generated in 0.06846 seconds
|