Might as well use all these release train versioning and
backward-compatibility rules to both project-specific and
cross-project advantage.
Scott,
Of course people would have to pay attention to announcements,
but yes, such announcements would be a good thing.
With Oomph we're being slightly bad, but in a good way I
think... While we rely on this component, we don't actually
contribute it to SimRel under the assumption that someone else
will. Given we depend on the Platform and ECF and that we have
permissive version ranges, that assumption works fine. As such,
Oomph is never responsible for the duplicates.
If one looks at the current report:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2020-03/index.html
and filter the Installable Unit's section to "Duplicate", you
can see the 53 bundles that are have duplicate versions. Many
with even with 3 versions. Lucene looks to be especially
popular!
org.apache.lucene.core 6.1.0.v20170814-1820
org.apache.lucene.core 7.1.0.v20171214-1510
org.apache.lucene.core 7.5.0.v20181003-1532
org.apache.lucene.core 8.0.0.v20190404-1858
org.apache.lucene.core 8.4.1.v20200122-1459
"We" really ought to do a better job coordinating this,
especially for components that tend to leak into the API and
causing wiring problems.
I expect M3 to arrive with unsigned content:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559740
I'm not sure if any actions are being taken to fix this before
the release; this in in the CDT product, so users will notice.
Web tools fixed their problem. Thanks Nick Boldt!
Also there will continue to be invalid licenses:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553883
Action has been taken, but getting it into a build and
contributing that seems to have stalled.
I've not harped on the rather massive duplication of common
components because after almost 1/2 a year, we've not gotten
past the "signed content and valid licenses" phase; we're darned
close though! Coordinating the common components will be much
more challenging, and I expect it will not actually happen until
the problems it causes rears its ugly head to the end-users.
Regards,
Ed
On 26.02.2020 00:54, Scott Lewis
wrote:
ECF updates httpclient/httpcomponents and deps (e.g. codec)
in response to explicit requests from platform...e.g. [1] in
this case.
I'm not sure how to effect in terms of process, but it might
be good for other release train projects that consume
httpclient (e.g. egit) if somehow the platform notified them
(or just the cross projects list) when it makes a request like
[1]. This so that only one version of
httpclient/httpcomponents/deps (codec) end up in release repo
as multiple versions have caused problems in past.
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=560228
On 2/25/2020 2:40 AM, Matthias Sohn
wrote:
I updated the JGit/EGit contribution
and this now comes with the latest versions of commons
codec (1.13.0) and Apache httpclient (4.5.10) and httpcore
(4.4.12)
I need to update the JGit/EGit contribution to the
release train repository, will do this asap
Hi folks,
org.apache.httpcomponents.httpclient
has 4.5.2, 4.5.6 and 4.5.10*
org.apache.commons.codec has
versions 1.9.0, 1.10.0 and 1.13.0*
Of those only the * ones are in
current orbit.
What is the way to resolve this?
At the moment, AFAICT for example,
egit's simrel contribution requires
jgit
(org.eclipse.jgit.http.apache.feature.group)
which requires o.a.h.httpclient
4.5.6 which requires o.a.c.codec
1.10.
This is causing me problems for
CDT as when I tried to upgrade our
target platform to Eclipse
Platform's M3 contribution, I can no
longer resolve egit because current
orbit does not have the org.apache
dependencies that egit/jgit needs.
This is not a new problem,
2019-12 had 2 versions of each of
the above libraries, now we are at
three of them.
Any suggestions?
Thanks
Jonah
_______________________________________________ cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or 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 change your delivery options, retrieve your
password, or 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 change your delivery options, retrieve your password, or 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 change your delivery options, retrieve your password, or 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 change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev