| relative library paths to jars outside of plugins [message #52765] |
Wed, 09 November 2005 11:28  |
Eclipse User |
|
|
|
Originally posted by: david_dean.comcast.net
Specifying a relative path for <library>, as with "whatever.jar" in the
plugin.xml snippet below, allows the plugin to include a jar which isn't
in the plugin. This seems like it would be a bug, or is there a
legitimate reason that this is allowed?
Thanks,
David
<?xml version="1.0" encoding="UTF-8" ?>
<?eclipse version="3.0"?>
<plugin id="com.acme.foo" name="%pluginName" version="0.0.1"
provider-name="%pluginProvider">
<runtime>
<library name="../../../../lib/whatever.jar">
<export name="*" />
</library>
</runtime>
</plugin>
-- also posted on "platform"
|
|
|
|
| Re: relative library paths to jars outside of plugins [message #53786 is a reply to message #53305] |
Wed, 30 November 2005 12:56  |
| Eclipse User |
|
|
|
Originally posted by: david_dean.comcast.net
Jeff,
Thanks for the response. I do realize that this usage is deprecated, but
what I'm really trying to determine is whether this behavior is
intentional or a bug. If 3.1 has an equivalent mechanism then this
implies that it is a "feature" to allow plugins/bundles to reference
external jars (or other resources).
This is surprising to me since it seems to break the packaging model of
a plugin/bundle, specifically:
- it is apparently ok for a plugin/bundle to rely on the structure of a
file system outside itself
- a plugin/bundle could be updated, either intentionally or by accident,
by changing files that are outside the plugin/bundle, unbeknownst to the
eclipse update mechanisms.
I am involved in a project where this behavior is being exploited and
I'm trying to figure out whether that is ok or not.
-David
Jeff McAffer wrote:
> Hmmm, does seem like a bug but more generally the plugin.xml approach to
> plugin definition is now (in 3.2) deprecated in favour of using manifest.mf.
> 3.1 included an experimental mechanism using external: URLs and system
> properties/env vars to define classpath entries from outside the specifiying
> bundle.
>
> Jeff
>
> "David Dean" <david_dean@comcast.net> wrote in message
> news:dkt83e$pvh$1@news.eclipse.org...
>
>>Specifying a relative path for <library>, as with "whatever.jar" in the
>>plugin.xml snippet below, allows the plugin to include a jar which isn't
>>in the plugin. This seems like it would be a bug, or is there a
>>legitimate reason that this is allowed?
>>
>>Thanks,
>>
>>David
>>
>><?xml version="1.0" encoding="UTF-8" ?>
>> <?eclipse version="3.0"?>
>> <plugin id="com.acme.foo" name="%pluginName" version="0.0.1"
>>provider-name="%pluginProvider">
>> <runtime>
>> <library name="../../../../lib/whatever.jar">
>> <export name="*" />
>> </library>
>> </runtime>
>> </plugin>
>>
>>-- also posted on "platform"
>
>
>
|
|
|
| Re: relative library paths to jars outside of plugins [message #53992 is a reply to message #53786] |
Thu, 01 December 2005 20:55 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
Hey David,
3.1 indeed has this feature but it is very much in the *experimental* realm.
It is included because several people in the community had usecases where
they had JARs in the file system that they could not move yet wanted those
JARs to be integrated into Equinox as bundles. The simplest approach was to
let them reference the external JARs from the Bundle-ClassPath of their
bundle.
This does not make it recommended or supported. The tooling does not
support it and you have to go to some hoops to get it to work. We were
going to add some poison gas and spike traps but the lawyers would not let
us.
Jeff
"David Dean" <david_dean@comcast.net> wrote in message
news:438DE7BB.30308@comcast.net...
> Jeff,
>
> Thanks for the response. I do realize that this usage is deprecated, but
> what I'm really trying to determine is whether this behavior is
> intentional or a bug. If 3.1 has an equivalent mechanism then this
> implies that it is a "feature" to allow plugins/bundles to reference
> external jars (or other resources).
>
> This is surprising to me since it seems to break the packaging model of
> a plugin/bundle, specifically:
> - it is apparently ok for a plugin/bundle to rely on the structure of a
> file system outside itself
> - a plugin/bundle could be updated, either intentionally or by accident,
> by changing files that are outside the plugin/bundle, unbeknownst to the
> eclipse update mechanisms.
>
> I am involved in a project where this behavior is being exploited and
> I'm trying to figure out whether that is ok or not.
>
> -David
>
> Jeff McAffer wrote:
> > Hmmm, does seem like a bug but more generally the plugin.xml approach to
> > plugin definition is now (in 3.2) deprecated in favour of using
manifest.mf.
> > 3.1 included an experimental mechanism using external: URLs and system
> > properties/env vars to define classpath entries from outside the
specifiying
> > bundle.
> >
> > Jeff
> >
> > "David Dean" <david_dean@comcast.net> wrote in message
> > news:dkt83e$pvh$1@news.eclipse.org...
> >
> >>Specifying a relative path for <library>, as with "whatever.jar" in the
> >>plugin.xml snippet below, allows the plugin to include a jar which isn't
> >>in the plugin. This seems like it would be a bug, or is there a
> >>legitimate reason that this is allowed?
> >>
> >>Thanks,
> >>
> >>David
> >>
> >><?xml version="1.0" encoding="UTF-8" ?>
> >> <?eclipse version="3.0"?>
> >> <plugin id="com.acme.foo" name="%pluginName" version="0.0.1"
> >>provider-name="%pluginProvider">
> >> <runtime>
> >> <library name="../../../../lib/whatever.jar">
> >> <export name="*" />
> >> </library>
> >> </runtime>
> >> </plugin>
> >>
> >>-- also posted on "platform"
> >
> >
> >
|
|
|
Powered by
FUDForum. Page generated in 0.03860 seconds
Home