Also using Import-Package allows for provider substitution. You don't
really know who the provider of the package dependency is by looking at a
bundle manifest in isolation.
Tom
From: Wayne Beaton wa...@eclipse.org
To: cross-project-issues-dev@eclipse.org,
Date: 05/17/2013 02:06 PM
Subject:Re: [cross-project-issues-dev] Libraty piggy-back CQs
Sent by:cross-project-issues-dev-boun...@eclipse.org
The issue is one of tracking who is using what third-party library.
Right now, the tools that I use to scan the downloads directory almost do a
good enough job to eliminate piggyback CQs altogether. Almost. The problem
is that the tool only detects libraries that are actually distributed by
the project. It works by file name alone. It fails to detect libraries that
are pulled in from Orbit, for example.
I think that the solution is to scan bundles for references to third-party
libraries, but I'll need some p2 magic to sort that out, I think. Bash just
isn't going to cut it.
Does anybody know what p2 magic we can use to query a bundle for a
definitive list of dependencies (including bundle and package imports?)
Of course, this doesn't help us if a project isn't distributing OSGi
bundles...
Wayne
On 05/17/2013 02:35 PM, Ed Willink wrote:
Hi
Thanks; that's clear but is hardly sensible. I have a handful of PB
CQs to raise and I suspect many other projects must do too.
Since we are strongly encouarged to track the latest Orbit version,
shouldn't there be an auto-PB CQ for any project that has a PB CQ for
an Orbit library?
Currently I see
20 Guava 10.x PB CQs
2 Guava 11.x PB CQs
0 Guava 12.x PB CQs
4 Guava 13.x PB CQs
0 Guava 14.x PB CQs
With M7 changing the preferred Guava release to 12 that makes for 20
out of 20 projects in breach of IP policy.
Regards
Ed Willink
On 17/05/2013 19:20, Wayne Beaton wrote:
I believe that the Contribution Questionnaire page in the wiki
[1] answers this. If it is unclear, either take a crack at
clarifying it yourself or let me know I can take another run at
it.
The short version is that you need CQ for any library that
project code uses directly. You do not require a CQ for any
library that is used indirectly via another Eclipse project. I
spelled this out in more detail on the wiki page.
CQs are version-specific. You need a CQ for each version of a
library that project code uses.
It doesn't matter where project code comes from. If a tool like
Xtext generates project code (i.e. code that goes into your
source code repository, or dynamically-generated code that gets
distributed in compiled form) that uses a library, this is
considered a direct reference.
HTH,
Wayne
[1]
http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire
On 05/17/2013 02:31 AM, Ed Willink wrote:
Hi Wayne
Can you clarify the policy on library piggy-back CQs?
For MDT/OCL we initially used Guava indirectly through
Xtext and so might not need a PB CQ although we did raise
one since Xtext auto-generates source code for us with
direct calls to the Injector class. Subsequently we have
some manually written code that exploits Guava too.
Our PB CQ has not updated from version 10, although Guava
in Orbit is charging along through 11, 12 with 14 on the
horizon.
Are we at fault through not raising more PB CQs? Do I
misunderstand the policy? Is the policy inappropriate for
major evolving libraries?
Regards
Ed Willink
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6332 - Release
Date: 05/17/13
