[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] Disabling Mylyn from SimRel + Removing related Orbit workarounds
|
You can also include bundles in your category.xml no need for a feature.
I just wonder if not Orbit itself should contribute its latest release
to simrel and thus participate in sim-rel process directly.
That would mean I never need to add Orbit directly but can only depend
on what is at the simrel-repo isn't it?
Am 14.01.22 um 10:08 schrieb Ed Merks:
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