On Tue, 2019-11-19 at 06:47 -0800, Ruben Reusser wrote: > Robert, > > would we not want each module to produce it's own feature file and > then > have an aggregation somewhere?
Depends on what you define as a module. I see multiple options here: 1. A bundle produces its own feature file. For instance, slingshot - single bundle, single feature file. 2. A set of bundles define their own feature file in a shared project This would be for example composum, defining all bundles + configs they need to start up in the Composum project. Then we import it in the application we are running. 3. A set of bundles are included in a feature file of the application project. This would be the Sling starter defining its own feature files and including e.g. composum Sling scripting bundles + configs in its own repository. Which is the one under discussion? Robert > > Ruben > > On 11/19/2019 6:41 AM, Robert Munteanu wrote: > > On Fri, 2019-11-15 at 11:47 -0800, Andreas Schaefer wrote: > > > Hi > > > > > > I started to get the pieces into place for a build up of > > > Peregrine > > > CMS based on Sling 11 using FMs. > > > > > > First I updated the Sling Feature Converter Maven Plugin to > > > install > > > the generated slingosgifeature into my local Maven repo and then > > > use > > > these dependencies to assemble and launch Peregrine. This works > > > fine > > > for most parts (content does not deploy but that is another > > > story). > > > > > > Next step is to install FMs from Bundles into the local Maven > > > repo > > > which will be used for bundles or content bundles like Sling. > > > > > > My question is: is it expected for the developer to write its own > > > slingosgiffeature file or is there a way to generate that from a > > > POM > > > ? > > Do you want to generate feature files for individual bundles? I > > would > > expect that you have a feature file that groups related bundles > > together, similar to what we do with the provisioning model. > > > > Robert > > > > > As far as I can see the Sling Feature Maven Plugin does not > > > provide > > > that. > > > > > > Cheers - Andy > > > > > > > On Nov 11, 2019, at 2:11 AM, Robert Munteanu < > > > > [email protected]> > > > > wrote: > > > > > > > > Hi Andreas, > > > > > > > > On Fri, 2019-11-08 at 09:51 -0800, Andreas Schaefer wrote: > > > > > Hi > > > > > > > > > > I am wondering how a Sling FM Starter Module would look like > > > > > and > > > > > how > > > > > it is used by clients like Peregrine. > > > > > > > > > > It is my assumption that any FM slingosgifeature project will > > > > > install > > > > > that file on release on a public Maven repository like all of > > > > > our > > > > > Sling Module. > > > > > > > > > > Then the Sling FM Starter Module will select the appropriate > > > > > slingosgifeature files and assemble it into a Sling release > > > > > slingosgifeature which is then also installed on a public > > > > > Maven > > > > > repo. > > > > > This enables anyone to build the latest Sling instance w/o > > > > > having > > > > > any > > > > > other Sling Module checked out / built like right now it is > > > > > done > > > > > in > > > > > PM based Sling Starter. > > > > > > > > > > A customer will then do the same by taking the Sling > > > > > slingosgifeature > > > > > file and assembly it with their own project and external > > > > > projects > > > > > slingosgifeature files to build the final Sling / Customer > > > > > instance. > > > > Overall that sounds reasonable to me. The only note that I want > > > > to > > > > make > > > > is that since we are doing releases at best once per year, > > > > downstream > > > > projects would either need to depend on SNAPSHOT versions of > > > > the > > > > Sling > > > > Starter, or depend on older versions. > > > > > > > > Thanks, > > > > Robert > > > >
