I am still struggling to find a balanced solution for this. What I want to do is to have a way for modules, projects and assemblers to deal with FMs through Maven like the PM does with dependencies. The issue is that all FMs need to be available for an assembler to build its Sling project and having to build all modules locally is not really feasible and for close-sourced products this might not work at all. Therefore products must expose their FM and the best way in my opinion is to do it through Maven.
For a simple bundle module creating a FM is simple and does not really warrant using a Plugin to create a FM. That said for content package, complex bundles and 3rd party projects like Composum, Peregrine FM descriptors on Maven are the way for assemblers to build their custom project. This is the reason why I want to have a plugin that can create an FM based on the project’s POM. Also more complex projects that have dependencies would have multiple Maven dependencies in their FM. This is how I see how FMs can be used to assemble a custom Sling instance. For this example I will use Sling and an imaginary Peregrine which is built up by bundles instead of its [current] content packages. 1. Each Sling and Peregrine module will create an FM descriptor (slingosgifeature) and install it in the local Maven repo 2. Each Sling and Peregrine module will deploy its FM descriptor to a remote Maven repo on release 3. Group of Modules can create, install and deploy a group FM descriptor similar to what we have today as PMs. As of now the assemble goal in Slingfeature Maven Plugin can create a JSon file but that one needs to be installed / deployed. 4. Sling FM Start Module will either use Group of Modules or cherry pick particular FMs with includeArtifacts to assemble a Sling Release (like Sling 12), then install and deploy it on release 5. Assemblers will pick the desired FMs (groups or single FMs with includeArtifacts) 6. Assemblers launch the application For modules with no not-provided dependencies the generation of the FM descriptor is plain simple but having it at least as local FM descriptor will streamline the building of groups and finally product releases as creating and consumption is the same for all levels. Group FMs take the place of PMs and deployed (released) FMs are used by assemblers to build projects based on 3rd party products like Sling, Peregrine, Composum etc. Next steps for me is to add a new Goal to the Slingfeature Maven plugin to create a FM descriptor on a bundle and then install it locally (for now). With that the local Maven repository should have a .slingosgifeature file next to the POM and its JAR artifact. Afterwards we need to be able to install / deploy assembled FMs as well. Cheers - Andy > On Nov 19, 2019, at 6:53 AM, Robert Munteanu <[email protected]> wrote: > > 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 >>>>> >
