[
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 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
