We are pleased to announce the availability of Servoy 2019.06.0 (release number 3502)
This version is available through the the download site
We ship from now on by default only archive installers, so for windows a zip file and for osx/linux tar files.
That people can just extract and run. For OSX you need to make sure you follow a few steps (run firstuse.command first and then allow the app to run)
We now ship a java with our installation (Java 12). So there doesn’t need to be a java installed on the system anymore.
Also with a next update, we can update the java version with it so no need to keep it up to date yourself anymore.
The update site can’t be used to upgrade from 84 to this release, a bug in the eclipse update mechanisme will result in a broken installation.
So a clean install needs to be done if you come from 84 (but you can reuse the existing workspace just fine)
Upgrading from 2019.03 or higher should be fine. (with the “latest” update site url)
This is a release in our quarterly release cycle, if you want to stay on the LTS path you need to stick to 2019.03.1 and enabled only the lts update site.
For more information for this release: whats new
Or look at the cases fixed for the first and second release candidate
for this final build we fixed mostly stuff for the Form Designer editor and a few regressions found on cases that did go into this release.
What is the reasoning behind the fact that Servoy no longer distribute the single installer for all platforms?
Because this means we have to manage 3 different packages that contain a lot of stuff that we might not want in our installations.
Besides the normal all in one installer we have now installers per platform (windows, osx, linux)
These installers are just zip/tar files that just needs extraction in a directory.
On OSX you need to run “firstuse.command” before starting the developer.
An installation (coming from the normal installer or from a platform specific archive) is now shipping with with a Java vm (Java12)
So for the platform specific archives you don’t need to install or java have on your system.
The all in one installer still needs java for itself.
Where can we find the All-In-One installer for 2019.06? Isn’t neither available in the download page nor on the build server (2019.06 isn’t available on the build server at all, except maybe in release or master?).
We aren’t particularly interested in overhauling our build process, which is based on the All-In-One installer
And I hope/presume that installing the bundled Java version can be disabled in the All-In-One installer, just like all other components? Cause we definitely don’t want to be forced to use a specific Java version and/or vendor
What is the reasoning behind the fact that Servoy no longer distribute the single installer for all platforms?
Because this means we have to manage 3 different packages that contain a lot of stuff that we might not want in our installations.
because the combination installer is now 700MB, which is a huge one
these archive installers is way faster to use and to install.
There is still a all in one installer, but why do you really need it? whats the use case?
you don’t have to use that Java version that we ship with it.
you can change the servoy.ini file just fine, pointing to another java version to what ever you want
But running the developer in something shouldn’t have much effect. You should be able to use any java version you want to run and debug.
(there could be potential java changes/related bug that we need to fix for a specific version of java because they changed some implementation, but that doesn’t happpen that often)
we want to get rid of being depending on the java version for the developer, it is integrated in our product, so the full installer will also have it (we also will update the java version through the developer update site)
jcompagner:
because the combination installer is now 700MB, which is a huge one
these archive installers is way faster to use and to install.
There is still a all in one installer, but why do you really need it? whats the use case?
Like Robert mentioned: for 3 platforms, you need to manage (store/download) 3 different packages.
This is 3 times approx 440MB against downloading the all-in-one installer of 700MB.
Bandwidth is not an issue nowadays and the same can be said about storage, but keeping track of 3 different packages is a pain.
Just leave the all-in-one installer available to anyone who prefers to work that way.
You are asking about ‘our’ use case, but that’s exactly what we want to know for the all-in-one installer no longer being available.
File-size is no reason…
jcompagner:
who on one kind of pc/laptop is downloading all 3 packages?
whats the usecase? Where do you do that?
For a start I run both Mac & Windows because the projects I’m working on use either one or both.
I try to run everything on Mac, but some environments are Windows only by design.
Occasionally I run stuff on Linux, so yes… I need 3 installers.
As there’s not always a choice for version in projects, I need to download 3 archives now and keep them for future use.
I just don’t see why not leave it up to the developer what he/she prefers?
Where does this head in the future?
My biggest concern is the fact that I have no choice of what it all installs. The all-in-one installer gave us the option for Developer or Server, bundled PostgreSQL or Community PostgreSQL (installer by EDB) or connect to an existing one, examples or not, etc.
Now I have to install everything (including the JVM) and then go in and remove/edit what I want to change.
Also one need to manually run some scripts to make it all work properly. I don’t think this is a good ‘first experience’ with the product either.
I do get the reasoning behind bundeling the JVM. Vendors like Jetbrains (IntelliJ, WebStorm, etc) and others do this too. It means one doesn’t even have to have Java installed, it just works. Of course it does mean that Servoy need to support the Java (security) updates for these installations (and not for only 3 or 12 months, but longer).
But not every shop wants this. Like Paul said some shops standardize on a certain Java vendor. Be it Oracle Java, HotSpot, OpenJ9, Azul Zulu or other. And not to mention the specific version of the JVM.
For all these reasons I believe it would be a better solution (and experience) to have an installer that allows you to choose if you want the JVM, PostgreSQL and other options, which then sets it all up properly ready to go.
Now if you say that the installer becomes too big I would say that a lot of OS updates (desktop/mobile) are larger than 700MB, and nobody is really bothered about that.
But if you really have to trim the size of the installer you could go the same route as you went with the Community PostgreSQL installation. You download it when needed. Of course this requires an internet connection so offline installations might be a problem.
But if you really need to make it 3 different packages then please, please, make it an installer that gives us a choice what it installs (and set it up ready to go).
Having a java installed on the system, is more and more a problem
We have a lot of problems of new customers that where struggling with this…
Or that they have a 32 bit java installed then nothing works…
So now we are fully in control. we even update java for you through a Servoy update… (if java 13 is out we will just update it)
For the database we yes install now also basic postgresql, but only by default the binary, you have then the choice after unzip and run it the first time, do you really want to init the database ? (yes, yes with sample, or never)
For a first time user this is way easier
For existing stuff (that do download a new installer) this is way way faster, its just unzip and run, Yes OSX is a a bit annoying that you have to run the firstuse.command, but this is only OSX
0
So the only thing you now get out of the box is 1 dir “postgres_db” that takes up a bit of space… Yes you have to remove the start up script in servoy.properties (or servoy developer preferences) to not also run it when developer starts
For the most part i also expect that you just update the developer through the update site
I almost never go to eclipse.org and download the zip again (yes for 20 years or so i download a zip there, i would hate it if that would be an installer…)
My eclipse i always just updated through “check for updates”
Java will be always in the product, because it is really a feature of the product this will not be removed from it. This way it is also update able by us, its really part of the eclipse servoy.product feature.
By the way a bit of disk space is way less of a problem for me that a huge download,
Java is not really in the way its just a dir in the feature/plugin folder… You can point to another just fine
Same for postgresql_db folder it is just a binairy set, you don’t need to use it
jcompagner:
Having a java installed on the system, is more and more a problem
We have a lot of problems of new customers that where struggling with this…
Or that they have a 32 bit java installed then nothing works…
The installer could check for this, no? If yes, then it should not be an issue. Just warn that they need to install 64-bit Java or the bundled JVM.
jcompagner:
So now we are fully in control. we even update java for you through a Servoy update… (if java 13 is out we will just update it)
Also if I still use 2019.xx 3 years later?
jcompagner:
For the database we yes install now also basic postgresql, but only by default the binary, you have then the choice after unzip and run it the first time, do you really want to init the database ? (yes, yes with sample, or never)
For a first time user this is way easier
For existing stuff (that do download a new installer) this is way way faster, its just unzip and run, Yes OSX is a a bit annoying that you have to run the firstuse.command, but this is only OSX
I wouldn’t consider this easier for a first time user. Nothing is easier than hitting Next in an installer and let it take care of any setups.
I believe there is already a post on the forum about PostgreSQL not running in 2019.06. I bet that it is because they weren’t aware of the need to run a script first. In other words not a good experience (and an unnecessary support call)
Also there are a lot of developers (like me) that have (for various reasons) multiple versions of Developer installed on their system. So ‘check for updates’ is not an option then.
you shouldn’t use 2019.03 3 years later, very very bad idea
We have now LTS (1 year) or “latest” releases quarterly, you should move, just like the chrome browser, just kind of like they want now with java (be on an LTS or be on the latest)
But even if you keep one release for 3 years, that is not really a problem, it is working fine with that java version, it is only used for our developer, and its only running our developer, so security wise there is not a problem (its not integrated in your os)
I agree it is very annoying if you use the default system “unpacker” of OSX that even if you say "yes i know it is downloaded i allow it’ it is STILL in a sandbox (if you would unpack with a 3th party tool it is not a problem)
but yeah Apple makes all stuff difficult, that is just a fact of live.
I like to solve it to not give you a .gz.tar file but a DMG with a signed application, then it is just drag drop (which i think most osx users are used to)
but it is very hard to make that in a build street that is running on linux or windows. You really need to have a mac for that to be able to do that (there is a lot of questions for this on the internet…)
But maybe in the future i can sole this by having some kind of osx servers in the cloud where i can send over the current tar.gz file and i get back a signed dmg container…
But on windows or linux it is really straight forward, download, unzip, run
Had a new customer (prior FoxPro user), and had to walk him through Servoy install today. He naturally unzipped it into a temp folder, which he normally deletes at regular intervals. He had no idea what to do with the zip. There isn’t a ReadMe.txt in there, so you are just expected to know to go into Developer folder and click on Servoy.exe. He then thought when he ran the servoy.exe in the developer folder that it did the install on his PC. I had to explain that the zip was the install. So then he wanted to drop it in his C:\Program Files and is hoping for a start menu to show up. It was confusing to him. One bright side is he didn’t have java installed, so the bundle was convenient. But really, the installers at adoptopenjdk.net are pretty good now, so that really isn’t helping much. I think this will just start a new problem of people downloading and accidentally deleting their entire Servoy installs.
It screws my docker builds. The URL to get the exact build and install the jar was all automated. It also downloads shit that I never needed before. I don’t want the developer folder (with java binaries) on my docker app server installs. Yes the jar is bigger, but the base image doesn’t get re-built that often.
At least include the jar for those that want it. Don’t link to it on the download page if you wish, but just put it in the wiki somewhere so we know what the URL structure is to get it.
yes we should add a readme.txt into the root of our installs
Thats a good suggestion (to explain what this unzip really is, wat they should be starting, and that they can create a short cut to it?)
I guess this is a bit different based on windows or osx (the wording)
That we have java inside it now will not change no matter what “installer” you will take, this is part of our product and eclipse builds it as 1 big package (that we then make special installers/zips for)
To change that would mean really having 2 different kind of products and doing quite a big build 2 times, it is really integrated into one thing.
(thats why we can also update it through our update site)
I personally don’t get how this affects docker installs. what is inside a docker? I would say you use docker to make deployment sites where you run the your deployed solution in for testing/staging or production?
You don’t run the developer from a docker right? I would think that the dockers that you create you get from a WAR export from a developer (ui or command line) and then include java/tomcat/war inside it…
jcompagner:
You don’t run the developer from a docker right? I would think that the dockers that you create you get from a WAR export from a developer (ui or command line) and then include java/tomcat/war inside it…
Yes, we do. Who manually generates WAR files anymore?
We have 2 different docker images. Here is an example of our common setup…
When we commit, there is a hook in git/svn which sees the code change, then spins up a docker image of Servoy developer. The docker image will run the unit tests, and if successful, builds the WAR and uploads it somewhere (like S3)
Separate docker images run the Servoy servers. They look for a WAR file at some location (like on S3), which are built from step 1, and deploys those.
So, now with this change, all that breaks. I need to have some switch based on which version since <=8.x are jar installers, and newer ones are zips. I also loose the ability to just install the application server, since the zip has both, but I guess I can just delete that. Also, we don’t know the URL structure yet to get specific builds. We need to be able to link our docker builds to a specific URL to get the ZIP for a specific build number, and currently we can’t do that (but we could before when they were jar installers).