Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] shipping directly a jre with an eclipse product on OSX

hmm now we have an update for our current product
where i changed the jre12.0.0 to jre12.0.2 and then it doesn't work..
the old one has a p2.inf of:

# Those would better be placed on the feature.jar iu instead of, but didn't find a way to add touchpoint for feature.jar
instructions.install = \
instructions.uninstall = \

and the new one:

# Those would better be placed on the feature.jar iu instead of, but didn't find a way to add touchpoint for feature.jar
instructions.install = \
instructions.uninstall = \

problem is after the update i have the new feature but the our ini file is not updated..
it has still the old dir, and the old dir is bogus (half deleted...)

what i did test before was coming from a release that had none of these features and then it seems to install it just fine.
But if it already had that then it doesn't work it seems.

Thats quite bad, because that means i have to always keep the version...  i can't update it.
(even if i put in a new jre install)

Does anybody has an idea about this one? That should work right? i can create a bug for this at


On Fri, 9 Aug 2019 at 09:21, Johan Compagner <jcompagner@xxxxxxxxxx> wrote:
yes i already have all that, that all working fine
Problem is that the p2.inf touchpoints stuff only is really working when you do an update from a p2 update site.

This is because in the end its all am matter where you create the installer from and how your link for example is done
For example in your that you have (the product zip of osx) that has that feature.
Does it there already have that link? Does zip support symbolic links?

But the problem is that i build on windows (and linux) and on both machines the output should be the same
So doing this:

wil not fix my problem, the osx.tar.gz file that we generate in the end will not have a link like that, how does for example your  
com.castortech.feature.jre.macosx.cocoa.x86_64_1.8.144 .zip 

look like?
how do you create that one correctly for example when building also on windows?

Mulit platform build is kind of annoying that that doesn't fully work.
I think tycho/eclipse should work with a container format like "tar" what the output of all stuff is so that you are never depending on anything on the system
(symbolic links should work under windows by the way, ntfs has junctions since i guess the beginning)


On Thu, 8 Aug 2019 at 17:45, Stéphane Vaucher <svaucher@xxxxxxxxxxxxxxxxxxx> wrote:
I don't know if this helps, but I have a feature that ships for an older JVM for MacOS/Linux/Windows. The master feature.xml has the conditional includes:
  1. <includes
  2. id="com.castortech.feature.jre.macosx.cocoa.x86_64"
  3. version="1.8.144"
  4. optional="true"
  5. os="macosx"
  6. ws="cocoa"
  7. arch="x86_64"/>
  8. <includes
  9. id="com.castortech.feature.jre.win32.win32.x86"
  10. version="1.8.144"
  11. optional="true"
  12. os="win32"
  13. ws="win32"
  14. arch="x86"/>

This is the p2.inf file for the mac version that fixes the links/permissions:

instructions.configure=\ org.eclipse.equinox.p2.touchpoint.eclipse.setJvm(jvm:../Eclipse/features/com.castortech.feature.jre.macosx.cocoa.x86_64_1.8.144/jre/Contents/Home/jre/bin);\ org.eclipse.equinox.p2.touchpoint.natives.chmod(targetDir:${installFolder}/features/com.castortech.feature.jre.macosx.cocoa.x86_64_1.8.144/jre/Contents/Home/jre/bin/,targetFile:java,permissions:755);\ org.eclipse.equinox.p2.touchpoint.natives.chmod(targetDir:${installFolder}/features/com.castortech.feature.jre.macosx.cocoa.x86_64_1.8.144/jre/Contents/Home/jre/lib/,targetFile:jspawnhelper,permissions:755);\ org.eclipse.equinox.p2.touchpoint.natives.ln(targetDir:${installFolder}/features/com.castortech.feature.jre.macosx.cocoa.x86_64_1.8.144/jre/Contents/MacOS/,linkName:libjli.dylib,linkTarget:../Home/jre/lib/jli/libjli.dylib);\ org.eclipse.equinox.p2.touchpoint.natives.remove(path:jre); instructions.unconfigure=\ org.eclipse.equinox.p2.touchpoint.eclipse.setJvm(jvm:null);

For Windows:
  1. instructions.configure=\
  2. org.eclipse.equinox.p2.touchpoint.eclipse.setJvm(jvm:features/com.castortech.feature.jre.win32.win32.x86_64_1.8.144/jre/bin);
  3. org.eclipse.equinox.p2.touchpoint.natives.remove(path:jre);
  4. instructions.unconfigure=\
  5. org.eclipse.equinox.p2.touchpoint.eclipse.setJvm(jvm:null);

I don't recall having issues with this code. The only annoying thing is that we need a checklist to ensure that we update the versions in the different files in a consistent manner.


On Thu, Aug 8, 2019 at 11:12 AM Johan Compagner <jcompagner@xxxxxxxxxx> wrote:
Just for some extra info

We use the chromium project 
on top of our product where we also add the java as a feature for the 3 platforms 

But for some reason the binary bombed out on the mac with an exception (hard crash of the vm)

After some searching using another jre that was installed on the system made it work.
So it was something in the osx java feature that we shipped

The problem was that in the openjdk.tar.gz file of osx there are symlinks (besides the executable bits that are already a problem)
but because i use untar of ant, (that doesnt' correctly handle symlinks) but also because i am building also on windows
and that eclipse/tycho in the end uses zip (not sure if zip does support symlinks), symlinks are converted to 0 bytes
And this is a problem for the /Contents/MacOS/libjli.dyli  that was symlinked to Contents/Home/lib/libjli.dylib  that last file is the vm argument itself
But somehow when using the native stuff of chromium it does expect that the one in MacOS dir is correct. (nothing else complains about that)

So what i did i just made sure that i "unlink" by really copy the whole file over:

then everything started to work..

In the end all this is kind of a bit tricky, you kind of want the executable bits and symlinks to work where ever you build it and where ever you archive it to..

In the end i could fix this by not really downloading and creating the macosx_java feature at the moment i make the feature 
but really do that after the full product is build and the if i make our osx specific tar.gz installer then copy the tar.gz of open.jdk in it (then everything would be always exactly the same)
But then i would have a problem with our update sites...


On Thu, 9 May 2019 at 11:51, Johan Compagner <jcompagner@xxxxxxxxxx> wrote:
Yes then it the eclipse executable (in jre/Contents/MacOS) has the X flag set
And also "java" in jre/Contents/Home/bin/
But the weird part is the jspawnhelper in jre/Contents/Home/lib hasn't...
So now i am wondering why there is a difference between java and jspawnhelper
because it has to he the touchpoint/chmod call that does it 
(because all executable bits coming from the original download of adoptopenjdk is already lost when creating the file)

So why wouldn't my second line in the p2.inf work...:


But anyway i can't rely on this because our product is also build on window machines and the output should always be exactly equal
So i keep my current ant script:

<tar destfile="${}/servoy_osx.tar.gz" compression="gzip" longfile="gnu">
<tarfileset dir="${}/osx_installer/" filemode="755" >
  <include name=""/>
  <include name="**/jre/Contents/Home/lib/jspawnhelper"/>
  <include name="**/jre/Contents/Home/bin/*"/>
  <include name="firstuse.command"/>
  <include name="**/*.sh"/>
<tarfileset dir="${}/osx_installer/">
  <exclude name="**/jre/Contents/Home/lib/jspawnhelper"/>
  <exclude name="**/jre/Contents/Home/bin/*"/>
  <exclude name=""/>
  <exclude name="firstuse.command"/>
  <exclude name="**/*.sh"/>

to fix all the executable bits for our installer.

But i wonder if i now do an upgrade, so that install will do an P2 update to a next version and we ship a new jre, will it then set the executable bit on the new jspawnhelper....

Will have to test this somehow


On Thu, 9 May 2019 at 10:23, Mickael Istria <mistria@xxxxxxxxxx> wrote:
And can you please try a build on Linux and compare?
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Johan Compagner

Johan Compagner
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Johan Compagner

Johan Compagner

Back to the top