search

eclipse-jdtls / eclipse.jdt.ls

Java language server
1.75k stars 391 forks source link

Can't build using 1.5.0/1.6.0 version since repository 4.22-I does not exist #1970

Closed adrielparedes closed 2 years ago

adrielparedes commented 2 years ago

I tried to build a JDT.ls plugin I wrote that is currently using 1.5.0 version. When I compile it with a fresh .m2 repository it can't find the https://download.eclipse.org/eclipse/updates/4.22-I-builds/I20211010-1800/ repository and target-platform-configuration can't be downloaded:

<plugin>
        <groupId>org.eclipse.tycho</groupId>
        <artifactId>target-platform-configuration</artifactId>
        <version>${tycho.version}</version>
        <configuration>
          <resolver>p2</resolver>
          <target>
            <artifact>
              <groupId>org.eclipse.jdt.ls</groupId>
              <artifactId>org.eclipse.jdt.ls.tp</artifactId>
              <version>${jdt.ls.version}</version>
            </artifact>
          </target>
          <resolver>p2</resolver>
          <pomDependencies>consider</pomDependencies>
          <ignoreTychoRepositories>true</ignoreTychoRepositories>
        </configuration>
      </plugin>

https://github.com/eclipse/eclipse.jdt.ls/blob/v1.5.0/org.eclipse.jdt.ls.target/org.eclipse.jdt.ls.tp.target#L34

rgrunber commented 2 years ago

If you want to rebuild that particular version, I think the closest thing to try is probably https://download.eclipse.org/eclipse/updates/4.22/ in the target file as a replacement for I-build you list above.

Alternatively, you could also try using 1.7.0-SNAPSHOT if you don't care about a particular older version. See https://github.com/redhat-developer/quarkus-ls/pull/478/files as an example.

The problem is JDT-LS releases at about once (sometimes twice) a month, and we depend on some Java plugin components from Eclipse, which releases about once every 3months. Often we find ourselves wanting to consume some useful fixes while the Eclipse components have only released an integration build. When the release is finally complete, the retention policy is to remove old build artifacts/repositories, which affects rebuilds on our older tags.

If we only ever used the release, we could potentially leave out some useful fixes. I think to be able to rebuild old releases we would really need to start copying over the corresponding I-builds, since that's generally what would break in the target file.

rgrunber commented 2 years ago

Just to follow up, https://github.com/eclipse/eclipse.jdt.ls/blob/v1.7.0/org.eclipse.jdt.ls.target/org.eclipse.jdt.ls.tp.target#L33 (v1.7.0) is using a release repository which should be retained for a longer term.

tiagobento commented 2 years ago

Hi @rgrunber, thanks for providing this information and sorry for commenting on a closed issue. We're depending on 1.7.0-SNAPSHOT now, much like Quarkus is, but today we noticed that we're getting a weird 504 Gateway Timeout error while downloading information from the p2 metadata repository.

See the following logs..

[INFO] Computing target platform for MavenProject: io.github.kiegroup.kogito.tooling:vscode-java-code-completion-extension-plugin-core:0.0.0 @ /Users/tiagobento/redhat/kogito-tooling/packages/vscode-java-code-completion-extension-plugin/vscode-java-code-completion-extension-plugin-core/pom.xml
[ERROR] Failed to resolve target definition /Users/tiagobento/.m2/repository/org/eclipse/jdt/ls/org.eclipse.jdt.ls.tp/1.7.0-SNAPSHOT/org.eclipse.jdt.ls.tp-1.7.0-SNAPSHOT.target: Failed to load p2 metadata repository from location https://download.jboss.org/jbosstools/updates/m2e-extensions/m2e-apt/1.5.3-2019-11-08_11-04-22-H22/: HTTP Server 'Gateway Timeout': https://download.jboss.org/jbosstools/updates/m2e-extensions/m2e-apt/1.5.3-2019-11-08_11-04-22-H22/content.xml: HttpComponents connection error response code 504. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException

Maybe this is related to a new SNAPSHOT version that was recently published?

tiagobento commented 2 years ago

