Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Adding jars to a bundle's classpath
Adding jars to a bundle's classpath [message #538887] Tue, 08 June 2010 18:42 Go to next message
Del Myers is currently offline Del Myers
Messages: 82
Registered: July 2009
Member
Hello,

I have a pretty specific problem that may or may not have a solution. I need to
use some third-party jars in my plug-in. I know that the typical way of doing
this is to just wrap the jars into their own plug-in and depend on it. But due
to licensing and installation problems (the tools that I'm using also have their
own install process because they depend on some custom environment variables), I
can't do that. Is there any way that I can get my plug-in to search for the jars
that I'm looking for and add them to the classpath? Thanks.

Del
Re: Adding jars to a bundle's classpath [message #538893 is a reply to message #538887] Tue, 08 June 2010 19:38 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

If you have to pick up the 3rd party jars that are already installed in
the system then you either have to fool with your RCP classpath:

http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/reference/misc/runtime-options.html

Or you can set a property -DLIB_LOCATION=/absolute/path/to/lib_dir and
use external: in your MANIFEST.MF. The you either have to 1) add the
jars to your Bundle-ClassPath or 2) create their own bundles with their
Bundle-ClassPath

Bundle-Classpath: .,external:$LIB_LOCATION$/useful.jar

Later,
PW

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


Re: Adding jars to a bundle's classpath [message #538894 is a reply to message #538893] Tue, 08 June 2010 20:07 Go to previous messageGo to next message
Del Myers is currently offline Del Myers
Messages: 82
Registered: July 2009
Member
I'm writing this stuff as a plug-in for Eclipse, so I don't really want to muck
with the RCP classpath. The other problem is that my plug-in won't know about
the third party jars until after it starts to run. It has to run to look for
them, and the user may have installed them anywhere so it might come down to the
user manually entering the location of the jars if all else fails. Do you
suggest that I programatically edit the manifest and save it with the location
of the external jars held in there and then tell the user to restart Eclipse?
I'm not 100% sure how the bundle start-up process works. I imagine that the
manifest is loaded before the bundle starts, in which case I would have to have
the LIB_LOCATION environment variable set before Eclipse starts, and I'm not
keen on editing environment variables. Doing anything to change the Eclipse
start up process is not ideal. So manually entering the actual directory
location in the manifest might be better.

Del

On 08/06/2010 4:38 PM, Paul Webster wrote:
> If you have to pick up the 3rd party jars that are already installed in
> the system then you either have to fool with your RCP classpath:
>
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/reference/misc/runtime-options.html
>
>
> Or you can set a property -DLIB_LOCATION=/absolute/path/to/lib_dir and
> use external: in your MANIFEST.MF. The you either have to 1) add the
> jars to your Bundle-ClassPath or 2) create their own bundles with their
> Bundle-ClassPath
>
> Bundle-Classpath: .,external:$LIB_LOCATION$/useful.jar
>
> Later,
> PW
>
Re: Adding jars to a bundle's classpath [message #539039 is a reply to message #538894] Wed, 09 June 2010 08:15 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Del Myers wrote:
> I'm writing this stuff as a plug-in for Eclipse, so I don't really want
> to muck with the RCP classpath. The other problem is that my plug-in
> won't know about the third party jars until after it starts to run. It
> has to run to look for them, and the user may have installed them
> anywhere so it might come down to the user manually entering the
> location of the jars if all else fails. Do you suggest that I
> programatically edit the manifest and save it with the location of the
> external jars held in there and then tell the user to restart Eclipse?
> I'm not 100% sure how the bundle start-up process works. I imagine that
> the manifest is loaded before the bundle starts, in which case I would
> have to have the LIB_LOCATION environment variable set before Eclipse
> starts, and I'm not keen on editing environment variables. Doing
> anything to change the Eclipse start up process is not ideal. So
> manually entering the actual directory location in the manifest might be
> better.

Trying to edit a deployed manifest is not reliable. It might be a jar,
and more importantly it might be in a read-only location.

If you supply external:$LIB_LOCATION$/useful.jar then the user can
supply -DLIB_LOCATION=/path/to/lib/folder ... either on the command line:
eclipse -vmargs -DIB_LOCATION=/path/to/lib/folder
or by editing the eclipse.ini and adding it after the -vmargs argument:
-DIB_LOCATION=/path/to/lib/folder

