-
Notifications
You must be signed in to change notification settings - Fork 89
Dependency Updates #2218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency Updates #2218
Conversation
|
Looks like Infra is down and therefore an old snapshot version is used: |
3507a2a to
756da67
Compare
|
Rerunning the workflow now looks much better ... |
| <groupId>jakarta.inject</groupId> | ||
| <artifactId>jakarta.inject-api</artifactId> | ||
| <version>2.0.1</version> | ||
| <version>2.0.1.MR</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm currently check if we maybe can reuse the file format of the maven-version-plugin that way one can share the configuration with the standard maven plugin.
Beside that I created
to make the jakarta project aware of the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general "we" should find a way that one can ignore certainly versions. For example, suppose as happened with slf4j, that a broken result was published to Maven Central. It would be nice to be able to exclude it.
For orbit I did it in a very general way with a pattern that can be matched against the fully qualified coordinates such that one can very precisely ignore things:
You can see from the list that broken things are not as rare as they should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, their ignore version support looks quite flexible!
merks
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How best can we include the one set of changes (ECF) but not the other (the .MR version).
| <groupId>jakarta.inject</groupId> | ||
| <artifactId>jakarta.inject-api</artifactId> | ||
| <version>2.0.1</version> | ||
| <version>2.0.1.MR</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we exclude .MR? It's probably the same as 2.0.1 but we don't know that for sure. The former is in Orbit, is used by everyone else, and was used by the Platform for a long time. We really don't need more sources of duplicates in SimRel. Furthermore, the 2.0.1 version was published after the 2.0.1.MR version so it's actually the newest/latest one by date if not by Maven version order:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is really strange, the published it just a few minutes afterwards...
At the moment one can not exclude it but I'll try to came up with a solution hopefully the next days.
| <unit id="org.eclipse.ecf.filetransfer.ssl.feature.source.feature.group" version="1.1.402.v20240812-1535"/> | ||
| <unit id="org.eclipse.ecf.filetransfer.httpclient5.feature.feature.group" version="1.1.702.v20240808-1900"/> | ||
| <unit id="org.eclipse.ecf.filetransfer.httpclient5.feature.source.feature.group" version="1.1.702.v20240808-1900"/> | ||
| <repository location="https://download.eclipse.org/rt/ecf/snapshot/site.p2/3.15.2.v20240812-1535"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks promising. I'll need to try to keep the SimRel contribution in sync.
I usually just copy the PR link, then fetch it in Eclipse and revert any unwanted changes in the compare view, then push it to my fork and create a new PR from that. |
|
FYI, I created the PR by modifying this PR's content: |
|
I now rerun the job and it claimed to update the PR with latest master but nothing seems to happen until now. I created a bugreport here: I would keep the PR in its current state for now to allow further analysis! |
|
As recommended here: I'll close / delete the branch so it can be recreated. |


Please review the changes and merge if appropriate, or cherry pick individual updates.