Re: [tycho-user] How to ensure that "import-package" results in getting

["Tom Bryan (tombry)" <tombry@xxxxxxxxx>]

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.

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