| Re: [cross-project-issues-dev] Disabling Mylyn from SimRel + Removing related Orbit workarounds |
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
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
