Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Michael Schnell
    @michael-schnell
    Yes. The first step would be to define your installation in a generic format. Then you create a real platform specific installer from that on the server. This avoids to re-invent the installer itself As this is already
    available.
    For example there is https://github.com/tcurdt/jdeb that can create binary Debian packages. The server could send a *.deb file back and starts normal package installation.
    Michael Schnell
    @michael-schnell
    By the way: Long time ago I created a little installer based on Webstart: http://fuin.org/kickstart4j/background.html . Webstart only updates the installer itself. But sooner or later you come to a point where native stuff is required. That was not supported wirh kickstart4j.
    Florian Brunner
    @puce77
    I see your points, some very good ones. I, too, think one of the trickiest parts of the solution I proposed is to get the native OS integration right, and as you point out there is a risk of reinventing the wheel.
    I see some pros and cons of the native package approach.
    Florian Brunner
    @puce77
    On the pro side there is clearly the easier OS integration once you have the native package. Maybe we could even get rid of the agent component?
    Some concerns which come to my mind when using this approach:
    Florian Brunner
    @puce77
    Stability: how feasible is it to create a stable cross-compilation pipeline which works for all the different kinds of applications. First experiments with javapackager (via Maven plugin) and a Drombler FX based application showed you have to consider a lot to make it work with all the tools. Similar things can be said about the agent approach, I guess
    Error handling:
    Florian Brunner
    @puce77
    What happens if something goes wrong during the cross-compilation process? When a vendor releases a new version, I guess you could provide the error message in the staging area. But what happens if there’s no interaction with the vendor, e.g. when there’s a new security update for a JRE?
    Scalability:
    Michael Schnell
    @michael-schnell
    Yes, that are indeed things to consider.
    I think building the artifacts is more like a build pipeline. You even can build it exactly with such (e.g. Jenkins)
    A step triggers other steps. If something fails, there is a notification of the owner of the build.
    A JRE is then just like any other dependency (only it‘s external). There might be a trigger for your build that is executed when there is a new JRE available.
    Michael Schnell
    @michael-schnell
    Testability is also a Pro as you can easily test artifacts from sub- steps . A Debian arti
    fact can be tested stand-alone.
    Florian Brunner
    @puce77
    Uninstaller would also be on the pro side as you could use the native OS tools to uninstall an application.
    What concerns me most, though is scalability.
    Currently I have very little computing and storage resources available.
    Now consider this solution gets popular and is used by hundreds if not thousands of applications.
    Florian Brunner
    @puce77
    For each new version of an application you would have to create all supported native packages. And some vendors might adapt a continuous delivery model, possibly releasing several times a day.
    And if there’s a new JRE version you would have to create new native packages for all applications which use this JRE.
    Unlike jar libraries, applications tend to become big, from a few MBs to several 100MBs and some even more than 1 GB.
    Florian Brunner
    @puce77
    Now you would also have to add a JRE to each package, making it even bigger.
    And multiply it with the number of supported platforms
    Florian Brunner
    @puce77
    Where should these packages be hosted?
    Florian Brunner
    @puce77
    I was thinking about a model where the applications would be hosted on web sites/ repositories of the vendors. JStore would only proxy the repositories and possibly caching some applications.
    Compared with the native package approach there would only be one package per application version unless the application uses some additional unmanaged native components.
    If there’s a new JRE version, nothing would have to be repackaged and no new storage would be needed, as the applications would share managed JRE installations.
    Florian Brunner
    @puce77
    Also with this approach the user can decide to try an unsupported newer JRE version when a vendor does not upgrade their applications.
    If the JRE is packaged along with the application, manual switching would not be this easy
    Florian Brunner
    @puce77
    And we also might have to consider private stores with private business applications.
    Though many companies are less reluctant nowadays to use SaaS solutions even for private software/ data. Others however still prefer on-premise solutions.
    Michael Schnell
    @michael-schnell
    Ah, ok. I thought if it more like a toolbox, not as a (proxies) service. So building the stuff would up to everyone them self.
    What is the goal of your service to act as a kind of proxy?
    Michael Schnell
    @michael-schnell
    If you have native installers, there is no need for jstore client or jstore. All native installers already have their own repository that mostly can also be used in a private environment (chocolatey, Debian, Maven, ...)
    Florian Brunner
    @puce77
    Ah, ok, now I see where you’re heading for. This was actually my initial approach and maybe I will still have to set something up like this: a Jenkins pipeline which releases (Maven release) an application using a generic format and then trigger native package builds on Jenkins slaves based on the generic application format (javapackager cannot cross-compile).
    Florian Brunner
    @puce77
    Then I would have to find an automated way to upload the native installers to the different app stores: Microsoft Store, Apple App Store, PPA, Packman etc. Likely the packages would also have to be signed.
    As pointed out earlier this will require quite some computing resources especially if there are many applications with many releases.
    Florian Brunner
    @puce77
    Unfortunately I don’t have the resources to provide such a service for others for free and I also haven’t found yet a good business model for such a service.
    Then there also some issues with packaged JRE approach (you can read more about this topic in my blog post; see the link at the top) and the mentioned app stores don’t provide first class support for Java applications AFAIK.
    Florian Brunner
    @puce77
    The solution I‘m proposing here tries to address all the issues mentioned in the blog post and it should be a solution that scales well/ doesn’t take a lot of resources.
    Florian Brunner
    @puce77
    But I‘m open to suggestions how to address the mentioned issues. Nothing is set in stone. I‘d like to find the best solution for the community to go forward from all the changes mentioned in the blog post.
    Florian Brunner
    @puce77
    The current backend mainly manages updates of some managed native components such as JREs. Applications could either be installed from a website using a JNLP like approach or by the discovery feature of the JStore backend. The JStore approach also allows for ratings and user feedbacks across platforms.
    Florian Brunner
    @puce77
    Florian Brunner
    @puce77
    I've recently updated the Drombler JStore software components: https://puces-blog.blogspot.com/2018/09/drombler-jstore-news-jre-rest-service.html
    Florian Brunner
    @puce77
    The REST services of Drombler JStore now support Java 11: Drombler/drombler-jstore@7c42438
    Florian Brunner
    @puce77
    I've just released a new version of Drombler JStore which now supports Java SE 11.0.1 and Java SE 8 Update 191