On Fri, 2017-10-06 at 15:06 +0100, Ian Boston wrote: > Hi, > > On 6 October 2017 at 15:02, Robert Munteanu <[email protected]> > wrote: > > > Hi Ian, > > > > Thanks for starting the discussion. I think this can be one of the > > big > > benefits of modularising Oak and I am interested in seeing this > > being > > done. > > > > As you mentioned, it becomes easier to integrate various Oak > > changes, > > especially for consumers only depending on stable APIs. > > > > On Thu, 2017-10-05 at 13:33 +0100, Ian Boston wrote: > > > Obviously bundles remain the release unit, and the build must > > > include > > > OSGi > > > based integration tests that validate a release is viable. > > > > This brings about a question - what is an Oak release? If doing > > per- > > module releases, will we also do a "product" releases? > > > > A product release in my view is - similar to the Sling Launchpad - > > a > > way of saying 'these module versions are guaranteed to work > > together > > beyond compilation and semantic versioning constraints'. > > > > Also of interest is how/if we want to address the issue of > > supporting > > various module versions combinations. So if we have ( for instance > > ) > > > > - oak-api 1.7.9 > > - oak-core 1.7.12 > > - oak-segment-tar 1.8.0 > > > > will these work together? Furthermore, which versions of oak- > > upgrade > > and oak-run are compatible with this combination? > > > > > Perhaps, there needs to be a Oak Quickstart jar to define a > combination of > jars that work. > Perhaps that is oak-run ?
Yes, that is one option. The question is how do we actually expect consumers to define their usage of Oak. One clear case is OSGi via Sling - and that can be defined via a Sling feature. Another is the one you mentioned - a runnable jar and that is oak-run. Yeat another one can be embedding Oak in their project via Maven/Gradle/etc dependencies . This is currently done in the oak- examples module. Here we can consider defining an 'uber-pom' that is used to pull in dependencies of a given Oak release. Robert
