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
