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
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.

Regards,
Stephane


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

We use the chromium project https://github.com/maketechnology/chromium.swt 
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...

johan
 

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 feature.zip file)

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

org.eclipse.equinox.p2.touchpoint.natives.chmod(targetDir:${installFolder}/features/com.servoy.jre.macosx.x86_64.feature_12.0.0/jre/Contents/Home/bin/,targetFile:java,permissions:755);
org.eclipse.equinox.p2.touchpoint.natives.chmod(targetDir:${installFolder}/features/com.servoy.jre.macosx.x86_64.feature_12.0.0/jre/Contents/Home/lib/,targetFile:jspawnhelper,permissions:755);

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="${project.build.directory}/servoy_osx.tar.gz" compression="gzip" longfile="gnu">
<tarfileset dir="${project.build.directory}/osx_installer/" filemode="755" >
  <include name="Eclipse.app/Contents/MacOS/servoy"/>
  <include name="**/jre/Contents/Home/lib/jspawnhelper"/>
  <include name="**/jre/Contents/Home/bin/*"/>
  <include name="firstuse.command"/>
  <include name="**/*.sh"/>
  </tarfileset>
<tarfileset dir="${project.build.directory}/osx_installer/">
  <exclude name="**/jre/Contents/Home/lib/jspawnhelper"/>
  <exclude name="**/jre/Contents/Home/bin/*"/>
  <exclude name="Eclipse.app/Contents/MacOS/servoy"/>
  <exclude name="firstuse.command"/>
  <exclude name="**/*.sh"/>
</tarfileset>
......
</tar>

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

johan





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
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tycho-user


--
Johan Compagner
Servoy


--
Johan Compagner
Servoy
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tycho-user

Back to the top