Potentially another option. Start up your plugin (or a 3rd party lib
finder plugin), and have the user enter the library location. Generate
a bundle into your state location with the correct MANIFEST.MF to
represent the jars in that location, and then use OSGi to install and
start that bundle.

Now you have a Bundle object and you can use loadClass(*) to access it.
Or if your main bundle starts later, it can now see that bundle.

See org.osgi.framework.Bundle.start(int),
org.osgi.framework.BundleContext.installBundle(String, InputStream),
org.osgi.service.packageadmin.PackageAdmin.refreshPackages(B undle[])

TestInstallUtil uses this to install test bundles into the running eclipse:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.test s/Eclipse%20UI%20Tests/org/eclipse/ui/tests/dynamicplugins/T estInstallUtil.java?view=co


PW



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


Re: Adding jars to a bundle's classpath [message #539141 is a reply to message #539039] Wed, 09 June 2010 14:00 Go to previous messageGo to next message
Del Myers is currently offline Del Myers
Messages: 82
Registered: July 2009
Member
Thank you very much. This gives me some ideas. The problem remains, though, that
I would need my "Application Code" bundle to depend on my "3rd Party Jars"
bundle in order for it to gain access to the classes that I need. Otherwise
Eclipse and p2 won't let my plug-in install (unsatisfied dependencies). Should I
supply a dummy bundle that pretends to supply the packages? Then on start-up, I
could look for the right location of the jars, generate a new new bundle with
the same id as the "3rd Part Jars" bundle but with a new version, stop the old
bundle, install the new one, and then start it. But, if the old bundle is in a
read-only location how can I be guaranteed to be able to install the new bundle?

That all seems very convoluted and fragile to be honest. I wish that there were
just some way to add the library location to the classloader as you are able to
with URL class loaders.

Asking the user to edit the eclipse.ini, or add a -D.... to their command line
is too much. You can't really expect users to do any of that--you can't even
expect programmers to do that. My experience is that if a feature doesn't work
out-of-the-box, then people won't use it. There can't be an install barrier.

Thank you very much for all your help so far.

Del

On 09/06/2010 5:15 AM, Paul Webster wrote:
> Del Myers wrote:
>> I'm writing this stuff as a plug-in for Eclipse, so I don't really
>> want to muck with the RCP classpath. The other problem is that my
>> plug-in won't know about the third party jars until after it starts to
>> run. It has to run to look for them, and the user may have installed
>> them anywhere so it might come down to the user manually entering the
>> location of the jars if all else fails. Do you suggest that I
>> programatically edit the manifest and save it with the location of the
>> external jars held in there and then tell the user to restart Eclipse?
>> I'm not 100% sure how the bundle start-up process works. I imagine
>> that the manifest is loaded before the bundle starts, in which case I
>> would have to have the LIB_LOCATION environment variable set before
>> Eclipse starts, and I'm not keen on editing environment variables.
>> Doing anything to change the Eclipse start up process is not ideal. So
>> manually entering the actual directory location in the manifest might
>> be better.
>
> Trying to edit a deployed manifest is not reliable. It might be a jar,
> and more importantly it might be in a read-only location.
>
> If you supply external:$LIB_LOCATION$/useful.jar then the user can
> supply -DLIB_LOCATION=/path/to/lib/folder ... either on the command line:
> eclipse -vmargs -DIB_LOCATION=/path/to/lib/folder
> or by editing the eclipse.ini and adding it after the -vmargs argument:
> -DIB_LOCATION=/path/to/lib/folder
>
> Potentially another option. Start up your plugin (or a 3rd party lib
> finder plugin), and have the user enter the library location. Generate a
> bundle into your state location with the correct MANIFEST.MF to
> represent the jars in that location, and then use OSGi to install and
> start that bundle.
>
> Now you have a Bundle object and you can use loadClass(*) to access it.
> Or if your main bundle starts later, it can now see that bundle.
>
> See org.osgi.framework.Bundle.start(int),
> org.osgi.framework.BundleContext.installBundle(String, InputStream),
> org.osgi.service.packageadmin.PackageAdmin.refreshPackages(B undle[])
>
> TestInstallUtil uses this to install test bundles into the running eclipse:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.test s/Eclipse%20UI%20Tests/org/eclipse/ui/tests/dynamicplugins/T estInstallUtil.java?view=co
>
>
>
> PW
>
>
>
Re: Adding jars to a bundle's classpath [message #539149 is a reply to message #539141] Wed, 09 June 2010 15:02 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Del Myers wrote:
> Thank you very much. This gives me some ideas. The problem remains,
> though, that I would need my "Application Code" bundle to depend on my
> "3rd Party Jars" bundle in order for it to gain access to the classes
> that I need. Otherwise Eclipse and p2 won't let my plug-in install
> (unsatisfied dependencies). Should I supply a dummy bundle that pretends
> to supply the packages? Then on start-up, I could look for the right
> location of the jars, generate a new new bundle with the same id as the
> "3rd Part Jars" bundle but with a new version, stop the old bundle,
> install the new one, and then start it. But, if the old bundle is in a
> read-only location how can I be guaranteed to be able to install the new
> bundle?

