Support use of plugin with JDK6 #36
Comments
compile using source and target 1.6 instead of 1.7 Closes #36
compile using source and target 1.6 instead of 1.7 Closes #36
|
Yes, in principle it is possible to use JDK 6 and also to compile the plugin with target 1.6. But the plugin by default generates JNLP files that use some features of Webstart that require Java 7. These are used to enable deploying the generated folder with JLNP file and jar files directly to any HTTP server. To use Java 6 you must use the servlet and cannot just deploy to a normal HTTP server. The jnlp war plugin removes these Java 7 features from the JNLP file again and generates a War file that should be deployable using Java 6 only. But the servlet container must support servlet 3.0. |
|
You are my hero! Thank you :-) How can I test out a pre-release version of your commit and when do you think we will see this feature in a released version? |
|
The release yesterday did not work due to an OutOfMemoryError on travis. I retriggered the job and now the version 1.1.0 is released. Please check. |
|
Thank you very much! I tried doing a build with JDK 6 after wiping out my gradle cache for good measure and I get an error. Did you by chance do the build with JDK 7? Please let me know when you wish me to try another version. |
|
I did the build with JDK 7, because Travis could not build with JDK 6: $ jdk_switcher use oraclejdk6
Sun/Oracle JDK 6 is EOL since November 2012, and is no longer supported. Please consider upgrading...
The command "jdk_switcher use oraclejdk6" failed and exited with 1 during .gradle-jnlp-plugin does not depend on any other plugin, only GPars and webstart-jnlp-servlet (for generating the JarDiff files). Your error seems to be during loading the gradle-ospackage-plugin, which is most probably applied in your build.gradle. |
|
Happy new year Tobias. Thank you for your terrific response on this issue even during the holidays. My work with this plugin is ready to commit but for this issue. I looked into Travis and it appears that just like Jenkins it allows a job to use whatever JDK its wants though the default is JDK 7. This can be overriden for a specific Travis job: https://blog.travis-ci.com/support_for_multiple_jdks/ "The Travis CI environment provides Oracle JDK 7 (default), Oracle JDK 8, OpenJDK 6, OpenJDK 7, Gradle 2.0, Maven 3.2 and Ant 1.8, and has sensible defaults for projects that use Gradle, Maven or Ant." I would be very grateful if you could do a release with JDK 6 bytecode. I am available to help if you like in any way including if you wish to add me to the project. Please let me know what to expect. If this cannot be done then my plan B is to build the plugin on my own with a private release version and publish to our internal Artifactory. I would very much prefer not to do this if possible. TIA. |
|
I hessitated to switch to openjdk6, because I am not sure if this might cause problems elsewhere. I just accidentally committed and pushed to master to use openjdk6 (wanted to use a feature branch). But it does not build, because Grgit, which I use for release, does not work with jdk6 (https://travis-ci.org/tschulte/gradle-jnlp-plugin/builds/189596436). I removed the commit again and force-pushed. But as I already wrote, I am sure that this would not fix your issue anyway, because you seem to have an issue with another plugin. |
|
Hi Tobias, I am not sure I have the necessary background to understand all the constraints preventing building and publishing a release of this plugin that will work with JDK 6. For example, I wonder, why could Grgit alone not use JDK 7 while all else use JDK 6? In any event, my plan B is to build the plugin myself with JDK 6 and publish it in my private Artifactory repo. This is not ideal but it gets me unstuck. Can you please tell me the steps to do this? Currently when I build from cloned master it produces version 1.0.1-develop-SNAPSHOT. But the latest released version seems to be 1.0.2. To summarize to build our own private version of the plugin and deploy to our private Artifactory I am looking for answers to the following:
It would be nice to have some documentation targeted for developers of the project where this info can be kept. Here is the output of my git status command: |
|
The default Branch in GitHub at the moment is develop, but the latest version is master. Now that you have published your own version of the plugin to your artifactory, have you been able to build with java 6? |
|
I realized there is no need to build with JDK 6. I built with JDK 8 and only specified sourceCompatibility and targetCompatibility to be 1.6 which is alreday in my patch as shown below: THis guarentees that the byte code emitted is JDK 6 byte code and that is all to allow an app based on JDK 6 to be able to build with the excellent gradle-jnlp-plugin using JDK 6. In summary, I think you can do the same in the actual project and generate plugin with JDK 6 bytecode. Thoughts? If you agree then a release with all my patches for this and related issues would be awesome. |
|
Yes, and exactly that was done with https://github.com/tschulte/gradle-jnlp-plugin/releases/tag/v1.1.0 20 days ago. Or am I missing something? |
|
Hmmm. I will test again but I thought that version was JDK 7 byte code meaning that the patch segment below was not applied: Let me retest and report back. Can you tell me what version to declare for the plugin to be sure? Judging from pom.xml it should be 1.1.0. Will test with that. |
|
Hi Tobia, it seems that version 1.1.0 works just fine. I am not sure where I mistakenly thought we had an issue. My aopology for the time you spent looking into this due to my mistake. Thanks again for a terrific plugin. |
issue36-jdk6-support.patch.txt
Currently the plugin is compiled with target version 1.7 which prevents it from being used in projects that are constrained to use JDK6. Since JNLP is usually used by older Java projects there is a need to support projects built and run on JDK6.
Would it be possible to have the target version be 1.6 to allow broader use. I have attached a patch to address this need and would be grateful for your consideration to include it in next build of this awesome plugin. Thanks in advance.
The text was updated successfully, but these errors were encountered: