I'm not sure these are entirely good ideas, though certainly
sensible in principle. The devil is in the details...
In the other related thread (about Passage) it was suggested
to "mirror dependencies in project's own p2 repo" but that
isn't an entirely clear statement. In particular, one might
take that literally and too broadly. E.g., I don't want my
Oomph repository to mirror all its dependencies
because I don't want my repository to include dependencies
from all these other projects that Oomph directly depends
upon, other than Orbit things "of course," though why Orbit
and not the other ones? So I definitely do not want
include all "includeAllDependencies".

Without guidance on what should be in your own
repository, why it should be in your own repository,
and how you should ensure that it ends up in your own
repository, we have a team of downstream people with open
questions.
Suppose we remove Orbit from the above graph, which is the
stated goal. All the things available in Orbit that are
needed by other projects will then have to come from
repositories of other projects. Again, that's fine and good
and is the goal. But, Mylyn could change its aggrcon to
reference the Orbit repo that resolves their requirements.
That would clearly not improve things. It would mask the
other problems in the other projects because the aggregator
doesn't care from where things are resolved. I guess there is
a rule that no one should do that? Mylyn could also change
their repository to reference (or compose) the Orbit
repository, which would have the same effect, but we'd not
even see that looking at the aggrcons themselves. Would that
be wrong or against some rule?
The bottom line is that I'm sure there are many
projects that depend on "Orbit contributions" that are in fact
contributed by other projects rather their own project, but we
only notice this "Orbit dependency" issue when some project is
the only one with a dependency that is satisfied by neither
itself nor any other project. E.g., Passage is the only one
using log4j2. So, for example, it's okay (apparently) if my
repo doesn't include Orbit dependencies that are
included/provided by the Platform, until the Platform
contributes a version that doesn't satisfy my requirements,
and then it's suddenly not okay because suddenly we notice.
One might even argue it's better that I rely on the Platform
contributing my Orbit dependencies because that way I won't
include a different version leading to the multiple versions
problem and I'll notice when I should move to a new version...
I mention this because it will be surprising later when we
must disable some project only to find out it's the only one
contributing some specific "Orbit dependency" on which a
number of other projects depend.
All that being said, the what and why should be
somewhat more clear to the projects themselves if you ask
yourself, What other repositories must be available in order
for the user to install one more more of your features? Note
that the answer is not at all related to SimRel, but if your
answer is that as long as the SimRel repo is available, it's
fine, then your answer might well be circular...
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...
Regards,
Ed
On 14.01.2022 09:50, Christoph
Läubrich wrote:
If
Tycho is used it is probably the easiest to enable
https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies
to get the best user experience and fulfill this requirement
without any additional actions.
Am 14.01.22 um 08:43 schrieb Alexander Fedorov:
Hi Jonah,
Since Passage was never depending from Mylyn it was
surprising to see it disabled. As I understood, it was done
because Passage does not mirror all the used Orbit bundles
to its p2 site.
Please don't get me wrong, but the gap between notification
[1] and action seems a bit tight to me: about 1 day without
technical space to fix it.
Perhaps I missed something important during the past years
but the rule to always mirror Orbit dependencies to the
component p2 site was neither clearly articulated nor
enforced previously.
To avoid future misunderstanding I've created a ticket [2]
to improve Project Handbook regrading SimRel participation.
@Wayne, @Alexander please invest your time to polish the
formulation of this [new?] constraint for Eclipse projects
that are willing to participate SimRel.
Thank you,
AF
[1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189570
[2] https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/177
1/13/2022 11:20 PM, Jonah Graham пишет:
On Thu, 13 Jan 2022 at 08:47, Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
wrote:
On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov,
<akurtako@xxxxxxxxxx>
wrote:
I would dare to say that as long as the
workarounds are in
simrel nothing will get fixed - it's time to face
reality.
Probably correct, but I don't have the nerve to
disable (or
knowledge/time to fix) Mylyn.
Hi folks,
It is time to remove the temporary workarounds. When I had
a look today I realised that more and more projects are
relying on the temporary workaround initially put in place
for Mylyn.
Over a year ago I filed numerous bugs asking projects to
fix their contributions, some projects were very
responsive and others I have not heard back from.
Therefore for M2 I plan to disable all projects from
SimRel that aren't up to date or have otherwise started
relying on these workarounds. I will submit the following
gerrits[1,2] after 2022-03 M1 is done. Please see the
gerrits for what is disabled. I attempted to only disable
features where possible and not entire contributions.
The affected projects are (with some comments):
- Mylyn (fully disabled Bug 569078)
- Passage (only one feature, so fully disabled)
- DTP (many features, lots because Lucene 7.x is no longer
provided by Eclipse Platform? + Bug 569181)
- WTP (Bug 568136)
- m2e-wtp (JPA related code)
- PDT (Composer feature needs org.apache.commons.exec)
- soa-bpel (depends on disabled WTP features)
[1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189612
- Remove the Orbit direct contribution to SimRel
workaround
[2] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189614
- Remove Mylyn
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com/>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan
Eberle, Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef
Schuermann
Aufsichtsrat/Supervisory Board: Michael Neuhaus
(Vors./chairman), Harald Goertz, Eric Swehla
Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24,
44536 Lünen (Germany)