[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] How to ensure that "import-package" results in getting packages only from bundles specified in "require-bundle"?
|
On 05/04/2016 01:58 PM, Tom Bryan (tombry) wrote:
Require-Bundle and Import-Package serve the same purpose in different
ways.
Require-Bundle specifies that the current plug-in depends on those
specific bundles. At runtime, if it doesn't find those bundles, it will
fail to load. Eclipse makes those bundles (and any of their exported
packages) available to your plug-in.
Import-Package specifies that the current plug-in depends on the
availability of a package, but it does not specify which plug-in should
provide that package.
Import-Package provide looser coupling and permits your plug-in to run
with different providers of that same package. The user could potentially
install one of a number of providers that supply the required packages.
You definitely don't need to use both for the same dependency. Use one or
the other.
You can still use Import-Package if you prefer the looser coupling. But
if you're concerned about which version you'll get, just specify version
constraints on the relevant Import-Package constraints.
If you permit your users to run updates or install new plug-ins themselves
or to install your feature into other Eclipse environments, you should
probably be specifying at least the minimum tested/supported versions for
all of your dependencies, no matter which approach you use.
I this this is telling me that I really have no choice but to directly
embed the antlr jar (using "maven-dependency-plugin") into each plugin
that requires those classes (fortunately, it does appear that only one
of my plugins requires those classes). I am assuming that if a class in
a bundle is looking for a class, if it finds it in the same bundle
(albeit referenced by "Build-Classpath"), it will not attempt to resolve
those classes in any other bundle?
Version constraints won't help me, as the checkstyle bundle is packaging
the same version of antlr that I need.
---Tom
On 5/4/16, 12:24 PM, "tycho-user-bounces@xxxxxxxxxxx on behalf of David M.
Karr" <tycho-user-bounces@xxxxxxxxxxx on behalf of
davidmichaelkarr@xxxxxxxxx> wrote:
On 05/04/2016 08:49 AM, Jonah Graham wrote:
At this point, it's looking like my only viable option is to use the
"maven-dependency-plugin"'s "copy" task within each plugin that
requires the antlr jar (there may be two plugin components that require
it), which will avoid the need for the "import-package" specification.
Yes, this is ugly, especially if I need to do it in more than one
plugin component. Ugly is better than a fatal error.
But that sounds like you will have the same jar loaded by two
different bundles and two different classloaders? That is allowed, but
will definitely lead to weird things if those bundles share any data.
For example if Bundle A creates a org.antlr.Foo then Bundle B does
instanceof org.antlr.Foo on that instance, the answer will be false.
If that happened, I think it would be worse than just returning "false"
>from that comparison. I imagine that would also result in a linkage
error. Fortunately, I'm fairly certain none of the Antlr objects are
passed between my plugin components.
Can you work around the problem and do a require bundle instead of
import package?
Well, that's interesting. I assumed at first that that wouldn't work.
I have been doing both "require-bundle" for the bundle that provides the
antlr jar, along with "import-package" for the antlr packages. I just
tried a simple test of removing the antlr jars from the "import-package"
directive, and Eclipse didn't complain, and Tycho built it
successfully. However, those are the easy tests. The really annoying
part of this is that the "linkage error" doesn't happen all of the
time. I'll do some testing of these results.
That said I don't think I am understanding your problem, so if the
above makes no sense I will bow out of this conversation rather than
further muddy the waters.
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
On 4 May 2016 at 16:34, David M. Karr <davidmichaelkarr@xxxxxxxxx>
wrote:
On 05/04/2016 07:49 AM, Jonah Graham wrote:
Hi David,
Try this:
1- git clone https://git.eclipse.org/r/orbit/orbit-recipes
2- cd to antlr/org.antlr.runtime_4.5.1
3- run mvn clean package
You now have a proper OSGi bundle in the target directory.
See the README for more details, in your clone root or here
https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/README.md
Ok. If I'm understanding this correctly, I believe this won't make any
difference.
It doesn't matter if I have a "proper" OSGi bundle or an OSGi bundle
composed of jars obtained from "maven-dependency-plugin". The crux of
the
problem is that if the dependent plugin has an "import-package"
specification for "org.antlr....", there are some undetermined
circumstances
where some of those references are resolved at runtime using the
classes in
the checkstyle bundle (which I'm not specifying as a dependency
anywhere),
and some are resolved with the bundle I've constructed. This results
in a
"linkage error".
At this point, it's looking like my only viable option is to use the
"maven-dependency-plugin"'s "copy" task within each plugin that
requires the
antlr jar (there may be two plugin components that require it), which
will
avoid the need for the "import-package" specification. Yes, this is
ugly,
especially if I need to do it in more than one plugin component. Ugly
is
better than a fatal error.
Alternatively, as I stated in the base note, if there was some way to
ensure
that the classes are only resolved using the bundle I specify, I could
avoid
the previous solution. I've noticed the "uses" qualifier on
"export-package". This seems related, but perhaps not quite what I
need.
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
On 4 May 2016 at 15:10, David M. Karr <davidmichaelkarr@xxxxxxxxx>
wrote:
I obviously need to learn more about this. The latest version in a
public
Orbit repo is older than 4.5.1, and I need 4.5.1. I don't
understand how
to
use what you're showing me here.
On 05/03/2016 11:45 PM, Jonah Graham wrote:
HI David,
Have you had any luck simply making a proper bundle with the version
of
ANTLR you require following the recipe in orbit:
https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/antlr/org.antlr
.runtime_4.5.1
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
On 4 May 2016 at 00:30, David M. Karr <davidmichaelkarr@xxxxxxxxx>
wrote:
I have an Eclipse plugin codebase that uses an ANTLR parser. One
(perhaps
two) of the several plugins references classes in the antlr
packages.
I wasn't able to find the required ANTLR version in a p2 repo, so I
have
one plugin whose only purpose is to use the
"maven-dependency-plugin" to
specify the dependencies I need to copy, and I have
"build-classpath"
entries in the manifest to point to the downloaded jars. I then set
this
plugin as a dependency of the other plugins that require the ANTLR
classes,
along with "import-package" to specify the antlr packages required
by
the
plugin.
This seems conceptually correct, but what I'm finding is that if I
do a
(say) "require-bundle" of bundle "foo" that defines the "com.foo"
package,
along with an "import-package" of "com.foo", it's entirely possible
that
if
some other bundle in the Eclipse OSGi runtime container exports the
"com.foo" package, I could very well get the classes from that other
bundle,
instead of the bundle I specifically required.
Specifically, I'm finding that the "checkstyle" bundle apparently
uses
ANTLR and actually exports those packages (for what reason I can't
imagine).
When the bundle in my application ends up randomly getting those
classes
from the checkstyle bundle, I end up with "linkage error" fatal
errors.
So, is there some way I can specify in my plugin manifest that when
I
say
"import-package" for "com.foo", I can specify that I ONLY want to
get
that
package from a specific bundle?
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from
this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from
this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
