asmaven plugin fails silently when used together with Xtext's builder plugin

[jachinte]

Hi, Thank you very much for working on this project! I don't have much experience with Gradle, but I think I found a rather odd issue. The following code works as expected:

plugins {
  id "java"
  id "com.diffplug.gradle.p2.asmaven" version "3.17.6"
}

p2AsMaven {
  group "som", {
    repoEclipse "4.11"
    repo "https://download.eclipse.org/modeling/emf/updates/"
    repo "https://download.eclipse.org/modeling/mdt/ocl/updates/releases/latest/"
    repo "https://som-research.github.io/openapi-metamodel/update/"
    feature "edu.uoc.som.openapi.feature"
    slicingOption "latestVersionOnly", "true"
  }
}

dependencies {
  implementation "som:edu.uoc.som.openapi:1.0.3.201804111106"
  implementation "som:edu.uoc.som.openapi.io:1.0.3.201804111106"
}

However, when I add Xtext's builder plugin it fails silently. Gradle will continue waiting for the download to finish, but it never does:

plugins {
  id "java"
  id "org.xtext.builder" version "2.0.4"
  id "com.diffplug.gradle.p2.asmaven" version "3.17.6"
}

p2AsMaven {
  group "som", {
    repoEclipse "4.11"
    repo "https://download.eclipse.org/modeling/emf/updates/"
    repo "https://download.eclipse.org/modeling/mdt/ocl/updates/releases/latest/"
    repo "https://som-research.github.io/openapi-metamodel/update/"
    feature "edu.uoc.som.openapi.feature"
    slicingOption "latestVersionOnly", "true"
  }
}

dependencies {
  implementation "som:edu.uoc.som.openapi:1.0.3.201804111106"
  implementation "som:edu.uoc.som.openapi.io:1.0.3.201804111106"
}

I'm using Gradle 5.3.1. You can find a minimal failing example here: https://github.com/jachinte/goomph-minimal-issue

I noticed that when it works (without Xtext's plugin), the plugin prints out the path to the build.xml file:

> Configure project :
p2AsMaven som is dirty.
Initalizing maven group som from p2
Only needs to be done once, future builds will be much faster
p2AsMaven som installing from p2
Buildfile: /var/folders/k0/7f_5tyms21b_1gcx01wfrp2h0000gn/T/goomph-ant-build4043555613247606746.xml
<-------------> 0% CONFIGURING [3s]
> root project

Otherwise, it doesn't:

> Configure project :
p2AsMaven som is dirty.
Initalizing maven group som from p2
Only needs to be done once, future builds will be much faster
p2AsMaven som installing from p2
<-------------> 0% CONFIGURING [4s]
> root project

[hacki11]

There are logs in C:/Users/<user>/.goomph/p2-bootstrap/4.7.2/configuration/which gives a hint where the problem lies. I think the main issue is

!ENTRY org.eclipse.osgi 4 0 2019-05-05 12:16:50.928
!MESSAGE error loading hook: org.eclipse.core.runtime.internal.adaptor.EclipseLogHook
!STACK 0
java.lang.SecurityException: class "org.eclipse.core.runtime.adaptor.LocationManager"'s signer information does not match signer information of other classes in the same package

and that it's related to these issues: https://github.com/eclipse/xtext-maven/issues/42 https://github.com/eclipse/xtext/issues/1231 https://github.com/eclipse/xtext/issues/1249 https://github.com/xtext/xtext-gradle-plugin/issues/121

goomph constructs a classpath-jar c:\users\<user>\AppData\Local\Temp\long-classpath*.jar which includes everything you have in your build.gradle file (plugins, dependencies, etc.) and uses that for the eclipse runtime which mirrors the p2 repo. I think org.eclipse.core.runtime.adaptor.LocationManager of xtext-builder clashes with the eclipse runtime (bootstrap v4.7.2).

I could not found a workaround easily but there are several SO posts for similar issues.

p2AsMaven should not hang, but i think thats another issue.

[nedtwigg]

Interesting... The fact that p2asmaven is hanging is bad, but very hard to fix from goomph's side. It's a common complaint, but I believe it's hanging inside of p2 code.

The fact that you're getting signer information does not match signer information of other classes in the same package, is very important, and almost definitely the root problem. Might be tricky to fix.

goomph constructs a classpath-jar c:\users\\AppData\Local\Temp\long-classpath*.jar which includes everything you have in your build.gradle file (plugins, dependencies, etc.) and uses that for the eclipse runtime which mirrors the p2 repo

There's some important details here. Let's step through it:

This is where we download the resources, and the hang occurs:

https://github.com/diffplug/goomph/blob/8b02ec2d114b6589be4fde3612af561591efaeaa/src/main/java/com/diffplug/gradle/p2/AsMavenGroupImpl.java#L78-L79

Which calls this:

https://github.com/diffplug/goomph/blob/8b02ec2d114b6589be4fde3612af561591efaeaa/src/main/java/com/diffplug/gradle/p2/P2AntRunner.java#L48-L51

Which calls this:

https://github.com/diffplug/goomph/blob/8b02ec2d114b6589be4fde3612af561591efaeaa/src/main/java/com/diffplug/gradle/eclipserunner/EclipseApp.java#L105-L107

So the interesting thing is P2BootstrapInstallation.latest().outsideJvmRunner(). The P2BootstrapInstallation.latest() means that it will download a stripped-down version of eclipse to use for running p2 tasks. Right now, goomph is using 4.7.2. It's possible to override this here:

https://github.com/diffplug/goomph/blob/8b02ec2d114b6589be4fde3612af561591efaeaa/src/main/java/com/diffplug/gradle/GoomphCacheLocations.java#L125-L135

The outsideJvmRunner means that it willl use this class to run those jars. It's true that it will create a long classpath, but look at this filter:

https://github.com/diffplug/goomph/blob/8b02ec2d114b6589be4fde3612af561591efaeaa/src/main/java/com/diffplug/gradle/eclipserunner/JarFolderRunnerExternalJvm.java#L99-L106

This should mean that every eclipse jar is getting loaded exclusively from the p2bootstrap folder except for the OSGi jar. So here are the things I would try, from easiest to hardest:

• Split up your groups. Instead of having one som group with everything, have a som group and an xtextgroup. They'll each resolve on their own.
• Lower the version of repoEclipse that you are using. The linked issues indicate you want whichever version contained equinox 3.10.0, whichever that is.
• Step through the code I linked to above. You can always swap out outsideJvmRunner() for insideJvmRunner(). Starting a fresh JVM is harder to debug, but OSGi sets weird state in the JVM that makes it hard/impossible to run multiple parallel OSGi applications in one JVM, thus starting a fresh JVM is safer and more repeatable. But swap them out while you're debugging :)

[jachinte]

Wow, thanks for all those pointers. I'll work on it as soon as I can and will let you know how it goes.

[nedtwigg]

This issue is solved in dev.equo.p2deps.