Eclipse Orbit
Replies: 4 comments 9 replies
-
|
I'm not clear how this works for the SimRel Orbit user. Yesterday, anything from Orbit would be re-exported by a true SimRel content. To use anything else from Orbit required an explicit paste of an Orbit repo into the 'works-with' install dialog. Tomorrow, I understand that these re-exports should be terminated to avoid competitive duplication. Does that mean that both SimRel and Orbit will be built-in 'works-with' locations, so that 'contact all sites' works perfectly? Or does the SimRel aggregator detect all the 'Orbit misses' and automatically include all actually required Orbit content into the SimRel repo? |
Beta Was this translation helpful? Give feedback.
-
|
No, nothing in Orbit provides touch points that would add any Orbit update site to any installation; Orbit never did (as far as I know) and never will do that. Yes, I believe EPP adds SimRel update sites. The CBI p2 aggregator as used by SimRel uses the p2 planner as if it were creating an installation that requires all bundles and all features specified in all Contributions. It uses all update sites of all Contributions to compute all the bundles and features that satisfy the transitive requirements of the explicitly includes bundles and features. No Orbit site is is contributed to SimRel so nothing will automatically come from Orbit. A miss is a failure and will fail validation. Orbit must be consumed by the projects and must be available in their update sites to end up in the aggregation. |
Beta Was this translation helpful? Give feedback.
-
|
Great. OCL 6.19.0M2 pushed to SimRel without an LPG-including feature. |
Beta Was this translation helpful? Give feedback.
-
|
I still see this one:
|
Beta Was this translation helpful? Give feedback.
-
|
Hm. Consider a specific example. OCL needs and re-distributes LPG from Orbit. If I follow the advice and OCL stops contributing a feature including LPG (from Orbit) to SimRel, what will provide a SimRel feature referencing the Orbit. i.e if today I search for LPG in 2023-12 - https://download.eclipse.org/releases/2023-12, I find nothing. Currently it is hidden within an OCL feature. Once OCL stops re-distributing LPG, SimRel must do so, sensibly with a feature whose name includes lpg allowing users to install lpg from SimRel's LPG from Orbit rather than SimRel's OCL's LPG from Orbit. Yes, the aggregator will fail if a contribution fails to include Orbit; just the same as yesterday, but that was to reference for the LPG re-distribution. How is SimRel taking on board the need to provide the shared LPG in SimRel so that installing OCL automatically pulls in LPG from SimRel's Orbit rather than SimRel's OCL? It seems to me that: Either the aggregator synthesizes a from-Orbit feature or features to distribute each shared Orbit contribution no longer provided by regular project features. Or Orbit must be a built-in works-with imposing the additional cost of loading the Orbit index for just about any Help->Install New Software.... Otherwise the aggregator will build SimRel just fine, but any attempt to install with the basic works-with will fail. |
Beta Was this translation helpful? Give feedback.
-
|
As with last time, it would be good to keep a discussion thread intact, rather than start a new thread as you've done here. You appear to be asking SimRel questions rather than Orbit questions This confuses me because nothing you describe was being done by Obit before and definitely nothing like what you describe is something Orbit will do in the future. The LPG bundle was never on my radar because it was never migrated to have an EBR Orbit recipe. When I search for it, I find it:
If your project requires it, then you must consume it and you must provide it to SimRel via your update site. As I said, Orbit provides nothing to SimRel and will not start doing so. The user only seems the SimRel repository and it will only ever be transitively complete... I suspect you've confused the recommendation to "not include 3rd party bundles in the feature you contribute to SimRel" to a situation where all the required bundles are no longer in your update site. That should not be the case. LPG needs to remain in your update site either because you include it in a feature (one that is not transitively included in SimRel) but rather is included in the category.xml, or you include LPG in the category.xml directly. The only potential Orbit issue here is that you need LPG but don't have it. I think it's this one: https://repo1.maven.org/maven2/lpg/runtime/java/2.0.17-v201004271640/ Is that what you need? Will this discussion conclude if it's available in the orbit-aggregation? Orbit update sites are purely intended for consumption by projects, not for consumption by SimRel and not for consumption by end-users... |
Beta Was this translation helpful? Give feedback.
-
|
In order to create a self-contained p2-repo with minimal size I recommend the new features of the latest Tycho version to automatically filter-out artifacts provided in referenced repositories and to autoatmatically add references to those repos used in the target-platform (which should not be floating targets in this case: We already use it in m2e: |
Beta Was this translation helpful? Give feedback.
-
|
I'm certainly confused. On cross-project-dev you directed questions to be here not on cross-project-dev. While, yes, my concern is not about what is in Orbit, my concern is about your sensible intent to avoid multiple re-distribution from Orbit by terminating the potentially duplicate re-distribution by each project individually. Yes, each project should continue to re-distribute from their own Update Site. Yes, LPG is once again in Orbit (thanks). But what I fail to understand is how the aggregator will ensure that SimRel takes over the responsibility to re-distribute LPG on behalf of OCL. |
Beta Was this translation helpful? Give feedback.
-
|
We've been through this before. There is a reply to a comment and there is a new comment as underlined here:
I was simply suggesting yet again that you use "Write a reply" rather than "Write a comment" because the former creates thread of related replies such that there would currently be a single comment with multiple replies rather than 3 comments, all from you, all about the same topic.
As I mentioned, the aggregator uses the p2 planner... So suppose that I removed all of OCLs contributions except the org.eclipse.ocl bundle. The aggregation will still contain LPG because org.eclipse.ocl requires it:
If I look at the Aggregated Repository, I can see which update site(s) contain LPG, i.e., where did it come from:
So you can see that LPG is included in the aggregation even if there is no OCL feature included. Moreover, if you look at what is contributed to the aggregation from OCL:
It's more than just the one bundle that was explicitly specified. Why? Because other things depend on these OCL bundles, e.g., QVTD:
While we're discussing SimRel and the aggregator, more relevant here is that Orbit too is using the aggregator to create orbit-aggregation. So that process too uses the p2 planner which ensures that the orbit-aggregation repository is transitively complete with respect to requirements:
Well, almost complete, except for org.eclipse.jdt.core.compiler.batch which comes from the Platform/JDT:
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry if this is not the right place, I'm not sure if this is an Orbit issue or a platform issue (or a user issue...). When updating our Trace Compass targets for 2023-12 M2, we encounter a new issue in the materialize-product stage: Cannot complete the install because one or more required items could not be found. We encountered similar issues when updating for M1, where two versions of the same bundle were available, it was picking up the latest one due to 0.0.0 in our feature.xml, but the platform was depending on a previous version, so we had to specify the older version in feature.xml (in that case, org.mortbay.jasper.apache-jsp 9.0.52). For M2 we also had to specify jakarta.annotation-api 1.3.5 (just before getting the above error). But now, if we specify jakarta.inject.jakarta.inject-api 1.0.5 in feature.xml, we get another error. It seems that the platform has a bundle with a dependency on two different versions of the same package (bundle?): In the orbit-aggregation repository, using Repository Explorer we can find two versions of the bundle: But in our feature.xml we can only specify one version or the other of the plugin, so we can't get both. I'm not sure if we are doing things incorrectly? Also, sorry for the uninformed rant as I'm not too familiar with how these things work, but is it normal that as users of the simrel / platform we have to constantly, at every new milestone, add or update explicit dependencies in our releng for new or updated dependencies from the platform? Shouldn't the platform bundles or features come with their own dependencies already resolved? |
Beta Was this translation helpful? Give feedback.
-
|
It looks like we are able to fix our issue by adding two entries in our feature.xml: We can do this by editing the source file, but it doesn't seem to be allowed (adding same plugin twice) from the Feature Manifest Editor Included Plug-ins tab, which makes me wonder if this is really the right way to do it? After this change we noticed we needed to do the same for: And finally we had to add all these plugins as new entries in our feature.xml: This is what I'm unsure, what are the changes in the platform between M1 and M2 that makes us need to do all these updates? |
Beta Was this translation helpful? Give feedback.
-
|
For Orbit I can only do my best to provide what projects need and what they actually use. E.g., Orbit collects all the things actually being used by projects looking at their target platforms to make those same things readily available for other projects, as reported here: https://github.com/eclipse-orbit/orbit-simrel/tree/main/report The Platform explicitly and deliberately uses two versions of the inject annotations to support both javax and jakarta namespaces (thanks Oracle for protecting the javax name for your own corporate gratification): The best I can do is offer both versions in Orbit as well. The Platform has migrated to Jetty 12: The best I can do is offer an update site with such content that projects can choose to use or not: https://download.eclipse.org/tools/orbit/simrel/maven-jetty/ The Platform has been gradually removing 3rd party includes from their features. This helps to avoid locking in specific versions of those bundles, which is generally good for downstream users and provides flexibility for consumers. As a result, you now you have the luxury and the burden of deciding yourself which version of batik you wish you use. The best I can do in Orbit is provide the very latest version of batik. In other words, I think I'm doing the best that I can in Orbit by providing the used and needed bundles in well-structured update sites. The removal of 3rd party bundle includes from features shifts responsibility for version choices from the feature provider to the feature consumer, i.e., to you. The decision to take that path was documented here in the 'SimRel Recommendations' section: There was also this announcement with PLEASE READ SECTION 3rd PARTY BUNDLES to draw attention. https://www.eclipse.org/lists/cross-project-issues-dev/msg19678.html |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Ed for the explanation! It's all starting to be clearer for me, all the information was a bit overwhelming at first. It helps to know that the burden we bear is indeed normal and intended, and not a result of a mistake on our part or on our dependent projects ;) We've already had to switch to import-package instead of require-bundle for some 3rd party dependencies that were renamed in orbit-aggregation, we'll try to do it for all of them! |
Beta Was this translation helpful? Give feedback.
-
The restructuring of Orbit is now complete:
The following two repositories are archived and will no longer be used to produce new content:
New Orbit content is generally maintained in one of the sub-folders here:
This aggregation site is the primary point of entry:
Orbit EBR accumulated a great deal of historical content over the years with much of it very stale and out-dated. In fact, while migrating the older EBR-driven recipes either to maven-bnd or to maven-osgi, it appeared as if a significant number of these bundles are no longer being actively used. As such, I kept an eye on what is actually used in SimRel and/or what actually appears to be used in p2 repositories on the download.eclipse.org server. As a result, there is a dramatic reduction in the content provided by Orbit via orbit-aggregation. It might not be nice to say, but being part of SimRel makes you a first class citizen when it comes to Orbit, so if you need something that appears to be missing, your needs will be prioritized accordingly.
In addition to keeping an eye on "what's actually being used", I kept an eye out for dependencies on "very old bundles" that were only produced by ancient CVS-based Orbit and never were migrated to EBR. These must go though often there need to be replacements. Some bundles are so ancient it was difficult to find source. The following repository maintains a small number of such fossilized bundles that are still necessary:
Collectively we need to wean ourselves off of the old Orbit content, i.e., anything not coming from orbit-aggregation, or directly from Maven, as soon as possible. Please don't wait for the emergency CVE alarms to go off, ensure that you have the capacity to make changes sooner, when it can be done at a leisurely pace, rather than later, when it's an emergency.
I believe that everything that everyone needs is available in orbit-aggregation. Of course I'm not perfect, so there might be something I've overlooked. Please report issues about missing content here:
That being said, first check what's available. Keep in mind that you should expect that for many of the bundles that are available directly from Maven as OSGi artifacts that they have different bundle symbolic names so you need to look carefully at the content.
The repository explorer is useful for searching for bundles with Expert Mode (underlined C button) enabled:
You might, for example look for one of the org.w3c bundles and be shocked to find it's missing!
But fear not, you don't ever actually need a bundle with a particular name, you need the packages that the bundle provides. You can search for "java.package" capabilities instead via the underlined combo:
When you double-click the package or a version, a details dialog will show you which bundle/version provides that package:
Beta Was this translation helpful? Give feedback.
All reactions