Hey y'all!
I've been a long-time MRL user, and today I just looked in my Raspberry Pi's SD card to find I had literally 13 different installs of MyRobotLab... I immediately started thinking "there must be a better way to handle this", and did some research, and found the JDeb project. It's a Maven plugin that automatically creates Debian package archives that can be installed by running the usual "dpkg -i package.deb" command. From just looking at the getting started pages, it seems like a pretty easy thing to add to our Maven build process (I think, I haven't yet looked at how pom.xml is generated), and would allow Debian users to easily and quickly install MRL system-wide, while also handling version control (updating is as simple as installing the new .deb file). In addition, it would make building projects that depend on MRL a lot easier (such as the InMoov scripts, which could be packaged in another deb file with dependencies on MRL).
So what do you guys think? Is this a feature we want? If so, I'll start looking into the pom.xml file generation and see if I can add this easily without breaking anything else ;)
Pros and Cons
I like where your coming from, however,
One of the big pros for the MRL system is it's not OS or even Processor specific.
What you suggest would be great if you could also implement it on MacIOS and windows (all flavors)
While developers and advanced user level people may be comfortable with the Debian system, the vast majority of users are not.
As a Raspi3 user myself, I think this would be great, because updating to the latest version would be a simple case of running "sudo apt-get -update" and "sudo apt-get -upgrade"
and that can be automated.
But you do need to allow for all the other platforms.
Thanks for the feedback
Thank you Ray for pointing out the flaws in my proposal. I use Linux exclusively, so I kinda forgot about the other operating systems ;)
Did some more digging, and found that there are also Maven plugins for generating Mac apps and Windows executables, however that seems like a lot of work to do and a lot of things that can go wrong, so perhaps it's best to wait on that until the next release.
Thanks!
There may be hope yet
During the early stages of trying to get Nixie working using the maven repository, there was some discussions regarding the versioning of various jar's.
For now, this is limited to the installation process, but it is possible, for a periodic service to run, and save back the last run date/time of a check online to see if there has been an update.
This is something that will have to be considered carefully, you don't want this check being done too often or it may crash the limited servers we have.
If an update is found, then the runtime service could potentially download the update and either install it then and there, or schedule that to occur during the next startup. If updates have been downloaded, then schedule a restart of the services at a user configurable time, ie 2:00am or wait till next restart.
I think that this would be possible for use inside that java environment, there for OS independent.
when it is all said and done, the only version of MRL that is being updated regularly, is the development version, currently Nixie. the current release version Maven get very little if any updates at all. From that perspective, do we need the auto update feature?
Hi AP, Yes it's nice to have
Hi AP,
Yes it's nice to have a native installer and Yes its nice to be platform independent.
heh - two true but contrary statements...
Since Java 8 was release (Java 9 has a lot of bug fixes to this) there is the
JAVA PACKAGER TOOL (woohoo!) https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/packager.html
This now comes with the JDK - and I've experimented a little with this. So, there is interest, but there are some problems with it too. If your interested, I'd like to know what you think of the tool. I had to tweak it a bit to get it to work, additionally the JDK 8 version docs are almost non-existant.
Javapackager thoughts
Thanks for the suggestion GroG. I took a look at Javapackager and got it to create a Debian package for me (I don't have a working Windows computer or a Mac to test on them), but I noticed some peculiar things about it. For one, it seems to package an entire Java runtime inside of the package. That's perfectly fine (in fact probably preferred) for Windows executables, but for Debian type packages it would be far better to define a dependency in the .Deb to avoid having duplicate Java runtimes. I haven't done much research at all into how Mac handles apps, but my guess is it's a lot like Windows executables in that they don't have any dependency information stored inside, so generating a dmg file in this way should also work just fine.
Second, I'm not exactly sure what tweaks you had to make, Javapackager worked perfectly for me right out of the box. Although I was running the version that came with OpenJFX instead of oracle's version, if that makes any difference. OpemJFX's version also came with man pages that helped a lot in figuring out all of the options.
Finally, speed seemed to be an issue with my test. I was running it on an old Acer Aspire One netbook running Ubuntu 16.04 LTS, and it took approximately 5 minutes to generate a .Deb package. From what I could see, the majority of that time spent was copying the system JRE to a temp directory and then compressing it for usage in the package. Very little time, about 30 seconds, was spent accessing the MyRobotLab.jar file. Building a package on a newer PC, one with an SSD, should be significantly faster, but I'm not at the house now to test on mine to get numbers.
So those are my thoughts on javapackager. Definitely something that we could use, but it does have some issues we might need to work around.