@rgrunber Just to add more to this, I already tried to use the new 1.7.0 release (like you did here https://github.com/redhat-developer/quarkus-ls/commit/da79fdb2413dd5e73764d426f682201dd9982156), but still getting 504 locally :/

rgrunber commented 2 years ago

I just tried querying https://download.jboss.org/jbosstools/updates/m2e-extensions/m2e-apt/1.5.3-2019-11-08_11-04-22-H22/ . It seems to be unchanged in both snapshot and 1.7.0 release. The url certainly loads in a browser and downloading an artifact via p2 also works. Is it still failing ?

Update : Build job to upload artifacts to the server failed for me. Unrelated error but odd that this and the issue mentioned here would happen at same time. (artifact upload succeeded now)

tiagobento commented 2 years ago

@rgrunber Hmm.... really weird. I can open it in the browser too, but me and some of my peers are getting this non-sensical 504 error. It works on our GitHub Actions CI, though. Even tried switching to a different internet provider already (😅), but no luck.

AlexXuChen commented 2 years ago

Update : Build job to upload artifacts to the server failed for me. Unrelated error but odd that this and the issue mentioned here would happen at same time.

I'm seeing the same issue when building: getting a 504 on my side

tiagobento commented 2 years ago

Interesting to note that, for some reason, Maven is trying to fetch resources from version 1.5.3 apparently?

rgrunber commented 2 years ago

For some background : quarkus-ls uses the JDT-LS target platform artifact for compilation. Intuitively the quarkus-ls JDT extension is going to have very similar dependencies to JDT-LS so that's why this is the approach taken. The version is 1.7.0 and repository is where it can be found.

The artifact itself is just an XML file with a list of p2 repositories to be used at build time : https://repo.eclipse.org/content/repositories/jdtls-releases/org/eclipse/jdt/ls/org.eclipse.jdt.ls.tp/1.7.0.20211216164144/org.eclipse.jdt.ls.tp-1.7.0.20211216164144.target. You'll find https://download.jboss.org/jbosstools/updates/m2e-extensions/m2e-apt/1.5.3-2019-11-08_11-04-22-H22/ inside that file, and the version is just a reference to the m2e-apt plugin, which happens to be similarly versioned.

rgrunber commented 2 years ago

I can also confirm the behaviour on https://ci.eclipse.org/ls/job/jdt-ls-master/1244/console .

tiagobento commented 2 years ago

@rgrunber Thanks for the details. It all makes sense to me and looks like we're using the correct approach on our repo, with the only difference being that we're still depending on 1.7.0-SNAPSHOT, rather than the latest 1.7.0.20211216164144 release.

I think this is an issue outside our configurations and it's really blocking us right now, as we cannot build our stack that depends on this artifact :/

Were you able to find the reason why we keep getting 504 'Gateway Timeout'?

snjeza commented 2 years ago

@tiagobento I can't reproduce the issue.

$ git clone git@github.com:kiegroup/kogito-tooling.git
$ cd kogito-tooling/packages/vscode-java-code-completion-extension-plugin/
$ mnv -v
Maven home: /usr/local/apache-maven-3.8.3
Java version: 11.0.13, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-11-openjdk-11.0.13.0.8-2.fc34.x86_64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.15-100.fc34.x86_64", arch: "amd64", family: "unix"
$ rm -rf /home/snjeza/mvnrepo # clear repo 
$ mvn -Dmaven.repo.local=/home/snjeza/mvnrepo clean verify
...
[INFO] Building jar: /home/snjeza/projects/kogito-tooling/packages/vscode-java-code-completion-extension-plugin/vscode-java-code-completion-extension-plugin-core/target/vscode-java-code-completion-extension-plugin-core-sources.jar
[INFO] 
[INFO] --- target-platform-configuration:2.3.0:target-platform (default-target-platform) @ vscode-java-code-completion-extension-plugin-core ---
[INFO] 
[INFO] --- tycho-packaging-plugin:2.3.0:package-plugin (default-package-plugin) @ vscode-java-code-completion-extension-plugin-core ---
[INFO] Building jar: /home/snjeza/projects/kogito-tooling/packages/vscode-java-code-completion-extension-plugin/vscode-java-code-completion-extension-plugin-core/target/vscode-java-code-completion-extension-plugin-core.jar
[INFO] 
[INFO] --- tycho-p2-plugin:2.3.0:p2-metadata-default (default-p2-metadata-default) @ vscode-java-code-completion-extension-plugin-core ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for vscode-java-code-completion-extension-plugin :: parent 0.0.0:
[INFO] 
[INFO] vscode-java-code-completion-extension-plugin :: parent SUCCESS [ 11.536 s]
[INFO] vscode-java-code-completion-extension-plugin :: core SUCCESS [07:38 min]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  15:53 min
[INFO] Finished at: 2022-01-21T23:20:28+01:00
[INFO] ------------------------------------------------------------------------
$
rgrunber commented 2 years ago

The issue should be resolved, and JDT-LS 1.8.0 has been properly released. Going forward we will migrate to https://jbosstools.github.io/m2e-apt/updates/1.5.4/ (Note that the folder is a 404, but the p2 repo does exist as things like https://jbosstools.github.io/m2e-apt/updates/1.5.4/artifacts.jar are there). Likely this can be configured with addition of main page if necessary.