TEST JAR: n/a - must switch to branch & perform gradle buildDeb and/or gradle buildRpm and then either sudo apt install ./...deb or sudo rpm -ivh *.rpm.
LEVEL OF EFFORT: major
DESCRIPTION OF CHANGES:
This took about a week and a day to implement, mainly because I didn't know what I was doing, but also because there are gradle plugin bugs and very poor plugin documentation. If I knew gradle better, it might not have taken so long.
There are 2 things I accomplished here:
I applied an icon to the java executable in the "dock" for linux
I implemented the production of .deb and .rpm files using gradle, which put the jar file in /usr/local/lib and an executable script in /usr/local/bin
I used a combination of 2 strategies to get this to work. I used the nebula.ospackage plugin and followed this blog post to create the .deb and .rpm files and I followed another blog post to get the script to build.
There are a number of issues with this implementation:
2 different shell scripts are created (because I used 2 different methods - but oddly enough, nebula.ospackage would not create any shell script unless the other method was implemented (which creates its own) - so you end up with 2 different scripts.
The fatJar isn't utilized. A fatJar is created and compiled, and I even managed to get it to copy into /usr/local/lib (along with the script that's created to run it in /usr/local/bin), but there was no way in gradle that I could find to add the jar location to the classpath option in the java command in the script. I eventually just gave up and went with the group of jars and its associated script.
A number of useless vestigial files are created (in the build directory).
The setupBuilder plugin would have been ideal, but it was producing a bad control file that I could not fix in gradle. I could fix it manually, but not before gradle would fail the build & abort.
This implementation is messy as a result, but it works!
NOTE: There exists a separate bitbucket issue to incorporate this build into a bitbucket pipeline.
Here are the commit messages:
Added a couple temp files I created (for convenience) to ignore. Fixed the pattern for files starting with a pound character. Had to escape the pound.
This version of build.gradle actually somewhat works - for creating a working .deb file for distribution.
It puts the jar and a shell script in /opt/local/treeview/{lib,bin} respectively.
The shell script needs to be tested. An icon is still needed. Vestigial code in the gradle script needs to be weeded out. A link from a bin in the user's path needs to be created.
This version puts things in the right place and actually works.
The last checkin was putting things in the right place, but the shell script was failing because it wasn't including the fat jar in the classpath argument to java. I just gave up on the fat jar and copied all the jar files to where they are expected using nebula/ospackage.
I took out some vestigial code.
Transferred install from /opt/local to /usr/local. Created a link from the bin & lib to the files in the corresponding directories in the treeview3 subdirectory.
Fixed an issue regarding a requirement that version numbers must start with a digit.
Cleaned up the gradle build file.
Added a line of code to set the icon for the java executable while running.
This should only have an effect in linux (& possibly windows). The Mac version is applied during gradle build.
Fixed the code which applies an icon to the java executable.
Made it only run when not on a mac. Consolidated the isMac() code. Corrected the image file from .icns to .png.
Removed a debug print.
Added a temp file.
Initial steps to building an rpm version of the treeview installation.
SUBMISSION DATE: 9/20/2017
ISSUE NUMBER(S): #541
BRANCH: https://bitbucket.org/TreeView3Dev/treeview3/branch/issue541-linux_build#diff
TEST JAR: n/a - must switch to branch & perform
gradle buildDeband/orgradle buildRpmand then eithersudo apt install ./...deborsudo rpm -ivh *.rpm.LEVEL OF EFFORT: major
DESCRIPTION OF CHANGES:
This took about a week and a day to implement, mainly because I didn't know what I was doing, but also because there are gradle plugin bugs and very poor plugin documentation. If I knew gradle better, it might not have taken so long.
There are 2 things I accomplished here:
I applied an icon to the java executable in the "dock" for linux
I implemented the production of .deb and .rpm files using gradle, which put the jar file in /usr/local/lib and an executable script in /usr/local/bin
I used a combination of 2 strategies to get this to work. I used the nebula.ospackage plugin and followed this blog post to create the .deb and .rpm files and I followed another blog post to get the script to build.
There are a number of issues with this implementation:
2 different shell scripts are created (because I used 2 different methods - but oddly enough, nebula.ospackage would not create any shell script unless the other method was implemented (which creates its own) - so you end up with 2 different scripts.
The fatJar isn't utilized. A fatJar is created and compiled, and I even managed to get it to copy into /usr/local/lib (along with the script that's created to run it in /usr/local/bin), but there was no way in gradle that I could find to add the jar location to the classpath option in the java command in the script. I eventually just gave up and went with the group of jars and its associated script.
A number of useless vestigial files are created (in the build directory).
The setupBuilder plugin would have been ideal, but it was producing a bad control file that I could not fix in gradle. I could fix it manually, but not before gradle would fail the build & abort.
This implementation is messy as a result, but it works!
NOTE: There exists a separate bitbucket issue to incorporate this build into a bitbucket pipeline.
Here are the commit messages:
Added a couple temp files I created (for convenience) to ignore. Fixed the pattern for files starting with a pound character. Had to escape the pound.
This version of build.gradle actually somewhat works - for creating a working .deb file for distribution.
It puts the jar and a shell script in /opt/local/treeview/{lib,bin} respectively.
The shell script needs to be tested. An icon is still needed. Vestigial code in the gradle script needs to be weeded out. A link from a bin in the user's path needs to be created.
This version puts things in the right place and actually works.
The last checkin was putting things in the right place, but the shell script was failing because it wasn't including the fat jar in the classpath argument to java. I just gave up on the fat jar and copied all the jar files to where they are expected using nebula/ospackage.
I took out some vestigial code.
Transferred install from /opt/local to /usr/local. Created a link from the bin & lib to the files in the corresponding directories in the treeview3 subdirectory.
Fixed an issue regarding a requirement that version numbers must start with a digit.
Cleaned up the gradle build file.
Added a line of code to set the icon for the java executable while running.
This should only have an effect in linux (& possibly windows). The Mac version is applied during gradle build.
Fixed the code which applies an icon to the java executable.
Made it only run when not on a mac. Consolidated the isMac() code. Corrected the image file from .icns to .png.
Removed a debug print.
Added a temp file.
Initial steps to building an rpm version of the treeview installation.