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 <[email protected]> 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 <[email protected]> > 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 >> >