Well, that's different. Adding it to a classloader on the fly means
only using reflection. If you want to have real code ...

If you make the Require-Bundle optional and provide one during compile,
your compile will work. If the requirement is optional, then you should
be able to install even if it is not already in their environment. You
just have to make sure your "import 3rd party jar" plugin runs before
any code in your plugin tries to load one of the 3rd party classes.
That means ensure your real plugin will never start until later in the
cycle, or using tricks to keep initial code and code that uses the 3rd
party libs separate.




You can still create a URLClassLoader off of your plugin class loader
and load the jar ... you just need to use reflection or common
interfaces to interact with it.

Something like http://www.eclipse.org/datatools/ must do something
similar, as you must be able to tell it about JDBC connectors after the
datatools plugins are running. Although this situation is most like the
URLClassLoader one, as their code interacts with a common set of
interfaces that are available by default.



less useful: There is a p2 equivalent of install handlers called
touchpoints. If you can write your update in terms of touchpoints then
as part of installing your plugins the system should be able to set a
property in the configuration and/or eclipse.ini as part of your
touchpoint, never having to bother the users. In theory if you could
write you own touchpoint then you could ask your users during an install
.... but I don't believe you can create your own touchpoints yet :-)

http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions




> That all seems very convoluted and fragile to be honest. I wish that
> there were just some way to add the library location to the classloader
> as you are able to with URL class loaders.

Actually, it's very stable and locked down ... the way enterprise
application like it. The ability for code to bootstrap extra libs and
just run them is the double-edged sword ... flexibility, but if there's
a problem in the system, well, it's got some untested version of the
library in there so there's a lot of debugging goin' on :-)

>
> Asking the user to edit the eclipse.ini, or add a -D.... to their
> command line is too much. You can't really expect users to do any of
> that--you can't even expect programmers to do that. My experience is
> that if a feature doesn't work out-of-the-box, then people won't use it.
> There can't be an install barrier.

There is a usability problem with it, but it's not just the the bundles
but the licenses and your particular distribution. From your usecase I
gather you're not distributing a product, but simply a plugin for
eclipse that depends on 3rd party libraries you can't distribute.

A product can control its eclipse.ini, and the installer can set up
anything (not uncommon for all apps), including asking the user to enter
the lib location during install and updating the file for them. That
removes some of the usability concerns as it all had to be done up front.

You could pay for the appropriate license to distribute the libraries
you need, removing the problem all together ... but if you're providing
an open source plugin, that's also not a good solution :-) Or they may
be GPLed code which you probably wouldn't be able to get commercial
licenses for anyway (some projects are dual licensed ... but not many).

>
> Thank you very much for all your help so far.
>

I hope it goes well.

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


Re: Adding jars to a bundle's classpath [message #539151 is a reply to message #539141] Wed, 09 June 2010 15:05 Go to previous messageGo to next message
Del Myers is currently offline Del Myers
Messages: 82
Registered: July 2009
Member
On further investigation, none of this seems to work. My plug-ins will not build
when I use Bundle-ClassPath: external:.... It seems that Eclipse won't look for
them at all during the build regardless of whether I use environment variables
or absolute paths. It simply will not find the external jars. Any ideas?

