Support multiple release channels? about update4j

[mordechaim]

Thanks for your interest in this project.

I really have a hard time understanding your question. How do you define "multiple release channels" and what have you tried that didn't work?

Generally speaking, update4j was designed at a very abstract level, allowing maximum flexibility. We will probably solve this issue sooner or later.

[ChrisLMerrill]

Here is what I need - a stable channel and a development channel. The selection of channels was specified by a config file. If not present, updates were always pulled from the default (stable) channel URL. If present, the config file specified alternate update channels and which was selected. Alternate channels would update from a different URL. This allowed developers or early adopters to get the latest, potentially unstable, changes immediately after our CI system spit out a new build.

[ChrisLMerrill]

Another detail - in addition to updating from a different channel, the files were stored in a different place. So not only could the user switch receive updates from different channels, they could actually switch between the two different versions with ease.

[mordechaim]

The easy way out would be to have 2 update4j configuration files and choose which you want to load according to you needs. The more advanced way -- if you really want only one config -- would be, to play around with properties. for instance, the "<base>" element's "uri" attribute should point to some system property and set that property according to your channel before loading the config. I'd personally stick to the first solution.

[mordechaim]

Just immerse in the idea that with update4j 'you' create the startup life-cycle, not the framework and you only get control after launch. This is critical for the first solution.

[ChrisLMerrill]

Ok. I will start digging in and see how it goes.

Thanks!