Hi Robert

Both, we need FM descriptors for single bundles and for groups (ala PMs).
The reason for single bundles is to provide the ability to assemble an 
application by cherry picking bundles so that I do not have to wait for a group 
to be released.

- Andy

> On Nov 19, 2019, at 6:41 AM, Robert Munteanu <romb...@apache.org> 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 <romb...@apache.org>
>>> 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

Reply via email to