On 09/06/2010 11:00 AM, Del Myers wrote:
> Thank you very much. This gives me some ideas. The problem remains,
> though, that I would need my "Application Code" bundle to depend on my
> "3rd Party Jars" bundle in order for it to gain access to the classes
> that I need. Otherwise Eclipse and p2 won't let my plug-in install
> (unsatisfied dependencies). Should I supply a dummy bundle that pretends
> to supply the packages? Then on start-up, I could look for the right
> location of the jars, generate a new new bundle with the same id as the
> "3rd Part Jars" bundle but with a new version, stop the old bundle,
> install the new one, and then start it. But, if the old bundle is in a
> read-only location how can I be guaranteed to be able to install the new
> bundle?
>
> That all seems very convoluted and fragile to be honest. I wish that
> there were just some way to add the library location to the classloader
> as you are able to with URL class loaders.
>
> Asking the user to edit the eclipse.ini, or add a -D.... to their
> command line is too much. You can't really expect users to do any of
> that--you can't even expect programmers to do that. My experience is
> that if a feature doesn't work out-of-the-box, then people won't use it.
> There can't be an install barrier.
>
> Thank you very much for all your help so far.
>
> Del
>
> On 09/06/2010 5:15 AM, Paul Webster wrote:
>> Del Myers wrote:
>>> I'm writing this stuff as a plug-in for Eclipse, so I don't really
>>> want to muck with the RCP classpath. The other problem is that my
>>> plug-in won't know about the third party jars until after it starts to
>>> run. It has to run to look for them, and the user may have installed
>>> them anywhere so it might come down to the user manually entering the
>>> location of the jars if all else fails. Do you suggest that I
>>> programatically edit the manifest and save it with the location of the
>>> external jars held in there and then tell the user to restart Eclipse?
>>> I'm not 100% sure how the bundle start-up process works. I imagine
>>> that the manifest is loaded before the bundle starts, in which case I
>>> would have to have the LIB_LOCATION environment variable set before
>>> Eclipse starts, and I'm not keen on editing environment variables.
>>> Doing anything to change the Eclipse start up process is not ideal. So
>>> manually entering the actual directory location in the manifest might
>>> be better.
>>
>> Trying to edit a deployed manifest is not reliable. It might be a jar,
>> and more importantly it might be in a read-only location.
>>
>> If you supply external:$LIB_LOCATION$/useful.jar then the user can
>> supply -DLIB_LOCATION=/path/to/lib/folder ... either on the command line:
>> eclipse -vmargs -DIB_LOCATION=/path/to/lib/folder
>> or by editing the eclipse.ini and adding it after the -vmargs argument:
>> -DIB_LOCATION=/path/to/lib/folder
>>
>> Potentially another option. Start up your plugin (or a 3rd party lib
>> finder plugin), and have the user enter the library location. Generate a
>> bundle into your state location with the correct MANIFEST.MF to
>> represent the jars in that location, and then use OSGi to install and
>> start that bundle.
>>
>> Now you have a Bundle object and you can use loadClass(*) to access it.
>> Or if your main bundle starts later, it can now see that bundle.
>>
>> See org.osgi.framework.Bundle.start(int),
>> org.osgi.framework.BundleContext.installBundle(String, InputStream),
>> org.osgi.service.packageadmin.PackageAdmin.refreshPackages(B undle[])
>>
>> TestInstallUtil uses this to install test bundles into the running
>> eclipse:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.test s/Eclipse%20UI%20Tests/org/eclipse/ui/tests/dynamicplugins/T estInstallUtil.java?view=co
>>
>>
>>
>>
>> PW
>>
>>
>>
>
Re: Adding jars to a bundle's classpath [message #539167 is a reply to message #539149] Wed, 09 June 2010 15:25 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Paul Webster wrote:

> less useful: There is a p2 equivalent of install handlers called
> touchpoints. If you can write your update in terms of touchpoints then
> as part of installing your plugins the system should be able to set a
> property in the configuration and/or eclipse.ini as part of your
> touchpoint, never having to bother the users. In theory if you could
> write you own touchpoint then you could ask your users during an install
> ... but I don't believe you can create your own touchpoints yet :-)
>
> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions
>

I take that back, custom touchpoints are supported on 3.6:
http://dev.eclipse.org/newslists/news.eclipse.technology.equ inox/msg06111.html

PW

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


Re: Adding jars to a bundle's classpath [message #539168 is a reply to message #539151] Wed, 09 June 2010 15:29 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Del Myers wrote:
> On further investigation, none of this seems to work. My plug-ins will
> not build when I use Bundle-ClassPath: external:.... It seems that
> Eclipse won't look for them at all during the build regardless of
> whether I use environment variables or absolute paths. It simply will
> not find the external jars. Any ideas?

Won't compile in eclipse, or won't build?

For "won't compile" try the PDEEditor>Build tab. At the bottom there's
Extra Classpath Libraries section. You might have to include them there.

What did you do, create a plugin project with a manifest and use
external:/path/to/lib/userful.jar for where it is installed in your system?

PW



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


Re: Adding jars to a bundle's classpath [message #539179 is a reply to message #539168] Wed, 09 June 2010 17:22 Go to previous messageGo to next message
Del Myers is currently offline Del Myers
Messages: 82
Registered: July 2009
Member
It doesn't compile.

I did as you said: create a plugin project with a manifest and use
external:/path/to/lib/userful.jar for where it is installed in my system. The
PDE doesn't seem to recognize the "external" modifier, though.

I was able to get it to compile by using the Build tab of the PDE editor, but I
had to create another "Library" plug-in that had a linked folder to the library
location before the PDE would let me add the jars. It seems that there should be
another way of doing it, and I am just missing it.

Del

On 09/06/2010 12:29 PM, Paul Webster wrote:
> Del Myers wrote:
>> On further investigation, none of this seems to work. My plug-ins will
>> not build when I use Bundle-ClassPath: external:.... It seems that
>> Eclipse won't look for them at all during the build regardless of
>> whether I use environment variables or absolute paths. It simply will
>> not find the external jars. Any ideas?
>
> Won't compile in eclipse, or won't build?
>
> For "won't compile" try the PDEEditor>Build tab. At the bottom there's
> Extra Classpath Libraries section. You might have to include them there.
>
> What did you do, create a plugin project with a manifest and use
> external:/path/to/lib/userful.jar for where it is installed in your system?
>
> PW
>
>
>
Re: Adding jars to a bundle's classpath [message #699104 is a reply to message #539179] Wed, 20 July 2011 16:34 Go to previous messageGo to next message
Nadeem Aboobaker is currently offline Nadeem Aboobaker
Messages: 20
Registered: July 2009
Junior Member
Was there a resolution to this problem?

In my development workspace in Eclipse, I'm pointing to a target platform that has plugins that specify the Bundle Classpath with 3rd party jars using the "external" keyword like so:
external:$library.home$/lib/foo.jar,
external:$library.home$/lib/bar.jar
I have plugin projects with Java code that uses classes located in the 3rd party jars. My workspace's PDE build is unable to resolve these classes, so the build fails and I am unable to launch or debug the Eclipse application. I tried adding a -Dlibrary.home=... location in my dev Eclipse's eclipse.ini, but that didn't help. I can't find a way to specifiy the "library.home" variable so the jars can be found and the classes resolved.

I can run the code in my plugins if I build the plugin projects from the command line using the PDE Ant Runner, edit the eclipse.ini to specify the -Dlibrary.home=... location, then launch the target platform's eclipse.exe. The "external" jars and "library.home" variable all get resolved properly and everything works like it should.

So the problem is that I can't really do proper development, since my development workspace is basically unusable due to the compile errors. I'd prefer not to set the "Extra Classpath Entries" on the Build tab of each plugin or add External JARs to the Libraries tab of the Java Build Path for each plugin project. I have hundreds of external JARs, and about 50 plugins, so it's not really feasible to maintain a list of jars in my plugins' MANIFEST.MF files and then also in the plugins/projects build metadata. All of the information is available (external jars specified in the MANIFEST.MF and library.home value specified in the environment variables), so I'm hoping there is a way to get all of this working.

Thanks for any help,
Nadeem


Del Myers wrote on Wed, 09 June 2010 17:22
It doesn't compile.

