Skip to content
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

Using org.eclipse.orbit:ant:1.10.14 for the latest ant version causes problems #17

Closed
merks opened this issue Oct 3, 2023 · 4 comments

Comments

@merks
Copy link
Contributor

merks commented Oct 3, 2023

With both Tycho 2.7.5, 3.0.5, and probably 4.0.3, a build against the Platform's 4.30 version fails because of ant dependency checking.

Update: No it does not fail for Tycho 4.0.3. So using the latest Tycho is definitely the best step forward.

Firstly one sees this in the log:

[WARNING] The POM for org.eclipse.orbit:ant:jar:1.10.14 is missing, no dependency information available

But then the build fails completely like this:

[ERROR] Failed to execute goal on project org.eclipse.emf.test.core: Could not resolve dependencies for project org.eclipse.emf:org.eclipse.emf.test.core:eclipse-test-plugin:2.29.0-SNAPSHOT: Failure to find org.eclipse.orbit:ant:jar:1.10.14 in https://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central-id has elapsed or updates are forced -> [Help 1]

The problems are highlighted here:

It appears that the following functions well as a workaround:

  <repositories>
    <repository>
      <!--
        Tycho is insisting on accessing the "upstream" artifact for this Ant, see https://github.com/eclipse-packaging/packages/issues/66
        To make this work we need to match the repo used in Orbit's build for the repository:
        https://github.com/eclipse-orbit/orbit-simrel/blob/f6ea491f4ada5d6d6750d8118bf40d9802993376/maven-bnd/tp/MavenBND.target#L1203
      -->
      <id>orbit-approved-artifacts</id>
      <url>https://repo.eclipse.org/content/repositories/orbit-approved-artifacts</url>
    </repository>
  </repositories>

So the open question for Orbit is, should I change the coordinates used to publish the transformed ant downloads from this location

to use coordinates that will exactly match this:

keeping in mind that these are NOT THE SAME ARTIFACTS so there seems some risk in conflating the two.

In other words, should I replace the org.eclipse.obit prefix/groupId with org.apache for the following build process:

https://github.com/eclipse-orbit/orbit-simrel/tree/main/maven-ant

Everyone having broken Tycho builds is also extremely unpleasant so I'm not sure how best to balance risk against unpleasantness...

@merks merks changed the title Using org.eclipse.orbit:ant:1.10.14 for the latest ant version causes problems Using org.eclipse.orbit:ant:1.10.14 for the latest ant version causes problems Oct 3, 2023
@laeubi
Copy link

laeubi commented Oct 3, 2023

Tycho 2.7.5

Tycho 2.x is EOL

Tycho 3.0.5

Tycho 3.x is EOL

probably 4.0.3

If you see issues with current released latest Tycho version please provide an integration-test to demonstrate the issue.

It appears that the following functions well as a workaround:

This is the recommended approach prior Tycho 4...

should I change the coordinates used to publish the transformed ant downloads from this location

The best would be to simply deploy it to maven central, there is already an orbit group id:
https://mvnrepository.com/artifact/org.eclipse.orbit

@merks
Copy link
Contributor Author

merks commented Oct 3, 2023

The latest nightly build has remapped the maven-wrapped- properties

image

@merks merks closed this as completed Oct 3, 2023
@jonahgraham
Copy link

I don't think this is the right solution - as when we rewrap things we are often changing the dependency information. I think instead of trying to make it look like org.apache.ant:ant:1.10.14 we should not publish maven coordinates at all.

The supposed reason to map to maven coordinates is so things like dependency:tree can display, but that means what dependency tree shows does not even match what happens in practice.

@merks
Copy link
Contributor Author

merks commented Oct 3, 2023

Good that I made the support flexible enough to remove coordinates too. 👍

The next build will look like this:

image

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

No branches or pull requests

3 participants