assemble.all, when run on mac, produces bad .app folder (but works when run on linux)

[nedtwigg]

Not sure why, but running gradlew assemble.all has this behavior:

• Windows can build output for all platforms, except it clobbers the executable flags for mac/linux.
• Linux can build for all platforms (Linux CI server ftw!)
• Mac produces incorrect output for its own platform (!!!)

So you can't build mac artifacts on a mac. Luckily, you can build mac artifacts on a linux box, and they'll run fine on a mac. But it'd be nice if mac could build itself.

Likely to be a bug in PDE build, perhaps related to this?

[elmsley]

I get this on my mac.

:deploy:buildP2
url=jar:file:/Users/me/.gradle/caches/modules-2/files-2.1/com.diffplug.gradle/goomph/3.0.3/70baf1e695ee113b5ba44f6d7584710604664581/goomph-3.0.3.jar!/com/diffplug/gradle/pde/template.build.properties
Installing org.eclipse.platform.ide 4.5.2.M20160212-1500.
Installing org.eclipse.jdt.feature.group 3.11.2.v20160212-1500.
Installing org.eclipse.pde.feature.group 3.11.2.v20160212-1500.
Operation completed in 1934 ms.
Installing pde 4.5.2... :deploy:buildP2 FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':deploy:buildP2'.

  Needed to find the pde.build folder: /Users/me/.goomph/pde-bootstrap/4.5.2.app/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 7.2 secs

[nedtwigg]

Looks like you're on Mac, correct? Which version?

Can you look in the ~/.goomph/pde-bootstrap folder and tell me if there's a
"4.5.2.app" in there?

On Friday, July 29, 2016, elmsley [email protected] wrote:

I get this.

:deploy:buildP2

url=jar:file:/Users/me/.gradle/caches/modules-2/files-2.1/com.diffplug.gradle/goomph/3.0.3/70baf1e695ee113b5ba44f6d7584710604664581/goomph-3.0.3.jar!/com/diffplug/gradle/pde/template.build.properties
Installing org.eclipse.platform.ide 4.5.2.M20160212-1500.
Installing org.eclipse.jdt.feature.group 3.11.2.v20160212-1500.
Installing org.eclipse.pde.feature.group 3.11.2.v20160212-1500.
Operation completed in 1934 ms.
Installing pde 4.5.2... :deploy:buildP2 FAILED

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':deploy:buildP2'.

Needed to find the pde.build folder:
/Users/me/.goomph/pde-bootstrap/4.5.2.app/configuration/org.eclipse.equinox.simpleconfigurator/
bundles.info

Try:
Run with --stacktrace option to get the stack trace. Run with --info
or --debug option to get more log output.

BUILD FAILED

Total time: 7.2 secs

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACyhwAtgJzzjp6kpfpyDMRsvNf1SwqtIks5qatHqgaJpZM4JMMva
.

Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043
340 S Lemon Ave #3433, Walnut, CA 91789

[elmsley]

El Capitan 10.11.6 (15G31)
Darwin quercus 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64

Yes, that folder is there. But only the Contents folder is in there (not 'configuration')

Although when I run the "gradle ide" the version shows 4.6.0. Is that correct?

[nedtwigg]

If you pull the latest, it will update Goomph to 3.0.4, which fixes both your problem and the original problem of generating bad mac .app folders. My test mac machine had somehow gotten into a strange state during Goomph's development, where the build succeeded, but with incorrect output (as noted in the original bug report).

In order to replicate your bug, I tried to wipe my ~/.goomph folder, and then I got the same stack as you. I fixed the bug, and now it generates correct output. Thanks for the stacktrace, very helpful.

When you get a chance, can you confirm that ./gradlew assemble.all works, and that the result in deploy/build/cocoa.macosx.x86_64.app runs correctly? Thanks!

[elmsley]

I recloned, and deleted my ~/.goomph. ./gradlew ide works fine, however assemble.all gives me:

p2AsMaven eclipse-deps is dirty.
Initalizing maven group eclipse-deps from p2
Only needs to be done once, future builds will be much faster
p2AsMaven eclipse-deps installing from p2
Buildfile: /var/folders/kj/md_ky92x7vx2y246fv99dhth0000gn/T/goomph-ant-build1123693527014919085.xml
[p2.mirror] SLF4J: Class path contains multiple SLF4J bindings.
[p2.mirror] SLF4J: Found binding in [jar:file:/Users/me/.gradle/caches/2.14/generated-gradle-jars/gradle-api-2.14.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[p2.mirror] SLF4J: Found binding in [jar:file:/Users/me/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/lib/gradle-logging-2.14.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[p2.mirror] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
[p2.mirror] SLF4J: Actual binding is of type [org.gradle.internal.logging.slf4j.OutputEventListenerBackedLoggerContext]
[p2.mirror] Messages while mirroring artifact descriptors.
BUILD SUCCESSFUL

BUILD SUCCESSFUL
Total time: 6 minutes 6 seconds
p2AsMaven eclipse-deps creating runnable repo
p2AsMaven eclipse-deps creating maven repo
p2AsMaven eclipse-deps is complete.
:deploy:buildP2
url=jar:file:/Users/me/.gradle/caches/modules-2/files-2.1/com.diffplug.gradle/goomph/3.0.4/b564c4c618c32d51c4b72473eb568ce77eea44a9/goomph-3.0.4.jar!/com/diffplug/gradle/pde/template.build.properties
:deploy:buildP2 FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':deploy:buildP2'.

  Root '/Users/me/playground3/gradle_and_eclipse_rcp/target.maven/build' does not exist.

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 6 mins 32.085 secs

[nedtwigg]

Try gradlew bundles (which builds target.maven/build) then gradlew assemble.all.

The trouble with gradlew bundles is that it doesn't have any up-to-date checks (so it always runs, even if it doesn't have to), and it's pretty slow. As a result, assemble.all doesn't have bundles as a dependency, even though it really should. On a fresh clone with no .goomph directory, ide triggers bundles, so that calling assemble.all afterwards should work. But if something was stale somewhere, it could fail to trigger.

I just uploaded some commits to make bundles a dependency of assemble.all so that users shouldn't have this problem in the future.

[elmsley]

I can confirm that cleaning the ~/goomph and doing gradlew bundles, gradlew ide, gradlew assemble.all does build cleaning.
There however is an issue with the .app that gets built, as it doesn't execute when issuing the 'open' command. I can run it directly ./deploy/build/cocoa.macosx.x86_64.app/Contents/MacOS/RcpDemo so I think things are compiled properly. I believe this is an Eclipse packaging problem as I've seen similar behaviors before.
Thanks!

[nedtwigg]

Huh. I also experiences this packaging problem initially (that's what I created the bug for in the first place), but after the fix earlier in this bug, I'm no longer experiencing it. But building the mac .app on a linux CI server has always worked for me. Guess I'll leave this open until we can reliably build the mac .app on a mac.