OMERO.insight Java Application Bundler task for Mac OS X #3337

chris-allan · 2015-01-13T15:43:00Z

This pull request adds support for the Java Application Bundler (https://java.net/projects/appbundler) and its open source fork (https://bitbucket.org/infinitekind/appbundler). This bundler and corresponding launcher are intended, at least as far as we're concerned, as a transition point for Java 1.7+ on Mac OS X.

The high level zips target can be run to trigger the execution of the Java Application Bundler specific dist-osx-appbundler task as follows:

./build.py -f components/insight/build.xml zips

You will likely find that this is best run after a current build run via ./build.py clean build. The new OMERO.insight.app is then available in the following subdirectory:

components/insight/OUT/dist/appbundler

Due to the fact that execution sets the "current working directory" to the user's home directory initial testing can be performed as follows:

components/insight/OUT/dist/appbundler/OMERO.insight.app/Contents/MacOS/OMERO.insight \
    container.xml `pwd`/components/insight/OUT/app

If you have errors, launcher debugging can be turned on with an environment variable (https://java.net/projects/appbundler/lists/dev/archive/2012-11/message/2):

export JAVA_LAUNCHER_VERBOSE=1

Work will have to be done on the following before this can be merged:

Resolving issues with the way that OMERO.insight locates configuration files

/cc @jburel, @rleigh-dundee

joshmoore · 2015-01-13T18:13:33Z

@chris-allan : before merging, I'd propose we force push away the jar and either use some existing maven repository or copy it to our "manual" repository.

joshmoore · 2015-01-14T07:41:13Z

Having looked at chris-allan@92ebe4c now, perhaps maybe the way to go is to set up a job that automatically builds and pushes to http://artifacts.openmicroscopy.org /cc @sbesson

sbesson · 2015-01-14T10:16:28Z

With regard to packaging and assuming this new app bundler will eventually be the long term solution for the Insight application under OS X, a suggestion would be to:

rename the old OMERO.insight e.g. as OMERO.insight_legacy (.app folder, zips etc etc)
bundle both legacy and non-legacy apps in the OMERO.clients (and deprecate legacy in a later release)
do we need the same strategy for editor and importer?
do we backport openGL removal on this line to reduce the build time, artifact list?

joshmoore · 2015-01-14T10:56:44Z

Perhaps OMERO.insight_Java6 ?

ghost · 2015-01-14T11:08:15Z

Bundling the new and legacy .app bundles is convenient, but these are quite large due to each having a complete copy of all the jars, so having them separate does have its advantages. Especially if this also includes editor and importer. [are these two not deprecated as standalone programs now Insight has both? Maybe consider removal of both if we want the legacy app in the same zip]

sbesson · 2015-01-14T11:13:10Z

Separate OMERO.insight bundles should also be available via the downloads page. The only place where we would have doubled size are the OMERO.clients for mac. As noted above this is a transition as we expect to drop the _Java6 bundle eventually.
Would be good to have @gusferguson's opinion on this, the major questions we need to answer in terms of packaging are:

what is the less confusing for our users?
how to properly document this (PR against ome-help?)

gusferguson · 2015-01-14T12:05:11Z

I would really like to see the Editor and Importer disappear from the bundles - they are very confusing for users.
We do 32 and 64 bit versions for Windows - so I presume 2 versions for Mac will be much the same overhead. As long as it is clear what is what the user probably won't care about size.
On the _legacy or _Java6 issue - I feel the _Java6 is much more intuitive and self-evident than _legacy - so my vote would go there.
Documentation will be fun - just have to see what it looks like and try and work out a way to make it obvious what a particular user needs.

jburel · 2015-01-14T13:23:37Z

@gusferguson: editor has been removed for 5.1. we will have to keep it for 5.0.x

chris-allan · 2015-01-15T21:27:33Z

Two .app's, OMERO.insight_Java6.app and OMERO.insight_Java7+.app, will now be included in the client ZIPs. We still have the issue of configuration file loading but that will have to be taken care of by @jburel.

jburel · 2015-01-15T21:30:24Z

great. I will start working on it tomorrow. Final adjustment on imageJ work prior to demo tomorrow.

joshmoore · 2015-01-16T08:05:16Z

(travis kicked)

mtbc · 2015-01-18T21:10:10Z

Ready for review again?

jburel · 2015-01-18T21:12:36Z

@mtbc: suggestions have been implemented. investigating solutions to get the config files picked up. Probably no need to list tomorrow

mtbc · 2015-01-18T21:41:04Z

Thank you, @jburel. Good luck with it.

jburel · 2015-01-19T21:13:33Z

PR opened against this PR.
Maybe for 5.1, we may want to include (e.g. under Contents/Resources) the config directory.
This will require an adjustment to dist.xml

jburel · 2015-01-20T09:53:24Z

@mtbc: to be listed tomorrow

ghost · 2015-01-21T09:42:58Z

Test platform: MacOSX 10.10 with Java 1.7.0_51 and Java 1.8.0_25. The _Java6 app (untested since I don't have Java6) warns than I need a Java6 VM [tested successfully by @qidane]. The new app works just fine, starts up and lets me log in, do stuff etc. I've tested the build on MacOSX and Linux, and tested the resulting Java7 artifacts, without any problems.

I would suggest removing the _Java7+ suffix (keeping _Java6). It makes the application title ugly in the menubar, and it's also what we should have as the default option. The only people who need the Java6 version are the small minority on MaxOSX 10.6. Maybe also rename the old one to _OldJava6 to highlight that?

Also, the Editor and Importer apps have no Java6/Java7 split. They need a _Java6 suffix to highlight that they won't work on older systems even if we don't provide Java7 equivalents.

There is this annoying UI glitch:

which goes away on resize. Maybe Java7 is not firing a resize event so it needs doing manually when the window is mapped?

dominikl · 2015-01-21T10:44:48Z

Built with Java 8, ran with Java 7, didn't notice any problems.
@rleigh-dundee Looks like to be a similar problem to #3174 (just had to make another call to pack() to fix this). For reproducing the problem in #3174 I needed exactly this setup, compile with Java 8, run with Java 7. Unfortunately this is not sufficient to reproduce the problem with the server dialog, can't see that, looks normal for me.

jburel · 2015-01-21T10:56:28Z

The UI issue will be covered in another PR.

ghost · 2015-01-21T10:58:46Z

From the build POV, looks good to merge. The cosmetic issues (application suffixes, UI) do need further work.

joshmoore · 2015-01-21T12:53:37Z

Waiting on appbundler modifications from @sbesson.

manics · 2015-01-21T15:10:25Z

$ open components/insight/OUT/dist/OMERO.insight_Java7+.app fails:

$ open components/insight/OUT/dist/OMERO.insight_Java7+.app --args container.xml $PWD/components/insight/OUT/app works

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.9.5
BuildVersion:   13F34
$ javac -version
javac 1.8.0_31

sbesson · 2015-01-21T15:10:33Z

Jar uploaded to our artifactory and accessible to Ivy via

<dependency org="ome" name="appbundler" rev="1.0.0">
    <artifact name="appbundler" ext="jar"/>
</dependency>

manics · 2015-01-21T15:15:58Z

However the CI artifact works:
https://ci.openmicroscopy.org/job/OMERO-5.0-merge-build/lastSuccessfulBuild/ICE=3.5,jdk=8_LATEST,label=octopus/artifact/src/target/OMERO.clients-5.0.6-119-0d5f460-ice35-b209.mac.zip

chris-allan · 2015-01-21T15:41:33Z

That is expected @manics. The configuration files are not copied in to the dist directory so those .app's will not work directly from there.

jburel · 2015-01-21T15:45:53Z

The idea (cf. a previous comment) is to move the config folder under Contents/Resources.
This should have been done a while ago.

jburel · 2015-01-22T11:08:21Z

for UI issue see #3375
Fixed in develop but not rebased.

chris-allan · 2015-01-23T08:58:06Z

This is going to require some more reworking. In adding the above three commits I've noticed that OMERO.editor and OMERO.importer .app's have been broken by the commits from @jburel above. This is because each of these is delineated by a command line option to specify the container.xml instance to use.

We'll need some time tomorrow to work through all of this.

jburel · 2015-01-23T09:12:43Z

@chris-allan: I will have a look either today or over the weekend

joshmoore · 2015-01-27T09:40:42Z

On 10.10, all three Java7+ apps launch for me.

sbesson · 2015-01-27T10:38:32Z

The thress Java7+ apps also work on 10.9.5 for me

pwalczysko · 2015-01-27T11:02:51Z

Tested OMERO.clients.zip on ice 3.3, 3.4 and 3.5 on the octopus build.
Mac OS X 10.8
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

All passed fine (6 clients per ice version tested, 2x ed, 2x imp, 2x insight each).

joshmoore · 2015-01-27T11:36:40Z

10.6 / Java_6: 🆗 (all three)
10.6 / Java_7+: double click instantly exits; no warning or error.

This commit adds a new `dist-osx-appbundler` target to OMERO.insight and adds it as a dependency to the OMERO.insight specific `dist` target. The `dist` target is used by the top level `zips` target which is used by overarching OMERO build system.

This commit switches to load the `appbundler` dependency from Artifactory as configured by Ivy. As Ivy resolution needs to be performed, JAR locations have been deferred to a new `appbundler-init` target which is now responsible for performing the task definition.

ghost · 2015-01-27T13:32:17Z

Also tested all three Java 7 applications on 10.10 and it's working fine. If we have the split into 10.6 and 10.7+ zips, that will also remove the need for the special application suffixes.

chris-allan · 2015-01-27T13:34:37Z

Force pushed this without JARs added to lib/repository and resolution of artifacts thanks to work from @sbesson.

 ______________
< Artifactory! >
 --------------
        \   ^__^
         \  (**)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||

sbesson · 2015-01-28T09:18:43Z

Thanks guys. Merging

OMERO.insight Java Application Bundler task for Mac OS X

sbesson · 2015-01-29T19:36:19Z

--rebased-to #3417

joshmoore added the dev_5_0 label Jan 14, 2015

chris-allan and others added 14 commits January 27, 2015 05:21

Add Java Application Bundler license to list

b8c7c78

Make dist-osx depend on dist-osx-appbundler so we can ZIP both

1a7daad

Make name changes to reflect Java version dependency

4a245c0

Add some documentation to the usage target

f4651af

Ensure dist-osx-appbundler stub has correct permissions

bf0638c

Set the use.dir property.

ebffd09

Review way we collect config and home parameters.

f3c7906

Use similar formatting to similar targets

9430ee6

Add and use new distEditor-osx-appbundler target for OMERO.editor

1e248db

Add and use distImporter-osx-appbundler target for OMERO.importer

6447a5a

Fix path check and config file check.

a81795a

Remove space.

d78586f

chris-allan force-pushed the app-bundler-task branch from f5167ec to b61bd57 Compare January 27, 2015 13:31

sbesson added a commit that referenced this pull request Jan 28, 2015

Merge pull request #3337 from chris-allan/app-bundler-task

e1f3bc1

OMERO.insight Java Application Bundler task for Mac OS X

sbesson merged commit e1f3bc1 into ome:dev_5_0 Jan 28, 2015

This was referenced Jan 28, 2015

Split OS X packaging into 2 sets #3407

Merged

Split OS X clients on the downloads page by Java version ome/ome-release#134

Merged

OMERO.insight Java Application Bundler task for Mac OS X (rebased onto develop) #3417

Merged

sbesson added this to the 5.0.7 milestone Feb 4, 2015

sbesson mentioned this pull request Feb 4, 2015

Split OS X clients on the downloads page by Java version (rebased onto develop) ome/ome-release#135

Merged

OMERO.insight Java Application Bundler task for Mac OS X #3337

OMERO.insight Java Application Bundler task for Mac OS X #3337

Conversation

chris-allan commented Jan 13, 2015

joshmoore commented Jan 13, 2015

joshmoore commented Jan 14, 2015

sbesson commented Jan 14, 2015

joshmoore commented Jan 14, 2015

ghost commented Jan 14, 2015

sbesson commented Jan 14, 2015

gusferguson commented Jan 14, 2015

jburel commented Jan 14, 2015

chris-allan commented Jan 15, 2015

jburel commented Jan 15, 2015

joshmoore commented Jan 16, 2015

mtbc commented Jan 18, 2015

jburel commented Jan 18, 2015

mtbc commented Jan 18, 2015

jburel commented Jan 19, 2015

jburel commented Jan 20, 2015

ghost commented Jan 21, 2015

dominikl commented Jan 21, 2015

jburel commented Jan 21, 2015

ghost commented Jan 21, 2015

joshmoore commented Jan 21, 2015

manics commented Jan 21, 2015

sbesson commented Jan 21, 2015

manics commented Jan 21, 2015

chris-allan commented Jan 21, 2015

jburel commented Jan 21, 2015

jburel commented Jan 22, 2015

chris-allan commented Jan 23, 2015

jburel commented Jan 23, 2015

joshmoore commented Jan 27, 2015

sbesson commented Jan 27, 2015

pwalczysko commented Jan 27, 2015

joshmoore commented Jan 27, 2015

ghost commented Jan 27, 2015

chris-allan commented Jan 27, 2015

sbesson commented Jan 28, 2015

sbesson commented Jan 29, 2015