Open jmini opened 1 year ago
@amergey: I am happy if you can tell me more. Here is the process to compute the BOM file:
Using bnd I read the content of the update site. For release 2022-06:
https://download.eclipse.org/eclipse/updates/4.24/
The list of bundles in this update site can be found here: https://github.com/jmini/ecentral/blob/master/data/4.24/bnd-output.txt --> I do not see anything related to RAP.
Then I turn the bundle name and the version to maven coordinates on maven central, matching what the CBI Aggregator is doing.
And I publish the BOM file.
I am happy to review this process to include what is missing.
I think the update site containing the full list of bundles for the 2022-06 eclipse releases is https://download.eclipse.org/releases/2022-06
Ok indeed…
This project is currently focusing on the jars published by the eclipse-platform projects.
I am not sure how the Eclipse RAP is publishing on maven central, but they do.
Example: org.eclipse.rap.ui_3.21.0.20220324-0858.jar
Is published in the update site: https://download.eclipse.org/releases/2022-06/202206151000/plugins/
And also on maven central:
<dependency>
<groupId>org.eclipse.rap</groupId>
<artifactId>org.eclipse.rap.ui</artifactId>
<version>3.21.0</version>
</dependency>
Does it make sense to include those in the ecentral-BOM as well ?
Or should the BOM be modularized, so that you can import the parts you are interested in…
My bad, I initially did not pay attention that this project was focused on eclipse platform, I thought it was for the full eclipse simrel
There are many dependencies between various eclipse project inside simrel which would make ecentral very useful to help pulling consistent set of dependencies from maven.
If it could make sense to extend the scope of this projet, I would say it makes more sense to include in ecentral bom, as there is no reasons to pull a module in a version and dependencies in another version. I mean eclipse rap 3.21 is in simrel 2022-06 and needs eclipse platform from 2022-06 (4.24) and cannot run with a different version of the platform.
If BOM is modularized, a "top level BOM" would be needed anyway to aggregate different modules in the right version.
If you think it is too wide and not really appropriate to extend this project, and keep focus on eclipse platform, that's fine, I can understand and you can close this
I think it makes sense to extend the project.
I am not familiar with how BOM can be composed together, but I think we need to go in this direction.
Especially because I have the feeling Maven is considering (resolving? checking? downloading?) each of the dependencies in the BOM, even if they are not required by the consumer project. Gradle is reading the BOM in a more clever way.
I am also not sure how to split the different BOM files (per groupId
maybe?: one file for org.eclipse.platform
, one for org.eclipse.jdt
, ... and one for org.eclipse.rap
with the corresponding dependencies. The BOM file for jdt requires the one for platform).
I noticed some eclipse bundles are missing from the bom in previous version (RAP for example, but there are others), how can I proceed, may I create issues, so you can check if it is relevant to include them or not ? or do you prefer a PR ?
Originally posted by @amergey in https://github.com/jmini/ecentral/issues/24#issuecomment-1272938350