Hello IP Team. Can have your opinion here.
For starters, I know that they need CQs for the mentioned
The question is what do they do when another project pushes a
different version of the libraries on them? A project may
build against one version of a library and include it in their
downloads. Then, they're combined with another project's bits
in the simultaneous release repository which also contains a
different version of the library.
In this scenario, do they need a new piggy back CQ?
-------- Forwarded Message --------
On 09.02.2015 19:30, Wayne Beaton wrote:
> You do not generally need a CQ for a library that you use indirectly as a result
> of pulling in the bits from another Eclipse project that uses the library
> directly. You only require a CQ for libraries that your project code uses
> directly. Clever reflection tricks constitute direct use.
I have a question about this.
I'm trying to sort out what to do about our (MPC's) slightly convoluted
dependencies to Apache HttpComponents Client and Core. MPC consumes those in
two ways: indirectly via P2 and directly via package imports.
Historically, we haven't pulled in a specific version or included the
library in our download bits/repository, but rely on the platform to provide
a version. I think that's somewhat bad form and plan to change it for Mars
accordingly (piggyback CQs are coming up).
In the meantime, Platform has changed its shipped version between Luna SR1
and SR2. So while nothing has changed in MPC's dependency, it'll technically
run with the new version in SR2. Does this mean I should
a) do nothing for Luna SR2
b) file a piggyback CQ for the new Apache HttpComponents versions
c) dto and request our CQ for the old version to be marked obsolete?
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
The Eclipse Foundation