You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Andreas Schaefer <sc...@me.com.INVALID> on 2019/11/08 17:51:14 UTC
Sling FM Starter Module
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.
Cheers - Andy
Re: Sling FM Starter Module
Posted by Ruben Reusser <rr...@headwire.com>.
Robert,
I think the first focus is on 1, fast followed by 2 and 3
Ruben
On 11/19/2019 6:53 AM, Robert Munteanu 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 <
>>>>> rombert@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
>>>>>
Re: Sling FM Starter Module
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
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 <ro...@apache.org> 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 <
>>>>> rombert@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
>>>>>
>
Re: Sling FM Starter Module
Posted by Robert Munteanu <ro...@apache.org>.
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 <
> > > > rombert@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
> > > >
Re: Sling FM Starter Module
Posted by Ruben Reusser <rr...@headwire.com>.
Robert,
would we not want each module to produce it's own feature file and then
have an aggregation somewhere?
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 <ro...@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
>>>
Re: Sling FM Starter Module
Posted by David Bosschaert <da...@gmail.com>.
Hi Andreas,
I might have missed a detail or two in this long email thread, but I just
wanted to share, that the feature models that are part of your Maven
project (e.g. the ones in src/main/features) do get added to the maven
dependencies of the current project, so instead of generating a feature
model of the current pom.xml, you could take a fm-first approach: create
that feature model and include it in your project - the
slingfeature-maven-plugin will make the bundles that are part of your
project dependencies of your current maven project. That way you don't need
to mention the artifacts (i.e. bundles) referenced in your feature model in
your pom.xml. This might save you from generating one from the other in the
first place.
Best regards,
David
On Tue, 26 Nov 2019 at 00:41, Andreas Schaefer <sc...@me.com.invalid>
wrote:
> Hi
>
> I started to work on a Goal in the Sling Feature Maven Plugin to create
> and install plain slingosgifeature files into the local Maven repo.
>
> This is what I added to a bundle:
>
> <plugin>
> <groupId>org.apache.sling</groupId>
> <artifactId>slingfeature-maven-plugin</artifactId>
> <version>${slingfeature-maven-plugin.version}</version>
> <extensions>true</extensions>
> <executions>
> <execution>
> <id>analyze</id>
> <phase>package</phase>
> <goals>
> <goal>create-fm-descriptor</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> This will create the an FM descriptor and place it into my local Maven
> repo.
>
> In my launcher module I used the Convert PM to FM to convert Sling and
> then add the bundle FM descriptor this way:
>
> <plugin>
> <groupId>org.apache.sling</groupId>
> <artifactId>slingfeature-maven-plugin</artifactId>
> <version>${slingfeature-maven-plugin.version}</version>
> <extensions>true</extensions>
> <configuration>
> <features>target/fm</features>
> <generatedFeatures>${basedir}/target/fm</generatedFeatures>
> </configuration>
> <executions>
> <execution>
> <id>aggregate-base-feature</id>
> <phase>generate-test-sources</phase>
> <goals>
> <goal>aggregate-features</goal>
> </goals>
> <configuration>
> <aggregates>
> <aggregate>
> <classifier>example-runtime</classifier>
> <filesInclude>**/*.json</filesInclude>
>
> <artifactsOverrides>org.apache.sling:org.apache.sling.serviceusermapper:LATEST</artifactsOverrides>
>
> <configurationOverrides>*=USE_LATEST</configurationOverrides>
> <includeArtifact>
> <groupId>${project.groupId}</groupId>
> <artifactId>wfx-api</artifactId>
> <version>${project.version}</version>
> <type>slingosgifeature</type>
> </includeArtifact>
> …
>
> Then I used the Sling Feature Maven Plugin Launcher goal to launch both
> Sling and my demo project and both came up just fine.
>
> Finally I wanted to add Peregrine CMS into my project which can be done
> with just this one:
>
> <includeArtifact>
> <groupId>com.peregrine-cms</groupId>
> <artifactId>com.peregrine-cms.featuremodel.starter</artifactId>
> <version>1.0.0-SNAPSHOT</version>
> <classifier>example-runtime</classifier>
> <type>slingosgifeature</type>
> </includeArtifact>
>
> The same way would Sling be added into my project when the FM descriptor
> is available.
>
> This is what I think a project should look like:
>
> - bundle(s): creates FM descriptor and installs it when built
> - project: creates Project Wide FM Descriptor and install it (Sling,
> Peregrine CMS etc). For Peregrine CMS this would only create a FM
> descriptor for its own modules and for example would not include Sling
> - launcher: takes the projects and modules FM descriptors, aggregates
> final FM descriptor and then launches it
>
> I will go on now and apply this to Sling Modules.
>
> As the FM specification does not lay out a grouping feature like the PMs
> have for Sling 12 we have these options:
>
> - Have the Sling FM Starter maintain a list of all FM from the Sling
> Project. We might want to consider to create a <includeArtifacts/>
> container that then can set group wide properties like group id, type etc
> to all its <includeArtifact/> children
> - Create Group Modules similar to the PMs that just create grouping FM
> descriptors
> - Create Group Modules inside the Sling FM Starter
>
> As soon as I have more experience with the Sling Feature Maven Plugin and
> the create-fm-descriptor goal I will commit and push.
>
> Cheers - Andy Schaefer
>
> > On Nov 19, 2019, at 5:40 PM, Andreas Schaefer <sc...@me.com.INVALID>
> wrote:
> >
> > 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 <ro...@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 <ro...@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
> >
>
>
Re: Sling FM Starter Module
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
Hi
I started to work on a Goal in the Sling Feature Maven Plugin to create and install plain slingosgifeature files into the local Maven repo.
This is what I added to a bundle:
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>slingfeature-maven-plugin</artifactId>
<version>${slingfeature-maven-plugin.version}</version>
<extensions>true</extensions>
<executions>
<execution>
<id>analyze</id>
<phase>package</phase>
<goals>
<goal>create-fm-descriptor</goal>
</goals>
</execution>
</executions>
</plugin>
This will create the an FM descriptor and place it into my local Maven repo.
In my launcher module I used the Convert PM to FM to convert Sling and then add the bundle FM descriptor this way:
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>slingfeature-maven-plugin</artifactId>
<version>${slingfeature-maven-plugin.version}</version>
<extensions>true</extensions>
<configuration>
<features>target/fm</features>
<generatedFeatures>${basedir}/target/fm</generatedFeatures>
</configuration>
<executions>
<execution>
<id>aggregate-base-feature</id>
<phase>generate-test-sources</phase>
<goals>
<goal>aggregate-features</goal>
</goals>
<configuration>
<aggregates>
<aggregate>
<classifier>example-runtime</classifier>
<filesInclude>**/*.json</filesInclude>
<artifactsOverrides>org.apache.sling:org.apache.sling.serviceusermapper:LATEST</artifactsOverrides>
<configurationOverrides>*=USE_LATEST</configurationOverrides>
<includeArtifact>
<groupId>${project.groupId}</groupId>
<artifactId>wfx-api</artifactId>
<version>${project.version}</version>
<type>slingosgifeature</type>
</includeArtifact>
…
Then I used the Sling Feature Maven Plugin Launcher goal to launch both Sling and my demo project and both came up just fine.
Finally I wanted to add Peregrine CMS into my project which can be done with just this one:
<includeArtifact>
<groupId>com.peregrine-cms</groupId>
<artifactId>com.peregrine-cms.featuremodel.starter</artifactId>
<version>1.0.0-SNAPSHOT</version>
<classifier>example-runtime</classifier>
<type>slingosgifeature</type>
</includeArtifact>
The same way would Sling be added into my project when the FM descriptor is available.
This is what I think a project should look like:
- bundle(s): creates FM descriptor and installs it when built
- project: creates Project Wide FM Descriptor and install it (Sling, Peregrine CMS etc). For Peregrine CMS this would only create a FM descriptor for its own modules and for example would not include Sling
- launcher: takes the projects and modules FM descriptors, aggregates final FM descriptor and then launches it
I will go on now and apply this to Sling Modules.
As the FM specification does not lay out a grouping feature like the PMs have for Sling 12 we have these options:
- Have the Sling FM Starter maintain a list of all FM from the Sling Project. We might want to consider to create a <includeArtifacts/> container that then can set group wide properties like group id, type etc to all its <includeArtifact/> children
- Create Group Modules similar to the PMs that just create grouping FM descriptors
- Create Group Modules inside the Sling FM Starter
As soon as I have more experience with the Sling Feature Maven Plugin and the create-fm-descriptor goal I will commit and push.
Cheers - Andy Schaefer
> On Nov 19, 2019, at 5:40 PM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>
> 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 <ro...@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 <ro...@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
>
Re: Sling FM Starter Module
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
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 <ro...@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 <ro...@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
Re: Sling FM Starter Module
Posted by Robert Munteanu <ro...@apache.org>.
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 <ro...@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
> >
Re: Sling FM Starter Module
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
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 ?
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 <ro...@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
>
Re: Sling FM Starter Module
Posted by Robert Munteanu <ro...@apache.org>.
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