On 14/01/2022 09:08, Ed Merks wrote:
So *how* do you ensure that the necessary/important/right things are
in your own repository? Certainly includeAllDependencies is the big
hammer, but do you really want users to install some snapshot of all
your dependencies? It seems doubtful. The obvious approach is to
include a "missing" plugin in a feature.xml of a feature that is in
your p2 update site because it's mentioned in the category.xml. But
that might not be ideal because you might be fine with a range of
versions and might not want to force your specific version to be
installed (and to be contributed to SimRel, leading to duplicates).
You can also mention such a plugin directly in your category.xml such
that a version is available, but that one is not necessarily the one
that must/will be installed to make your bundles happy. What we did
in Oomph is to include some Orbit dependencies in a test feature that
is included in the category.xml as uncategorized and we don't
contribute the test feature to SimRel so our Orbit requirements will
(hopefully) be satisfied by other projects with more restrictive
version range requirements that those of Oomph...
A similar situation exists for OCL and QVTo.
OCL should use the same version of Guava as 'everyone else' so OCL
relies on the Xtext to provide it without imposing any version bounds.
Known relevant Guava incompatibilities are accommodated by replacing
incompatible functionality with local implementations.
Similarly ASM is re-used from the platform but with a lower bound to
exclude a known API incompatibility. The upper bound was removed after
ASM took to throwing new versions for each new Java version.
However for LPG, which few other projects use, OCL redistributes LPG.
QVTo consumes the same version as OCL.
The imported version may be random, in so far as OCL / QVTo have no idea
which version is in use, but it's consistent and users should see the
version that was tested. Testing of the latest OCL distribution on
Oxygen and later platforms provides some opportunity for detecting
incompatible dependencies.
Over the years, it was my impression that the need to redistribute LPG
was precisely because Orbit was not (transitively) available when
performing an Install New Software... from SimRel.
It would therefore seem that the longstanding and desirable practice of
excluding Orbit has been undermined by who/whatever is providing it. If
nothing else, providing it costs users unnecessary download time on a
large index and may provide many opportunities for ambiguous
better/slower P2 install solutions.
Please, let's revert to our longstanding practice that Orbit is not
transitively available in SimRel.
Regards
Ed Willink
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev