| Re: [cross-project-issues-dev] Disabling Mylyn from SimRel + Removing related Orbit workarounds |
> All the things available in Orbit that are needed by other
projects will then have to come from repositories of other
projects.
with the emphasis on random other projects with no explicit
dependency.
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
