You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2022/06/13 14:41:55 UTC
[DISCUSS] Running Starter ITs with module builds
Hi,
I think it would be useful to be able to optionally run the Starter ITs
when building a module that is part of the Sling Starter. This way we
catch various errors sooner and we can get this feedback as part of PR
checks.
I have written down some notes about how this could work at [0]. I have
also worked on a proof of concept that has two parts:
1. The ability to override the version of an artifact when using the
feature-launcher-maven-plugin - [1], [2]
2. A parent pom profile that sets up the Maven executions needed to run
the ITs with the overridden version of the bundle - [3], [4]
With this solution, all that is going to be needed in the end is to run
$ mvn clean verify -Dit.starter.version=13-SNAPSHOT
My plan is to merge the needed changes on Friday so I can work on the
Jenkins part next week and enable it in a couple of sensitive modules.
I don't plan to enable it unconditionally on all modules from the
Starter until:
- we have a good understanding of how well this works
- have a solution that does not require touching every module
definition to enable the tests
Thoughts?
Thanks,
Robert
[0]:
https://cwiki.apache.org/confluence/display/SLING/Running+Sling+Starter+integration+tests+with+module+builds
[1]: https://issues.apache.org/jira/browse/SLING-11387
[2]:
https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
[3]: https://issues.apache.org/jira/browse/SLING-11395
[4]:
https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
Re: [DISCUSS] Running Starter ITs with module builds
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2022-06-29 at 16:59 +0200, Robert Munteanu wrote:
> On Tue, 2022-06-14 at 13:51 +0200, Robert Munteanu wrote:
> >
> > Hi Eric,
> >
> > On Mon, 2022-06-13 at 15:05 -0700, Eric Norman wrote:
> > > Hi Robert,
> > >
> > > For your reference, I stashed a quick demonstration of what I was
> > > talking
> > > about in my last reply at9d9b7d5
> > > <
> > > https://github.com/enapps-enorman/sling-org-apache-sling-jcr-maintenan
> > > ce/commit/9d9b7d5d683dc51236e311a0f4641177f6cd7cc2>
> > > that
> > > will run the starter-its while using the SNAPSHOT versions of
> > > the o.a.sling.jcr.maintenance features in the runtime.
> >
> >
> > Nice, that looks like an improvement over the current PoC.
> >
> > One thing which I would like to do is avoid the need to have an
> > additional feature model file which includes the current artifact
> > being
> > built, since I think that most of the bundles don't need it. We can
> > do
> > that by adding the 'additionalBundles' configuration to the
> > slingfeature-maven-plugin
> >
>
> I have updated my sling-parent PR [1] following your example. I was
> able to include the current artifact in a new feature on the fly
> using
> the slingfeature-maven-plugin include-artifact goal.
>
> I have also enabled feature model analysis on the generated feature
> model ( Sling Starter test model + local artifact ).
>
> I have not yet extended the support for additional local feature
> model
> files, as I would like to keep things simple at the start and
> experiment some more.
>
> I'm going to leave this open for a couple of more days for comments.
I have merged my PR and also updated the contributing docs [2]. There
is definitily room for improvement, as Eric has mentioned in including
local configuration files (without making them mandatory). But I'd like
to try it out first on a couple of modules and see how it goes.
Thanks,
Robert
>
> Thanks,
> Robert
>
> [1]: https://github.com/apache/sling-parent/pull/27
[2]:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/73/files
Re: [DISCUSS] Running Starter ITs with module builds
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2022-06-14 at 13:51 +0200, Robert Munteanu wrote:
>
> Hi Eric,
>
> On Mon, 2022-06-13 at 15:05 -0700, Eric Norman wrote:
> > Hi Robert,
> >
> > For your reference, I stashed a quick demonstration of what I was
> > talking
> > about in my last reply at9d9b7d5
> > <
> > https://github.com/enapps-enorman/sling-org-apache-sling-jcr-maintenan
> > ce/commit/9d9b7d5d683dc51236e311a0f4641177f6cd7cc2>
> > that
> > will run the starter-its while using the SNAPSHOT versions of
> > the o.a.sling.jcr.maintenance features in the runtime.
>
>
> Nice, that looks like an improvement over the current PoC.
>
> One thing which I would like to do is avoid the need to have an
> additional feature model file which includes the current artifact
> being
> built, since I think that most of the bundles don't need it. We can
> do
> that by adding the 'additionalBundles' configuration to the
> slingfeature-maven-plugin
>
I have updated my sling-parent PR [1] following your example. I was
able to include the current artifact in a new feature on the fly using
the slingfeature-maven-plugin include-artifact goal.
I have also enabled feature model analysis on the generated feature
model ( Sling Starter test model + local artifact ).
I have not yet extended the support for additional local feature model
files, as I would like to keep things simple at the start and
experiment some more.
I'm going to leave this open for a couple of more days for comments.
Thanks,
Robert
[1]: https://github.com/apache/sling-parent/pull/27
Re: [DISCUSS] Running Starter ITs with module builds
Posted by Robert Munteanu <ro...@apache.org>.
Hi Eric,
On Mon, 2022-06-13 at 15:05 -0700, Eric Norman wrote:
> Hi Robert,
>
> For your reference, I stashed a quick demonstration of what I was
> talking
> about in my last reply at9d9b7d5
> <
> https://github.com/enapps-enorman/sling-org-apache-sling-jcr-maintenan
> ce/commit/9d9b7d5d683dc51236e311a0f4641177f6cd7cc2>
> that
> will run the starter-its while using the SNAPSHOT versions of
> the o.a.sling.jcr.maintenance features in the runtime.
Nice, that looks like an improvement over the current PoC.
One thing which I would like to do is avoid the need to have an
additional feature model file which includes the current artifact being
built, since I think that most of the bundles don't need it. We can do
that by adding the 'additionalBundles' configuration to the
slingfeature-maven-plugin
By my count we have 98 Sling bundles included in the Starter and it
looks like a lot of work and duplication to include that file in each
of them.
What we can to support the scenario you mention for org-apache-sling-
jcr-maintenance is to include feature model files from well-known
directories, e.g. src/test/features/starter-its/*.json. That should not
conflict with automatically including the latest version of the bundle,
and would support both scenarios.
Thanks,
Robert
>
> Regards,
> Eric
>
> On Mon, Jun 13, 2022 at 12:56 PM Eric Norman <en...@apache.org>
> wrote:
>
> > Hi Robert,
> >
> > Here are my quick thoughts about this.
> >
> > It seems like this approach would lose the benefits of running the
> > analyse-features goal to find any conflicts that the new SNAPSHOT
> > may have
> > introduced. The errors from the feature analyzer are more
> > descriptive (and
> > fail faster) than just getting an error that the server timed out
> > after
> > failing to start due to some bundle failing to resolve.
> >
> > How would you feel about using the slingfeature-maven-plugin to
> > generate a
> > new testing_oak_tar aggregate that includes the starter's oak_tar
> > feature +
> > adds the new SNAPSHOT with an artifactsOverrides configuration to
> > prefer
> > the SNAPSHOT version? I believe that this approach would not
> > require any
> > changes to the sling-feature-launcher-maven-plugin at all. Plus
> > this
> > approach should make it possible to override features and
> > configurations as
> > well if any are defined in the project you are testing (for
> > example,
> > the org-apache-sling-jcr-maintenance project)
> >
> > Regards,
> > -Eric
> >
> > On Mon, Jun 13, 2022 at 7:41 AM Robert Munteanu
> > <ro...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > I think it would be useful to be able to optionally run the
> > > Starter ITs
> > > when building a module that is part of the Sling Starter. This
> > > way we
> > > catch various errors sooner and we can get this feedback as part
> > > of PR
> > > checks.
> > >
> > > I have written down some notes about how this could work at [0].
> > > I have
> > > also worked on a proof of concept that has two parts:
> > >
> > > 1. The ability to override the version of an artifact when using
> > > the
> > > feature-launcher-maven-plugin - [1], [2]
> > > 2. A parent pom profile that sets up the Maven executions needed
> > > to run
> > > the ITs with the overridden version of the bundle - [3], [4]
> > >
> > > With this solution, all that is going to be needed in the end is
> > > to run
> > >
> > > $ mvn clean verify -Dit.starter.version=13-SNAPSHOT
> > >
> > > My plan is to merge the needed changes on Friday so I can work on
> > > the
> > > Jenkins part next week and enable it in a couple of sensitive
> > > modules.
> > >
> > > I don't plan to enable it unconditionally on all modules from the
> > > Starter until:
> > >
> > > - we have a good understanding of how well this works
> > > - have a solution that does not require touching every module
> > > definition to enable the tests
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Robert
> > >
> > >
> > > [0]:
> > >
> > > https://cwiki.apache.org/confluence/display/SLING/Running+Sling+Starter+integration+tests+with+module+builds
> > > [1]: https://issues.apache.org/jira/browse/SLING-11387
> > > [2]:
> > > https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
> > > [3]: https://issues.apache.org/jira/browse/SLING-11395
> > > [4]:
> > > https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
> > >
> >
Re: [DISCUSS] Running Starter ITs with module builds
Posted by Eric Norman <en...@apache.org>.
Hi Robert,
For your reference, I stashed a quick demonstration of what I was talking
about in my last reply at9d9b7d5
<https://github.com/enapps-enorman/sling-org-apache-sling-jcr-maintenance/commit/9d9b7d5d683dc51236e311a0f4641177f6cd7cc2>
that
will run the starter-its while using the SNAPSHOT versions of
the o.a.sling.jcr.maintenance features in the runtime.
Regards,
Eric
On Mon, Jun 13, 2022 at 12:56 PM Eric Norman <en...@apache.org> wrote:
> Hi Robert,
>
> Here are my quick thoughts about this.
>
> It seems like this approach would lose the benefits of running the
> analyse-features goal to find any conflicts that the new SNAPSHOT may have
> introduced. The errors from the feature analyzer are more descriptive (and
> fail faster) than just getting an error that the server timed out after
> failing to start due to some bundle failing to resolve.
>
> How would you feel about using the slingfeature-maven-plugin to generate a
> new testing_oak_tar aggregate that includes the starter's oak_tar feature +
> adds the new SNAPSHOT with an artifactsOverrides configuration to prefer
> the SNAPSHOT version? I believe that this approach would not require any
> changes to the sling-feature-launcher-maven-plugin at all. Plus this
> approach should make it possible to override features and configurations as
> well if any are defined in the project you are testing (for example,
> the org-apache-sling-jcr-maintenance project)
>
> Regards,
> -Eric
>
> On Mon, Jun 13, 2022 at 7:41 AM Robert Munteanu <ro...@apache.org>
> wrote:
>
>> Hi,
>>
>> I think it would be useful to be able to optionally run the Starter ITs
>> when building a module that is part of the Sling Starter. This way we
>> catch various errors sooner and we can get this feedback as part of PR
>> checks.
>>
>> I have written down some notes about how this could work at [0]. I have
>> also worked on a proof of concept that has two parts:
>>
>> 1. The ability to override the version of an artifact when using the
>> feature-launcher-maven-plugin - [1], [2]
>> 2. A parent pom profile that sets up the Maven executions needed to run
>> the ITs with the overridden version of the bundle - [3], [4]
>>
>> With this solution, all that is going to be needed in the end is to run
>>
>> $ mvn clean verify -Dit.starter.version=13-SNAPSHOT
>>
>> My plan is to merge the needed changes on Friday so I can work on the
>> Jenkins part next week and enable it in a couple of sensitive modules.
>>
>> I don't plan to enable it unconditionally on all modules from the
>> Starter until:
>>
>> - we have a good understanding of how well this works
>> - have a solution that does not require touching every module
>> definition to enable the tests
>>
>> Thoughts?
>>
>> Thanks,
>> Robert
>>
>>
>> [0]:
>>
>> https://cwiki.apache.org/confluence/display/SLING/Running+Sling+Starter+integration+tests+with+module+builds
>> [1]: https://issues.apache.org/jira/browse/SLING-11387
>> [2]:
>> https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
>> [3]: https://issues.apache.org/jira/browse/SLING-11395
>> [4]:
>> https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
>>
>
Re: [DISCUSS] Running Starter ITs with module builds
Posted by Eric Norman <en...@apache.org>.
Hi Robert,
Here are my quick thoughts about this.
It seems like this approach would lose the benefits of running the
analyse-features goal to find any conflicts that the new SNAPSHOT may have
introduced. The errors from the feature analyzer are more descriptive (and
fail faster) than just getting an error that the server timed out after
failing to start due to some bundle failing to resolve.
How would you feel about using the slingfeature-maven-plugin to generate a
new testing_oak_tar aggregate that includes the starter's oak_tar feature +
adds the new SNAPSHOT with an artifactsOverrides configuration to prefer
the SNAPSHOT version? I believe that this approach would not require any
changes to the sling-feature-launcher-maven-plugin at all. Plus this
approach should make it possible to override features and configurations as
well if any are defined in the project you are testing (for example,
the org-apache-sling-jcr-maintenance project)
Regards,
-Eric
On Mon, Jun 13, 2022 at 7:41 AM Robert Munteanu <ro...@apache.org> wrote:
> Hi,
>
> I think it would be useful to be able to optionally run the Starter ITs
> when building a module that is part of the Sling Starter. This way we
> catch various errors sooner and we can get this feedback as part of PR
> checks.
>
> I have written down some notes about how this could work at [0]. I have
> also worked on a proof of concept that has two parts:
>
> 1. The ability to override the version of an artifact when using the
> feature-launcher-maven-plugin - [1], [2]
> 2. A parent pom profile that sets up the Maven executions needed to run
> the ITs with the overridden version of the bundle - [3], [4]
>
> With this solution, all that is going to be needed in the end is to run
>
> $ mvn clean verify -Dit.starter.version=13-SNAPSHOT
>
> My plan is to merge the needed changes on Friday so I can work on the
> Jenkins part next week and enable it in a couple of sensitive modules.
>
> I don't plan to enable it unconditionally on all modules from the
> Starter until:
>
> - we have a good understanding of how well this works
> - have a solution that does not require touching every module
> definition to enable the tests
>
> Thoughts?
>
> Thanks,
> Robert
>
>
> [0]:
>
> https://cwiki.apache.org/confluence/display/SLING/Running+Sling+Starter+integration+tests+with+module+builds
> [1]: https://issues.apache.org/jira/browse/SLING-11387
> [2]:
> https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
> [3]: https://issues.apache.org/jira/browse/SLING-11395
> [4]:
> https://github.com/apache/sling-feature-launcher-maven-plugin/pull/8
>