Skip to content

Conversation

@github-actions
Copy link
Contributor

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

@laeubi
Copy link
Contributor

laeubi commented Aug 14, 2024

Looks like Infra is down and therefore an old snapshot version is used:

Warning:  Could not transfer metadata org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.9-SNAPSHOT/maven-metadata.xml from/to tycho-snapshots (https://repo.eclipse.org/content/repositories/tycho-snapshots/): status code: 403, reason phrase: Forbidden (403)
Warning:  Could not transfer metadata org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.9-SNAPSHOT/maven-metadata.xml from/to cbi-jdt (https://repo.eclipse.org/content/repositories/eclipse-staging/): status code: 403, reason phrase: Forbidden (403)
Warning:  Could not transfer metadata org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.9-SNAPSHOT/maven-metadata.xml from/to cbi-snapshots (https://repo.eclipse.org/content/repositories/cbi-snapshots/): status code: 403, reason phrase: Forbidden (403)
Warning:  Could not transfer metadata org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.9-SNAPSHOT/maven-metadata.xml from/to cbi-releases (https://repo.eclipse.org/content/repositories/cbi-releases/): status code: 403, reason phrase: Forbidden (403)
Warning:  Could not transfer metadata org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.9-SNAPSHOT/maven-metadata.xml from/to eclipse (https://repo.eclipse.org/content/repositories/cbi/): status code: 403, reason phrase: Forbidden (403)

@laeubi
Copy link
Contributor

laeubi commented Aug 14, 2024

Rerunning the workflow now looks much better ...

@laeubi laeubi requested review from merks and mickaelistria August 14, 2024 06:45
<groupId>jakarta.inject</groupId>
<artifactId>jakarta.inject-api</artifactId>
<version>2.0.1</version>
<version>2.0.1.MR</version>
Copy link
Contributor

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.

Copy link
Contributor

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:

https://github.com/eclipse-orbit/orbit-simrel/blob/d50928576445d05c1aecbf6ea96951b9ac6c7bcc/maven-osgi/dependency-analyzer-arg.txt#L63

image

You can see from the list that broken things are not as rare as they should be.

Copy link
Contributor

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!

Copy link
Contributor

@merks merks left a 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>
Copy link
Contributor

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:

image

Copy link
Contributor

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"/>
Copy link
Contributor

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.

@laeubi
Copy link
Contributor

laeubi commented Aug 14, 2024

How best can we include the one set of changes (ECF) but not the other (the .MR version).

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.

@merks
Copy link
Contributor

merks commented Aug 14, 2024

FYI, I created the PR by modifying this PR's content:

#2220

@laeubi
Copy link
Contributor

laeubi commented Aug 14, 2024

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!

@laeubi
Copy link
Contributor

laeubi commented Aug 14, 2024

As recommended here:

I'll close / delete the branch so it can be recreated.

@laeubi laeubi closed this Aug 14, 2024
@laeubi laeubi deleted the update_target branch August 14, 2024 10:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants