[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Staging for SimRel 2023-06 RC1 is Complete (PLEASE READ SECTION 3rd PARTY BUNDLES)
|
I'd like to note that Tycho 4 contains a new option to filter so called
"provided" items see [1]
That means, if you reference another repository in your category.xml
(see [2] for an example), Tycho will exclude all items that are provided
by this site, even if include all dependencies are enabled.
That way one can produce sites that contain "everything needed" but
still not reproduce what is available in any of the referenced sites.
This feature is quite new, but I still encourage everyone to try it out
and give feedback so this can become a good alternative from maintaining
features just for including something in an updatesite that is
indirectly referenced.
best
Christoph
[1]
https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#new-parameter-for-tycho-p2-repository-pluginassemble-repository
[2]
https://github.com/eclipse-m2e/m2e-core/blob/428661981bcfe567cbed50749cae5a7c16bebef8/org.eclipse.m2e.repository/category.xml#L32-L35
Am 01.06.23 um 09:01 schrieb Ed Merks:
The staging repository content of
https://download.eclipse.org/staging/2023-06/
has been promoted to the following repository for 2023-06 RC1:
https://download.eclipse.org/releases/2023-06 /202306021000/
This is ready for consumption by EPP.
It will become visible in the composite as scheduled Friday, June 2nd,
2023:
https://download.eclipse.org/releases/2023-06
_______________________________________________
STOP INCLUDING 3rd PARTY BUNDLES IN FEATURES
This is the first time in a very long time that we've reduced the number
of duplicates:
https://download.eclipse.org/releases/2023-06/202306021000/buildInfo/archive/download.eclipse.org/releases/2023-06/202306021000/index.html
The most common reason for duplicates (though not the only one) is
including 3rd party bundles in your features, e.g., here the platform
requires one specific version of gson while papyrus another:
In this case, lsp4j is depending on an internal package not exported by
the direct-from-maven version of gson. I wonder if or why that's necessary?
There is a proposal to stop including 3rd party bundles in features:
https://github.com/eclipse/orbit/issues/8#issuecomment-1534255305
I plan to help the platform and other projects stop doing that:
https://github.com/eclipse-platform/eclipse.platform.releng/issues/230#issuecomment-1560452454
For the platform is relatively easy because they're at the bottom of the
food chain so they can just specify to include all transitive
requirements in their repository. For most of us though, we cannot and
should not replicate project content of other Eclipse projects, so we
must take a different approach. My suggestion here is to introduce an
additional "dependencies" feature that's included uncategorized in the
category.xml and to move all 3rd party bundle includes to that feature
(and DO NOT include that feature in any other feature that the user
installs).
You might think, "but I want to be sure that a specific tested version
of some 3rd party dependency is used". Dream on then because there is
no guarantee that OSGi will actually wire your bundles to any specific
3rd party bundle version even if that version is available in the
installation. The wiring will depend only on the version ranges in your
actual bundles, not on the versions included by the features.
Regards,
Ed
_______________________________________________
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
