- 
                Notifications
    You must be signed in to change notification settings 
- Fork 185
[Build] Collect native sources in Jenkins pipeline with Java script #973
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Build] Collect native sources in Jenkins pipeline with Java script #973
Conversation
6b92179    to
    afe1743      
    Compare
  
    23c1fae    to
    1c607b9      
    Compare
  
    29db6cc    to
    0650d8c      
    Compare
  
    in order to replace ANT tasks with JavaScript (which require Java-11) in Jenkins pipeline. Stash native sources not-zipped to save the zip and unzip steps. Additionally move all remaining ANT tasks to run a native build in a local Maven for the running platform completely to the maven-antrun-plugin configuration. Furthermore move declaration of tools to the common Jenkins pipeline section to make them usable in all stages. Since eclipse-platform#633 the JDK on the native-build-agent's PATH is not used anymore when building the native binaries and thus it is not required anymore to keep the PATH untouched. Part of - eclipse-platform#513 - eclipse-platform#626
0650d8c    to
    ae48842      
    Compare
  
    Since eclipse-platform/eclipse.platform.swt#973 the I-build (like the SWT build) requires a java-17 (or later) jdk on the PATH system environment-variable in order to launch a jdk>=17 with the 'java' command from the CLI. Just setting the JAVA_HOME variable to a path pointing to a jdk-17 is not sufficient since the the java executable is usually located in '$JAVA_HOME/bin'. And while the maven launch script searches in '$JAVA_HOME/bin' for a java executable to run the build itself, a simple java command on the CLI isn't that smart. Previously java would just run the default default java version on the Jenkins executor. In general this simplifies the build-configuration because the JDK to use is only defined once and used everywhere. Fixes eclipse-platform#1724
Since eclipse-platform/eclipse.platform.swt#973 the I-build (like the SWT build) requires a java-17 (or later) jdk on the PATH system environment-variable in order to launch a jdk>=17 with the 'java' command from the CLI. Just setting the JAVA_HOME variable to a path pointing to a jdk-17 is not sufficient since the the java executable is usually located in '$JAVA_HOME/bin'. And while the maven launch script searches in '$JAVA_HOME/bin' for a java executable to run the build itself, a simple java command on the CLI isn't that smart. Previously running the 'java' command would just run the default default java version on the Jenkins executor. In general this simplifies the build-configuration because the JDK to use is only defined once and used everywhere. Fixes eclipse-platform#1724
Since eclipse-platform/eclipse.platform.swt#973 the I-build (like the SWT build) requires a java-17 (or later) jdk on the PATH system environment-variable in order to launch a jdk>=17 with the 'java' command from the CLI. Just setting the JAVA_HOME variable to a path pointing to a jdk-17 is not sufficient since the the java executable is usually located in '$JAVA_HOME/bin'. And while the maven launch script searches in '$JAVA_HOME/bin' for a java executable to run the build itself, a simple java command on the CLI isn't that smart. Previously running the 'java' command would just run the default default java version on the Jenkins executor. In general this simplifies the build-configuration because the JDK to use is only defined once and used everywhere. Fixes #1724
| @HannesWell with this commit, how do I manually (re)compile the SWT native binaries, especially the Windows .dll files, using  Or, is there now a different (new) way to (re)compile them using  Here's my use case: I've been using  ant -f buildSWT.xml build_libraries -Dswt.os=win32 -Dswt.ws=win32 -Dswt.arch=aarch64 -Dtargets="aarch64 all install" -DSWT_JAVA_HOME=%JAVA_HOME%With this commit, the above  | 
| To compile the native binaries locally with maven it is sufficient to run If you also want to build the jars you have to run the build up to a later phase like  If that takes to long for you, you can just directly run two commands to collect the native sources and compile them as it is implemented in the  | 
| Thanks, but it should be the  The caveat: there must already exist the  And my ultimate goal is to cross-compile from a Windows x64 host to generate the binaries for the Arm64 target, so the command becomes: Thanks for your work to simplify these SWT build scripts. | 
| 
 That's right, sorry for the confusion. So for my WoA .dll production, the command series should be (running on a WoA box): 
 If you just run the mvn command from the swt repository root, then that file is generated (that's done when the  If you want to reduce your build time you could use the  
 That should work yes. In order to avoid the need to specify the targets on the CLI you could simply create a org.eclipse.swt.win32.win32.aarch64 fragment as copy from the existing windows fragment basically replacing all x86_64 by aarch64 plus the adjustments of the make files (but you probably know them better than I). | 
in order to replace ANT tasks with JavaScript (which require Java-11) in Jenkins pipeline.
Stash native sources not-zipped to save the zip and unzip steps.
Additionally move all remaining ANT tasks to run a native build in a local Maven for the running platform completely to the
maven-antrun-plugin configuration.
Furthermore move declaration of tools to the common Jenkins pipeline section to make them usable in all stages.
Since #633 the JDK on the native-build-agent's PATH is not used anymore when building the native binaries and thus it is not required anymore to keep the PATH untouched.
Part of