Oliver Lietz wrote > On Wednesday 29 March 2017 08:00:27 Carsten Ziegeler wrote: >> Oliver Lietz wrote >> >>>> It would be good if we have this description only once in our code base >>>> and not several times and can then generate different artifacts (if >>>> needed) out of it. >>> >>> Right, but I'm pretty sure I raised my concerns generating Karaf Features >>> and Configurations (and repoinit statements) from provisioning model >>> already. >>> >>> * Launchpad is _unstable_ most of the time (using snapshots mostly) while >>> Karaf Features are _stable_ (only a few snapshots left). Launchpad is in >>> fact the test bed for AEM, but Sling Karaf aims at good user experience >>> and production readiness. >> >> Well, we decided to not use snapshot dependencies in launchpad anymore. >> It just has not happened yet. But I think we should start directly after >> the release of Sling 9. I didn't say we should use Launchpad as the >> base, I said we should use the same source which probably is a >> provisioning model. Launchpad's only purpose is to get people easily >> started with Sling, nothing less but also nothing more. >> >>> * There are much more and finer grained features in Karaf than in >>> Launchpad. >> I don't want to be pedantic, but these things are not *in* Karaf. The >> features are defined in Sling and can be consumed by Karaf. > > Sorry, I don't get your point here. > * in Karaf: /trunk/karaf/org.apache.sling.karaf-features/src/main/feature > <feature name="..."> (around 70) > * in Launchpad: /trunk/launchpad/builder/src/main/provisioning > [feature name=...] (around 10) > > Well, (re)usable features *for* Karaf or Launchpad instead of *in*?
I was just trying to emphasize that the source for this is not in the Karaf project, it is in *our* svn. But I think I slightly missunderstood you and as mentioned was too pedantic. :( > >> And I don't >> see any reason why we can't describe these things with a provisioning >> model and a) reference it in Launchpad and b) generate a Karaf feature >> out of it. >> >> The only potentially missing feature are dependencies (as you note >> below). I'll think we should rethink the format of the provisioning >> model anyway and with that we could add dependency handling. The Karaf >> feature XML is unfortunately not suited for our needs as it's not >> possible to add other artifact types and especially not possible to add >> things like repo init. > > Not sure which artifacts you have in mind, but e.g. Pax Web pulls in its > jetty.xml with configfile. That should be possible with repoinit files also. > And I guess we can evolve the Karaf Feature format as we can evolve the > provisioning model when we say what's missing. > I can provide a list of things missing: - inheritance of features in contrast to dependencies - but maybe that is possible in Karaf - framework properties - other artifacts than bundles, e.g. content packages, sub systems etc. - additional free form sections for things like repo init or sub system definitions etc. - usage of the new JSON format for configurations as defined by R7 >From the top of my head, that's all Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
