Package Details: jdtls 1.12.0-1

Git Clone URL: https://aur.archlinux.org/jdtls.git (read-only, click to copy)
Package Base: jdtls
Description: Eclipse Java language server
Upstream URL: https://github.com/eclipse/eclipse.jdt.ls
Licenses: EPL
Submitter: languitar
Maintainer: languitar
Last Packager: languitar
Votes: 16
Popularity: 0.78
First Submitted: 2017-11-15 12:49 (UTC)
Last Updated: 2022-06-02 10:55 (UTC)

Dependencies (2)

Sources (1)

Latest Comments

languitar commented on 2022-01-28 08:29 (UTC)

@mynacol thanks for the hints. I have updated the script.

mynacol commented on 2022-01-27 17:43 (UTC)

Two minor improvement ideas to the launcher script:

  • use /bin/sh instead of /bin/bash (no fancy functions needed)
  • exec before the single java command. This allows the shell process to exit after startup.

schrieveslaach commented on 2022-01-21 20:13 (UTC)

Looks good to me. Thanks.

languitar commented on 2022-01-20 19:55 (UTC)

Oh sorry, forgot that the whole Gitlab group is private. Here's the proposed diff:

diff --git a/PKGBUILD b/PKGBUILD
index 62ec0ed1b9f4dde42e820eaea7cf77939da67b42..48185fc1215ef10ba701117e01966e2047ed98c2 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -2,7 +2,7 @@

 pkgname=jdtls
 pkgver=1.7.0
-pkgrel=1
+pkgrel=2
 pkgdesc="Eclipse Java language server"
 arch=(any)
 url="https://github.com/eclipse/eclipse.jdt.ls"
@@ -12,7 +12,7 @@ makedepends=()
 source=("https://download.eclipse.org/jdtls/milestones/1.7.0/jdt-language-server-1.7.0-202112161541.tar.gz"
         "launcher.sh")
 sha256sums=('2f0c28dfec317a268ec44904420657181b43a7ba2a32f0bf788ea388dacb8552'
-            '813801c237676764f6fb005df3ccaaee33c7cc0ab54fc1c73ef3cf4cee5a65de')
+            '78c7dc2936dedd27011a787438e85888c3846a16115ae02b281eb672456d547c')

 package() {
     mkdir -p "${pkgdir}/usr/share/java/jdtls"
diff --git a/launcher.sh b/launcher.sh
index fdee5be1c57498f856094d453460c7ac2d3648be..2c320342a4de9126d884ccd10fb9464893ec5ba0 100755
--- a/launcher.sh
+++ b/launcher.sh
@@ -1,17 +1,14 @@
 #!/bin/bash

-# copy the configuration folder to tmp to be writable
-tmp_dir="$(mktemp -d /tmp/jdtls.XXXXX)"
-cp -R /usr/share/java/jdtls/config_linux "${tmp_dir}"
-# and ensure that it is removed on exit
-trap "{ rm -rf ${tmp_dir}; }" EXIT
-
 java \
     -Declipse.application=org.eclipse.jdt.ls.core.id1 \
     -Dosgi.bundles.defaultStartLevel=4 \
     -Declipse.product=org.eclipse.jdt.ls.core.product \
+    -Dosgi.checkConfiguration=true \
+    -Dosgi.sharedConfiguration.area=/usr/share/java/jdtls/config_linux \
+    -Dosgi.sharedConfiguration.area.readOnly=true \
+    -Dosgi.configuration.cascaded=true \
     -noverify \
     -Xms1G \
     -jar /usr/share/java/jdtls/plugins/org.eclipse.equinox.launcher_*.jar \
-    -configuration "${tmp_dir}/config_linux" \
     "$@"

schrieveslaach commented on 2022-01-20 12:44 (UTC) (edited on 2022-01-20 12:46 (UTC) by schrieveslaach)

@languitar, I've no access to the GitLab repo. Can you give me access? Here is my GitLab handle: https://gitlab.com/schrieveslaach

languitar commented on 2022-01-20 12:13 (UTC)

@schrieveslaach thanks for the hint. That feature didn't exist when I created the project.

Do you think these are the correct changes: https://gitlab.com/languitar-aur-packages/aur-jdtls/-/merge_requests/6/diffs

schrieveslaach commented on 2022-01-20 06:42 (UTC)

Based on this AUR package I created a Homebrew formula to install jdtls on MacOS. I discovered that you can get rid of the temporary folder creation by using some Java properties that will tell the Eclipse Equinox framework to use a shared configuration which make jdtls make package manager friendly.

Here are the properties: https://github.com/Homebrew/homebrew-core/blob/ec2f8b111eb89cc7e68360d418cde708248529ea/Formula/jdtls.rb#L20-L23

Do you mind to incorporate these properties.

languitar commented on 2020-11-20 18:13 (UTC)

@cwtb I started packaging this by using the git repository. Sometimes this failed, so I got in contact with the jdtls developers and they indicated that the preferred way of distributing jdtls is to use the milestone builds. I don't understand why the snapshot version is so much ahead of the milestone builds. May be this is something to be asked upstream.

cwtb commented on 2020-11-20 15:23 (UTC)

Have you looked into using snapshots instead of milestone releases keeping things updated? It looks like there is a version here that isn't in the milestones yet. Might not be as stable, but who knows https://download.eclipse.org/jdtls/snapshots/

brainplot commented on 2020-02-19 07:59 (UTC) (edited on 2020-02-23 05:24 (UTC) by brainplot)

@languitar You can expand the ${pkgver} variable in the url so that you don't have to change it in multiple places, whenever there's an update.

languitar commented on 2020-02-07 08:12 (UTC)

I'd love to update this package, but upstream - again - hasn't released a milestone build for the new version. I have, again, pinged them in a Github issue: https://github.com/eclipse/eclipse.jdt.ls/issues/1208

languitar commented on 2019-10-12 13:46 (UTC)

Version bump to 0.44.0 is currently impossible because upstream has not published an artifact using the normal channel: https://github.com/eclipse/eclipse.jdt.ls/issues/1208

GrimKriegor commented on 2019-05-28 19:55 (UTC)

@nicolehopperB8Y, @languitar, I have been through that same issue with vim-ale recently.

Hope this helps.

https://github.com/w0rp/ale/pull/2523

languitar commented on 2019-05-28 19:45 (UTC)

@nicolehopperB8Y the only option I see is to somehow replicate what the launcher schript does in vimscript. Or try to get in touch with the coc developer to clarify this.

Btw, I always use the signed releases from the milestone release server and use the sha256 sum provided by upstream.

nicolehopperB8Y commented on 2019-05-27 05:59 (UTC)

@languitar I use this package because I don't want coc to manage it. When updating I can check the pkgbuild if I use aur, but when coc updates I don't know which file it's downloading...

languitar commented on 2019-05-26 12:34 (UTC)

@nicolehopperB8Y ships it's own copy of jdtls, which should be installed somewhere into your home directory. I don't see why you shouldn't be able to write there. Try to check the permissions. You don't event need this package for coc.

nicolehopperB8Y commented on 2019-05-25 11:02 (UTC)

@languitar is there any other way to work around the issue? I'm using coc.nvim & coc-java, but coc-java just run the jdtls server directly so the launcher script is useless to me.

languitar commented on 2019-05-20 16:57 (UTC)

@GrimKriegor thanks, you're right. Package is updated now.

GrimKriegor commented on 2019-05-19 17:11 (UTC)

Hello there.

It has come to my attention that the latest commit named Version bump to 0.38.0 updates the pkgver variable, but not source nor sha256sums, which still point to the 0.35.0 tar file.

Additionally, version 0.39.0 is already out.

Here is a patch for your consideration:

diff --git a/PKGBUILD b/PKGBUILD
index e9568ff..1d30e25 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,7 +1,7 @@
 # Maintainer: Johannes Wienke <languitar@semipol.de>

 pkgname=jdtls
-pkgver=0.38.0
+pkgver=0.39.0
 pkgrel=1
 pkgdesc="Eclipse Java language server"
 arch=(any)
@@ -9,9 +9,9 @@ url="https://github.com/eclipse/eclipse.jdt.ls"
 license=('EPL')
 depends=('java-runtime')
 makedepends=()
-source=("http://download.eclipse.org/jdtls/milestones/0.35.0/jdt-language-server-0.35.0-201903142358.tar.gz"
+source=("http://download.eclipse.org/jdtls/milestones/0.39.0/jdt-language-server-0.39.0-201905150127.tar.gz"
         "launcher.sh")
-sha256sums=('f51f804e5c6d1a1674d78433f1530faeba46b86da86a8bae2ed55690d2c28204'
+sha256sums=('2bc0e44c337ea1fb68df6bcb29267f112ec6dddc4e28114a99e35332966153c1'
             '813801c237676764f6fb005df3ccaaee33c7cc0ab54fc1c73ef3cf4cee5a65de')

 package() {

Thank you for your time.

languitar commented on 2019-01-19 20:07 (UTC)

I have put a hack in the launcher script to work around the issue. Should work as expected now.

languitar commented on 2019-01-11 19:01 (UTC)

@sum01 strange, on a different computer I am experiencing exactly the same issue, but I am unable to reproduce it on my main machine and I can't spot a difference.

languitar commented on 2019-01-05 17:51 (UTC) (edited on 2019-01-05 17:51 (UTC) by languitar)

@sum01: I suspect that is a problem of how you call the server. Here, it still works as expected. You can have a look at my vim config for this server: https://github.com/languitar/config-vim/blob/master/home/.config/nvim/init.vim#L365

sum01 commented on 2019-01-05 17:47 (UTC)

The installation does work now, although when trying to run it I get this error <title>Invalid Configuration Location</title>The configuration area at '/usr/share/java/jdtls/config_linux' is not writable. Please choose a writable location using the '-configuration' command line option.

I'm attempting to use it with the LanguageClient-neovim plugin, although that error is from running at command line.

languitar commented on 2019-01-05 10:14 (UTC)

I have updated the package. @sum01, could you test again, please?

languitar commented on 2019-01-05 09:58 (UTC)

Great. The release is just about two weeks old and already an upstream snapshot version is gone again. I will have to change the package to use their released jar files instead to work against these things. Seems, they will continue to use snapshots versions of upstream software for some more time.

sum01 commented on 2019-01-05 01:39 (UTC)

I'm having the same build failure issue with v0.30.0

languitar commented on 2018-10-01 15:00 (UTC)

I have reported this upstream. Let's see what the do about this.

https://github.com/eclipse/eclipse.jdt.ls/issues/810

commented on 2018-10-01 14:22 (UTC)

@languitar Yeah, it's repeatable, does look like an upstream issue.

However, I was able to build jdtls using YouCompleteMe (following these instructions: https://www.reddit.com/r/vim/comments/844bwy/has_anyone_gotten_java_language_server_to_work/e2o5hhr). Somehow it manages to overcome the issue, interesting to look at the magic it does to build it.

languitar commented on 2018-10-01 07:05 (UTC)

@zoresvit is this repeatable? if so, this is an upstream issue, because some of the configured maven repositories seem to be gone.

commented on 2018-09-30 20:10 (UTC)

The build fails with the following error:

[ERROR] Failed to resolve target definition /tmp/yaytmp-1000/jdtls/src/eclipse.jdt.ls-0.25.0/org.eclipse.jdt.ls.target/org.eclipse.jdt.ls.tp.target: Failed to load p2 metadata repository from location http://download.eclipse.org/eclipse/updates/4.9-I-builds/: No repository found at http://download.eclipse.org/eclipse/updates/4.9-I-builds. -> [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
==> ERROR: A failure occurred in build().
    Aborting...
Error making: jdtls