Closed osadl closed 1 year ago
Only a subset of our projects focus on the Eclipse IDE. Our Jakarta projects do leverage standard OSGi, but have no specific interest Eclipse Plug-ins.
To the best of my knowledge, the bundle that's distributed as part of the Eclipse IDE is modified by the Eclipse Orbit project to make it suitable for use as an Eclipse Platform plug-in (it is the mandate of the Eclipse Orbit project to "bundlify" content that is not already in an appropriate bundle form). So the team that monitors this channel doesn't know how to respond to your question.
The module that was produced by this project, for example, doesn't actually include the Import-Package
header in its manifest.
It's not clear to me that the Import-Package
header added by the Eclipse Orbit project makes any sense. It appears that the bundle is attempting to import packages that it exports. That notwithstanding, the Import-Package
header is generally used to describe dependencies and the version=[1.3.5,2)
is intended to indicate that the bundle can consume any version of the dependency between version 1.3.5 inclusive and 2.0.0 exclusive. It has nothing to do with the commit. The date in the bundle qualifier is the date that the Eclipse Orbit process grabbed the JAR and retooled it.
The Jakarta Annotations project only provides standard OSGi headers by design. The Eclipse-SourceReferences
is something that is specific to the Eclipse IDE. While it's relatively easy to add that header to the MANIFEST using the BND-based Felix maven-bundle-plugin
plug-in, there's no existing straightforward means of calculating a value for that field using the tools currently used by the project. The Eclipse plug-ins that include this header in their manifests use Eclipse Tycho (which makes this easy) as part of their build.
AFAICT there is no standard OSGi header that is intended to represent this information. This feels like an opportunity for a future version of the OSGi specification and BND.
It seems to me that it would be relatively easy for the Eclipse Orbit team to include an Eclipse-SourceReferences
header that points to the source JAR on Maven Central. I'll open an issue with them to see what we can do.
Note that the Eclipse Orbit project does distribute source bundles for all of the content that it tools. Source bundles are included in some configurations of the Eclipse IDE (most notably the Eclipse SDK and Eclipse IDE for Committers), but not all to minimize the footprint in cases where the user doesn't require direct access to the source.
Thanks a lot for taking care of this request.
It seems to me that it would be relatively easy for the Eclipse Orbit team to include an Eclipse-SourceReferences header that points to the source JAR on Maven Central. I'll open an issue with them to see what we can do.
That would be wonderful. Would you be so kind as to link that issue here or send me the link? - I could post a comment and maybe help convince the Eclipse Orbit team.
I opened the issue here: https://github.com/eclipse-orbit/orbit-simrel/issues/21
The team is, I believe, correctly pointing out that the Maven metadata (and repository) should (a) exist, and (b) contain information about the source (and license).
FYI, we're working on generating proper CycloneDX SBOMs for the Eclipse IDE products. I believe that those should be more useful to you. I'm a little late doing this, but I've created an issue to track that effort and the various related activities.
I'm going to close this issue, because I believe that it is unrelated to this project and we should get it out of their queue. Any follow up discussion on this specific topic should probably occur in the Eclipse Orbit repository referenced above.
We are a member-based Open Source organization and help our members fulfill license obligations. Recently, we received a request about the EPL-2.0 disclosure obligations of the Eclipse IDE and found out that in many plugins there is a special tag "Eclipse-SourceReferences" in the META-INF/MANIFEST.MF file. We then created a Python script that evaluates this information and checks out the corresponding source code from the given Github repository. The script is located in the repository https://github.com/osadl/Jar2src and the output of the most recent program run is available in the repository at the URL https://github.com/osadl/Jar2src/blob/main/pdf/Locate-Eclipse-IDE-source-code-by-manifest-2023-07-23.pdf.
Unfortunately, the mentioned tag is not included in the META-INF/MANIFEST.MF file of this project. In the file META-INF/NOTICE.md the reference to this Github repository is, indeed, given and from the name of the plugin with the name part "1.3.5" the name of the branch "1.3.5-BRANCH" can be assumed. However, the two dates 2019 and 2023 do not match, and the addition of ",2" in the "Import-Package" tag indicates that a later commit was used when producing the plugin for the Eclipse IDE 2023-06. In addition, the named process cannot be automated.
So my request is that the tag "Eclipse-SourceReferences" with URL, Path and Commit be added to the META-INF/MANIFEST.MF file of this plugin to make it easier and safer to find the corresponding source code to comply with the disclosure obligations of the selected license. It certainly would be very welcome if this could be done.