I've been thinking about this, and really we're already produce all of the artifacts we'd need via the launchpad / starter builder project, there's just nothing in place to support the upgrade. I'm not sure we'd even need to shut down the Sling instance, we could just provide an upgrade mechanism which extracts the builder JAR, installs the bundles and then parses / executes the repoinit file.
I would think there'd need to be some concept of a minimum version, e.g. the oldest version capable of being upgraded to a version, but otherwise we should be able to support pretty painless upgrades via such a process. The only other thing I could think that could be a problem is deprecated bundles as there's not really a good mechanism (at least I can think of) to differentiate a deprecated bundle and one which is user installed. WDYT? On Thu, Aug 2, 2018 at 8:20 PM Jason E Bailey <[email protected]> wrote: > Yeah the dependency thing has always been problematic. I had a contractor > once did a crazy thing with one of my AEM instances where it became the > provider of the parent POM through a dynamic generation. Or something like > that. > > Conceivably, The sling starter should be able to generate a file with all > the bundle dependencies in it. Or it may even be a value add to have a > service generate that list. > > From an upgrade perspective, you should be able to do exactly what you > describe. Unless there are additional steps that would need to take place. > That goes back to thinking of Sling as a product. How would these > additional steps occur. There should be upgrade documentation etc. > > - Jason > > On Thu, Aug 2, 2018, at 2:31 PM, Andreas Schaefer wrote: > > From a customer point of view I would like to see something along the > > line of the in-place migration of AEM. > > This is a scenario I can think of: > > > > 1. Sling releases a new version > > 2. Customer shuts down Sling > > 3. Customer downloads the JAR / WAR file and replaces the old with the > > new JAR / WAR > > 4. Customer starts Sling with the new version > > 5. Sling uses now the OSGi / Felix from the new version and all the new > > bundles from Sling(start) > > 6. Customer migrates its bundles / packages to the new Sling version and > > installs it (if necessary) > > > > Another issue I ran into with trying to upgrade to a new Sling version > > (10) is that I had a hard time to figure out the correct dependencies. > > It might be great to have a POM of a Slingstart release with all its > > dependencies or maybe an Uber jar with all code merge into it? > > > > Cheers - Andy Schaefer >