I did as you said: create a plugin project with a manifest and use
external:/path/to/lib/userful.jar for where it is installed in my system. The
PDE doesn't seem to recognize the "external" modifier, though.

I was able to get it to compile by using the Build tab of the PDE editor, but I
had to create another "Library" plug-in that had a linked folder to the library
location before the PDE would let me add the jars. It seems that there should be
another way of doing it, and I am just missing it.

Del

Re: Adding jars to a bundle's classpath [message #780361 is a reply to message #699104] Tue, 17 January 2012 12:00 Go to previous message
Jan Mauersberger is currently offline Jan Mauersberger
Messages: 119
Registered: July 2009
Senior Member
I more or less had exactly the same problem and background as Del in the
original posting back in 2010. With the help of this thread I get it
working this way:

* use the way proposed by Paul, i.e. external classpath entries in the
Manifest
* for PDE build use a library bundle that is only referenced optional
and will not go into the final product
* in startup code of my bundle I check for the existence of the library
bundle, in case it's not there I further check for certain preferences
that do locate the libraries to include, if they are not there, nothing
is done and classes are not loaded (user is typically informed that he
has to configure things)
* a special preferences page lets the user enter the file locations and
forces a workbench restart
* on next startup the preferences are set and I install a fragment on
the fly

That seems to be an adequate solution, at least for me and our build and
development process.

However, I face only one issue: when forcing a restart, the bundle is
resumed after restart at an very early stage (more or less before my
application is started and can ask for a workspace). However, since my
code that creates the fragment on the fly relies on preferences, a
workspace is needed at that early stage which forces the default
workspace ;-(

Any idea? I remember that Paul wrote about exactly that "resume" issue
and that I would have to do something during shutdown what I cannot find
it anymore.

Jan

> Was there a resolution to this problem?
>
> In my development workspace in Eclipse, I'm pointing to a target
> platform that has plugins that specify the Bundle Classpath with 3rd
> party jars using the "external" keyword like so:
> external:$library.home$/lib/foo.jar,
> external:$library.home$/lib/bar.jar
> I have plugin projects with Java code that uses classes located in the
> 3rd party jars. My workspace's PDE build is unable to resolve these
> classes, so the build fails and I am unable to launch or debug the
> Eclipse application. I tried adding a -Dlibrary.home=... location in my
> dev Eclipse's eclipse.ini, but that didn't help. I can't find a way to
> specifiy the "library.home" variable so the jars can be found and the
> classes resolved.
>
> I can run the code in my plugins if I build the plugin projects from the
> command line using the PDE Ant Runner, edit the eclipse.ini to specify
> the -Dlibrary.home=... location, then launch the target platform's
> eclipse.exe. The "external" jars and "library.home" variable all get
> resolved properly and everything works like it should.
>
> So the problem is that I can't really do proper development, since my
> development workspace is basically unusable due to the compile errors.
> I'd prefer not to set the "Extra Classpath Entries" on the Build tab of
> each plugin or add External JARs to the Libraries tab of the Java Build
> Path for each plugin project. I have hundreds of external JARs, and
> about 50 plugins, so it's not really feasible to maintain a list of jars
> in my plugins' MANIFEST.MF files and then also in the plugins/projects
> build metadata. All of the information is available (external jars
> specified in the MANIFEST.MF and library.home value specified in the
> environment variables), so I'm hoping there is a way to get all of this
> working.
>
> Thanks for any help,
> Nadeem
>
>
> Del Myers wrote on Wed, 09 June 2010 17:22
>> It doesn't compile.
>>
>> I did as you said: create a plugin project with a manifest and use
>> external:/path/to/lib/userful.jar for where it is installed in my
>> system. The PDE doesn't seem to recognize the "external" modifier,
>> though.
>>
>> I was able to get it to compile by using the Build tab of the PDE
>> editor, but I had to create another "Library" plug-in that had a
>> linked folder to the library location before the PDE would let me add
>> the jars. It seems that there should be another way of doing it, and I
>> am just missing it.
>>
>> Del
>
>
Previous Topic:Crash while synchronizing SVN workspace
Next Topic:Multiple hosts for a single Fragment
Goto Forum:
  


Current Time: Thu Jul 24 00:38:11 EDT 2014

Powered by FUDForum. Page generated in 0.01805 seconds