Maybe this is abit far fetched. I get the impression that we are (need to be) moving from a "per artifact" towards a "deployment" paradigm.
Approaches pioneered by crankstart and the provisioning model may become desirable (as an option) for the installer. By specifying the desired deployment state in a provisioning model file, the installer could make sure it has all required artifacts available (e.g. local folder, maven repository, etc). Once that is the case it could update/install/uninstall as it sees fit in order to attain the desired system state. This would make the question of "update vs install" mute. Also this new feature does not preclude the old behaviour. One open question, however, would be how partial deployments could be controlled via provisioning model and the rest via the current mechanisms. Thoughts? Regards Julian On Tuesday, September 22, 2015, Carsten Ziegeler <[email protected]> wrote: > Am 22.09.15 um 01:24 schrieb Justin Edelson: > > IMHO, coming up with general rules is going to be close to impossible. > > Instead, we should make this configuration explicit, I.e. Have a > > configuration on the installer which declares the action per BSN. > > > > Well, right now we have general rules and they work for the majority of > cases well. > I've had several discussions with different people over the past years > and it seems changing our rules to take the major version number into > account is a good compromise - which again should work for the majority > of cases. > Granted, a general rule does not always work so we need a way to > influence that. > I think we all agree that we need this, they tougher question is really > how? So far the OSGi installer has zero dependencies to configuration > admin and I don't think you want to add a configuration to config admin > whenever you put a file in an install folder. > In general, as soon as you have to provide two pieces (the artifact and > the configuration for that artifact) we might run into problems. So it > would really be good if the artifact itself contains all relevant > information. > > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] <javascript:;> >
