Re: [Feature Analyser] Usage scenario gap
I would make it an external extension because that way you can have the analyser on the classpath without affecting the launcher. regards, Karl On Thu, May 16, 2019 at 11:25 AM Dominik Süß wrote: > > Sounds good to me - would you suggest to make this a default behavior of > the analyser or making this an explicit external extension? > Depending on this I'd either add that to the whiteboard or a PR to the > existing analyser artifact. > > Cheers > Dominik > > On Thu, May 16, 2019 at 10:55 AM Karl Pauls wrote: > > > You don't need a standalone CLI nor add the analyser capabilites to > > the feature launcher. You should be able to create a launcher > > extension that you can hook into the launcher to act as an analyser. I > > added that possibility in SLING-8386. > > > > In sort, you use the feature launcher and provide a > > org.apache.sling.feature.launcher.spi.Launcher via the ServiceLoader. > > That should in turn be able to run the analyser with the assembled > > feature. > > > > regards, > > > > Karl > > > > On Thu, May 16, 2019 at 10:44 AM Dominik Süß > > wrote: > > > > > > Hi Carsten, hi David, > > > > > > basically, there are 2 scenarios (where I currently primarily focus on > > > scenario 1) > > > 1) we have a set of base features developed by one party and have > > another > > > party developing a "customer" feature that is running on top of base > > > feature. Both features have their own lifecycle and may change > > > independently - the customer feature may be rebuilt (and effectively is) > > > each time that the base feature is updated. At this point of time, I need > > > to validate that changes of the base feature work together with the > > > customer feature(s). As I am rebuilding the customer feature I would have > > > the "option" to run it in the maven build process but effectively we want > > > to validate two versions of ready built features before we start up the > > > instance. Running via maven would by the setup we have where the customer > > > feature is rebuilt via maven anyhow just a potential fallback if easier > > to > > > solve) > > > 2) a consuming feature should probably be validated against updating > > > baseline features when being developed - this scenario is solved > > > differently for our product and there is no direct access to the invidual > > > features at build time - so it is rather a theoretical scenarios where at > > > least we currently don't have an active usecase that wouldn't be covered > > by > > > scenario 1 > > > > > > I hope this makes it a bit clearer. > > > Can you clarify why you prefer to have a standalone CLI tool over adding > > > analyser capabilities to the feature launcher. Key for my question is the > > > necessary duplication of binaries? Or maybe the launcher could be used as > > > the sidecar for the analyser jar to make sure all the libaries are on the > > > class path - WDYT? > > > > > > Cheers > > > Dominik > > > > > > On Thu, May 16, 2019 at 8:57 AM David Bosschaert < > > david.bosscha...@gmail.com> > > > wrote: > > > > > > > I can also see the benefit of running the Analyser outside of a Maven > > > > context, which can be especially useful if you are in an environment > > where > > > > you don't have a Maven cache around. E.g. in a Docker environment. > > Running > > > > Maven in such a context can be very time and network consuming as the > > Maven > > > > cache needs to be built up from scratch, which is really not great if > > all > > > > you want to do is run the Analyser. > > > > > > > > I also think that making it part of the launcher unnecessarily couples > > > > these two. I can see many use cases where they should be run at > > separate > > > > times. If someone wants to run them together it would be as simple as > > > > calling them in sequence or putting them together in a shell script. > > So I > > > > would think option b is the cleanest here too. > > > > > > > > Cheers, > > > > > > > > David > > > > > > > > On Thu, 16 May 2019 at 07:39, Carsten Ziegeler > > > > wrote: > > > > > > > > > My tendency is towards option b) - keeping things separate and > > allowing > > > > > to develop/release them separately. > > > > > > > > > > From your options I'm not sure what exactly your use case is as > > they go > > > > > in all possible directions :) But in many use cases you want to > > validate > > > > > as early as possible - and the launcher is the last resort. I can > > > > > totally see use cases where you want to validate features > > independent of > > > > > a maven project and independent from launching, that's why I think we > > > > > should have that as a separate cli. > > > > > > > > > > That was the initial idea of the Main class; we just removed it > > because > > > > > no one needed it at that time and it was the quickest fix. We should > > > > > also make sure that the Main class is really just parsing the command > > > > > line options and has no other logic. Everything else can be > > delegated to > > >
Re: [Feature Analyser] Usage scenario gap
Sounds good to me - would you suggest to make this a default behavior of the analyser or making this an explicit external extension? Depending on this I'd either add that to the whiteboard or a PR to the existing analyser artifact. Cheers Dominik On Thu, May 16, 2019 at 10:55 AM Karl Pauls wrote: > You don't need a standalone CLI nor add the analyser capabilites to > the feature launcher. You should be able to create a launcher > extension that you can hook into the launcher to act as an analyser. I > added that possibility in SLING-8386. > > In sort, you use the feature launcher and provide a > org.apache.sling.feature.launcher.spi.Launcher via the ServiceLoader. > That should in turn be able to run the analyser with the assembled > feature. > > regards, > > Karl > > On Thu, May 16, 2019 at 10:44 AM Dominik Süß > wrote: > > > > Hi Carsten, hi David, > > > > basically, there are 2 scenarios (where I currently primarily focus on > > scenario 1) > > 1) we have a set of base features developed by one party and have > another > > party developing a "customer" feature that is running on top of base > > feature. Both features have their own lifecycle and may change > > independently - the customer feature may be rebuilt (and effectively is) > > each time that the base feature is updated. At this point of time, I need > > to validate that changes of the base feature work together with the > > customer feature(s). As I am rebuilding the customer feature I would have > > the "option" to run it in the maven build process but effectively we want > > to validate two versions of ready built features before we start up the > > instance. Running via maven would by the setup we have where the customer > > feature is rebuilt via maven anyhow just a potential fallback if easier > to > > solve) > > 2) a consuming feature should probably be validated against updating > > baseline features when being developed - this scenario is solved > > differently for our product and there is no direct access to the invidual > > features at build time - so it is rather a theoretical scenarios where at > > least we currently don't have an active usecase that wouldn't be covered > by > > scenario 1 > > > > I hope this makes it a bit clearer. > > Can you clarify why you prefer to have a standalone CLI tool over adding > > analyser capabilities to the feature launcher. Key for my question is the > > necessary duplication of binaries? Or maybe the launcher could be used as > > the sidecar for the analyser jar to make sure all the libaries are on the > > class path - WDYT? > > > > Cheers > > Dominik > > > > On Thu, May 16, 2019 at 8:57 AM David Bosschaert < > david.bosscha...@gmail.com> > > wrote: > > > > > I can also see the benefit of running the Analyser outside of a Maven > > > context, which can be especially useful if you are in an environment > where > > > you don't have a Maven cache around. E.g. in a Docker environment. > Running > > > Maven in such a context can be very time and network consuming as the > Maven > > > cache needs to be built up from scratch, which is really not great if > all > > > you want to do is run the Analyser. > > > > > > I also think that making it part of the launcher unnecessarily couples > > > these two. I can see many use cases where they should be run at > separate > > > times. If someone wants to run them together it would be as simple as > > > calling them in sequence or putting them together in a shell script. > So I > > > would think option b is the cleanest here too. > > > > > > Cheers, > > > > > > David > > > > > > On Thu, 16 May 2019 at 07:39, Carsten Ziegeler > > > wrote: > > > > > > > My tendency is towards option b) - keeping things separate and > allowing > > > > to develop/release them separately. > > > > > > > > From your options I'm not sure what exactly your use case is as > they go > > > > in all possible directions :) But in many use cases you want to > validate > > > > as early as possible - and the launcher is the last resort. I can > > > > totally see use cases where you want to validate features > independent of > > > > a maven project and independent from launching, that's why I think we > > > > should have that as a separate cli. > > > > > > > > That was the initial idea of the Main class; we just removed it > because > > > > no one needed it at that time and it was the quickest fix. We should > > > > also make sure that the Main class is really just parsing the command > > > > line options and has no other logic. Everything else can be > delegated to > > > > another class. This makes it easier to embed this logic somewhere > else. > > > > > > > > > > > > Regards > > > > > > > > Carsten > > > > > > > > > > > > Dominik Süß wrote > > > > > Hi all, > > > > > > > > > > https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 > led to > > > > > removal of the Main class of the feature analyser making it no > longer > > > > > usable standalone (taking away option b for the
Re: [Feature Analyser] Usage scenario gap
You don't need a standalone CLI nor add the analyser capabilites to the feature launcher. You should be able to create a launcher extension that you can hook into the launcher to act as an analyser. I added that possibility in SLING-8386. In sort, you use the feature launcher and provide a org.apache.sling.feature.launcher.spi.Launcher via the ServiceLoader. That should in turn be able to run the analyser with the assembled feature. regards, Karl On Thu, May 16, 2019 at 10:44 AM Dominik Süß wrote: > > Hi Carsten, hi David, > > basically, there are 2 scenarios (where I currently primarily focus on > scenario 1) > 1) we have a set of base features developed by one party and have another > party developing a "customer" feature that is running on top of base > feature. Both features have their own lifecycle and may change > independently - the customer feature may be rebuilt (and effectively is) > each time that the base feature is updated. At this point of time, I need > to validate that changes of the base feature work together with the > customer feature(s). As I am rebuilding the customer feature I would have > the "option" to run it in the maven build process but effectively we want > to validate two versions of ready built features before we start up the > instance. Running via maven would by the setup we have where the customer > feature is rebuilt via maven anyhow just a potential fallback if easier to > solve) > 2) a consuming feature should probably be validated against updating > baseline features when being developed - this scenario is solved > differently for our product and there is no direct access to the invidual > features at build time - so it is rather a theoretical scenarios where at > least we currently don't have an active usecase that wouldn't be covered by > scenario 1 > > I hope this makes it a bit clearer. > Can you clarify why you prefer to have a standalone CLI tool over adding > analyser capabilities to the feature launcher. Key for my question is the > necessary duplication of binaries? Or maybe the launcher could be used as > the sidecar for the analyser jar to make sure all the libaries are on the > class path - WDYT? > > Cheers > Dominik > > On Thu, May 16, 2019 at 8:57 AM David Bosschaert > wrote: > > > I can also see the benefit of running the Analyser outside of a Maven > > context, which can be especially useful if you are in an environment where > > you don't have a Maven cache around. E.g. in a Docker environment. Running > > Maven in such a context can be very time and network consuming as the Maven > > cache needs to be built up from scratch, which is really not great if all > > you want to do is run the Analyser. > > > > I also think that making it part of the launcher unnecessarily couples > > these two. I can see many use cases where they should be run at separate > > times. If someone wants to run them together it would be as simple as > > calling them in sequence or putting them together in a shell script. So I > > would think option b is the cleanest here too. > > > > Cheers, > > > > David > > > > On Thu, 16 May 2019 at 07:39, Carsten Ziegeler > > wrote: > > > > > My tendency is towards option b) - keeping things separate and allowing > > > to develop/release them separately. > > > > > > From your options I'm not sure what exactly your use case is as they go > > > in all possible directions :) But in many use cases you want to validate > > > as early as possible - and the launcher is the last resort. I can > > > totally see use cases where you want to validate features independent of > > > a maven project and independent from launching, that's why I think we > > > should have that as a separate cli. > > > > > > That was the initial idea of the Main class; we just removed it because > > > no one needed it at that time and it was the quickest fix. We should > > > also make sure that the Main class is really just parsing the command > > > line options and has no other logic. Everything else can be delegated to > > > another class. This makes it easier to embed this logic somewhere else. > > > > > > > > > Regards > > > > > > Carsten > > > > > > > > > Dominik Süß wrote > > > > Hi all, > > > > > > > > https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led to > > > > removal of the Main class of the feature analyser making it no longer > > > > usable standalone (taking away option b for the scenarios described > > > below) > > > > > > > > > https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154 > > > > > > > > Afaict the analyser currently can only run in maven context which > > creates > > > > some trouble where a validation is supposed to run in isolation based > > on > > > > built and released features (checking if given features work > > together). I > > > > initially tried to work around with the maven plugin but the analyser > > > only > > > >
Re: [Feature Analyser] Usage scenario gap
I just noticed that I missed to add details why using the maven build failed for me - at this build time I only have the cachefolder available as "local repository" - the way that the repository goal produces this cache folder doesn't generate/download the pom.xml files for the artifacts. I first was trying to use install:install-file to make the external feature addressable which did work, but the analyzer subsequently fails as when running in the maven context the analyzer only supports reading artifacts via maven. So this opens another option to solve the problem, which is adding support for a local cache folder "bypassing" the maven lookup (e.g. configuring a local cache folder would bypass maven lookup). Cheers Dominik On Thu, May 16, 2019 at 10:34 AM Dominik Süß wrote: > Hi Carsten, hi David, > > basically, there are 2 scenarios (where I currently primarily focus on > scenario 1) > 1) we have a set of base features developed by one party and have another > party developing a "customer" feature that is running on top of base > feature. Both features have their own lifecycle and may change > independently - the customer feature may be rebuilt (and effectively is) > each time that the base feature is updated. At this point of time, I need > to validate that changes of the base feature work together with the > customer feature(s). As I am rebuilding the customer feature I would have > the "option" to run it in the maven build process but effectively we want > to validate two versions of ready built features before we start up the > instance. Running via maven would by the setup we have where the customer > feature is rebuilt via maven anyhow just a potential fallback if easier to > solve) > 2) a consuming feature should probably be validated against updating > baseline features when being developed - this scenario is solved > differently for our product and there is no direct access to the invidual > features at build time - so it is rather a theoretical scenarios where at > least we currently don't have an active usecase that wouldn't be covered by > scenario 1 > > I hope this makes it a bit clearer. > Can you clarify why you prefer to have a standalone CLI tool over adding > analyser capabilities to the feature launcher. Key for my question is the > necessary duplication of binaries? Or maybe the launcher could be used as > the sidecar for the analyser jar to make sure all the libaries are on the > class path - WDYT? > > Cheers > Dominik > > On Thu, May 16, 2019 at 8:57 AM David Bosschaert < > david.bosscha...@gmail.com> wrote: > >> I can also see the benefit of running the Analyser outside of a Maven >> context, which can be especially useful if you are in an environment where >> you don't have a Maven cache around. E.g. in a Docker environment. Running >> Maven in such a context can be very time and network consuming as the >> Maven >> cache needs to be built up from scratch, which is really not great if all >> you want to do is run the Analyser. >> >> I also think that making it part of the launcher unnecessarily couples >> these two. I can see many use cases where they should be run at separate >> times. If someone wants to run them together it would be as simple as >> calling them in sequence or putting them together in a shell script. So I >> would think option b is the cleanest here too. >> >> Cheers, >> >> David >> >> On Thu, 16 May 2019 at 07:39, Carsten Ziegeler >> wrote: >> >> > My tendency is towards option b) - keeping things separate and allowing >> > to develop/release them separately. >> > >> > From your options I'm not sure what exactly your use case is as they go >> > in all possible directions :) But in many use cases you want to validate >> > as early as possible - and the launcher is the last resort. I can >> > totally see use cases where you want to validate features independent of >> > a maven project and independent from launching, that's why I think we >> > should have that as a separate cli. >> > >> > That was the initial idea of the Main class; we just removed it because >> > no one needed it at that time and it was the quickest fix. We should >> > also make sure that the Main class is really just parsing the command >> > line options and has no other logic. Everything else can be delegated to >> > another class. This makes it easier to embed this logic somewhere else. >> > >> > >> > Regards >> > >> > Carsten >> > >> > >> > Dominik Süß wrote >> > > Hi all, >> > > >> > > https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led >> to >> > > removal of the Main class of the feature analyser making it no longer >> > > usable standalone (taking away option b for the scenarios described >> > below) >> > > >> > >> https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154 >> > > >> > > Afaict the analyser currently can only run in maven context which >> creates >> > >
Re: [Feature Analyser] Usage scenario gap
Hi Carsten, hi David, basically, there are 2 scenarios (where I currently primarily focus on scenario 1) 1) we have a set of base features developed by one party and have another party developing a "customer" feature that is running on top of base feature. Both features have their own lifecycle and may change independently - the customer feature may be rebuilt (and effectively is) each time that the base feature is updated. At this point of time, I need to validate that changes of the base feature work together with the customer feature(s). As I am rebuilding the customer feature I would have the "option" to run it in the maven build process but effectively we want to validate two versions of ready built features before we start up the instance. Running via maven would by the setup we have where the customer feature is rebuilt via maven anyhow just a potential fallback if easier to solve) 2) a consuming feature should probably be validated against updating baseline features when being developed - this scenario is solved differently for our product and there is no direct access to the invidual features at build time - so it is rather a theoretical scenarios where at least we currently don't have an active usecase that wouldn't be covered by scenario 1 I hope this makes it a bit clearer. Can you clarify why you prefer to have a standalone CLI tool over adding analyser capabilities to the feature launcher. Key for my question is the necessary duplication of binaries? Or maybe the launcher could be used as the sidecar for the analyser jar to make sure all the libaries are on the class path - WDYT? Cheers Dominik On Thu, May 16, 2019 at 8:57 AM David Bosschaert wrote: > I can also see the benefit of running the Analyser outside of a Maven > context, which can be especially useful if you are in an environment where > you don't have a Maven cache around. E.g. in a Docker environment. Running > Maven in such a context can be very time and network consuming as the Maven > cache needs to be built up from scratch, which is really not great if all > you want to do is run the Analyser. > > I also think that making it part of the launcher unnecessarily couples > these two. I can see many use cases where they should be run at separate > times. If someone wants to run them together it would be as simple as > calling them in sequence or putting them together in a shell script. So I > would think option b is the cleanest here too. > > Cheers, > > David > > On Thu, 16 May 2019 at 07:39, Carsten Ziegeler > wrote: > > > My tendency is towards option b) - keeping things separate and allowing > > to develop/release them separately. > > > > From your options I'm not sure what exactly your use case is as they go > > in all possible directions :) But in many use cases you want to validate > > as early as possible - and the launcher is the last resort. I can > > totally see use cases where you want to validate features independent of > > a maven project and independent from launching, that's why I think we > > should have that as a separate cli. > > > > That was the initial idea of the Main class; we just removed it because > > no one needed it at that time and it was the quickest fix. We should > > also make sure that the Main class is really just parsing the command > > line options and has no other logic. Everything else can be delegated to > > another class. This makes it easier to embed this logic somewhere else. > > > > > > Regards > > > > Carsten > > > > > > Dominik Süß wrote > > > Hi all, > > > > > > https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led to > > > removal of the Main class of the feature analyser making it no longer > > > usable standalone (taking away option b for the scenarios described > > below) > > > > > > https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154 > > > > > > Afaict the analyser currently can only run in maven context which > creates > > > some trouble where a validation is supposed to run in isolation based > on > > > built and released features (checking if given features work > together). I > > > initially tried to work around with the maven plugin but the analyser > > only > > > can run on the features it builds and won't allow me to refer external > > > artifacts - copying in the other artifacts in the project also doesn't > > work > > > as the check of the maven plugin fails for groupid & artifact id. > > > > > > Here are the options I currently see: > > > a) the analyse mojo of slingfeature-maven-plugin is improved to be able > > to > > > analyse against adhoc merged features and also supports injecting > > external > > > artifacts (optimally both maven coordinates or file location) - this > > would > > > allow to validate the combination of features intended to be used in > the > > > launcher > > > > > > b) add a standalone analyser as it was present before - here
Re: [Feature Analyser] Usage scenario gap
I can also see the benefit of running the Analyser outside of a Maven context, which can be especially useful if you are in an environment where you don't have a Maven cache around. E.g. in a Docker environment. Running Maven in such a context can be very time and network consuming as the Maven cache needs to be built up from scratch, which is really not great if all you want to do is run the Analyser. I also think that making it part of the launcher unnecessarily couples these two. I can see many use cases where they should be run at separate times. If someone wants to run them together it would be as simple as calling them in sequence or putting them together in a shell script. So I would think option b is the cleanest here too. Cheers, David On Thu, 16 May 2019 at 07:39, Carsten Ziegeler wrote: > My tendency is towards option b) - keeping things separate and allowing > to develop/release them separately. > > From your options I'm not sure what exactly your use case is as they go > in all possible directions :) But in many use cases you want to validate > as early as possible - and the launcher is the last resort. I can > totally see use cases where you want to validate features independent of > a maven project and independent from launching, that's why I think we > should have that as a separate cli. > > That was the initial idea of the Main class; we just removed it because > no one needed it at that time and it was the quickest fix. We should > also make sure that the Main class is really just parsing the command > line options and has no other logic. Everything else can be delegated to > another class. This makes it easier to embed this logic somewhere else. > > > Regards > > Carsten > > > Dominik Süß wrote > > Hi all, > > > > https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led to > > removal of the Main class of the feature analyser making it no longer > > usable standalone (taking away option b for the scenarios described > below) > > > https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154 > > > > Afaict the analyser currently can only run in maven context which creates > > some trouble where a validation is supposed to run in isolation based on > > built and released features (checking if given features work together). I > > initially tried to work around with the maven plugin but the analyser > only > > can run on the features it builds and won't allow me to refer external > > artifacts - copying in the other artifacts in the project also doesn't > work > > as the check of the maven plugin fails for groupid & artifact id. > > > > Here are the options I currently see: > > a) the analyse mojo of slingfeature-maven-plugin is improved to be able > to > > analyse against adhoc merged features and also supports injecting > external > > artifacts (optimally both maven coordinates or file location) - this > would > > allow to validate the combination of features intended to be used in the > > launcher > > > > b) add a standalone analyser as it was present before - here I could > think > > of not embedding the features but rather produce a sidecar jar with all > the > > dependencies that could be set on the classpath for execution, > eliminating > > the trouble addressed via SLING-8102 in a sligthly different way while > > still keeping the option to validate in a pre launcher phase via CLI tool > > > > c) adding validation capabilities to the launcher to be able to run the > > analyser tasks via cli through the launcher > > > > My personal tendency is that a & c might both be quite reasonable to have > > around (a giving quick roundtrip times during development cycles/build > > phase - while c rather matches operational validation where the build of > > the features happens decoupled from the final aggregation/combination). b > > rather feels like a workaround of c if we don't want to have the analyser > > being part of the launcher to keep it as slim as possible. > > > > Btw. I don't suggest to make analysis a mandatory step in the launcher > but > > at least an option. > > > > WDYT? > > > > Cheers > > Dominik > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: [Feature Analyser] Usage scenario gap
My tendency is towards option b) - keeping things separate and allowing to develop/release them separately. From your options I'm not sure what exactly your use case is as they go in all possible directions :) But in many use cases you want to validate as early as possible - and the launcher is the last resort. I can totally see use cases where you want to validate features independent of a maven project and independent from launching, that's why I think we should have that as a separate cli. That was the initial idea of the Main class; we just removed it because no one needed it at that time and it was the quickest fix. We should also make sure that the Main class is really just parsing the command line options and has no other logic. Everything else can be delegated to another class. This makes it easier to embed this logic somewhere else. Regards Carsten Dominik Süß wrote Hi all, https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led to removal of the Main class of the feature analyser making it no longer usable standalone (taking away option b for the scenarios described below) https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154 Afaict the analyser currently can only run in maven context which creates some trouble where a validation is supposed to run in isolation based on built and released features (checking if given features work together). I initially tried to work around with the maven plugin but the analyser only can run on the features it builds and won't allow me to refer external artifacts - copying in the other artifacts in the project also doesn't work as the check of the maven plugin fails for groupid & artifact id. Here are the options I currently see: a) the analyse mojo of slingfeature-maven-plugin is improved to be able to analyse against adhoc merged features and also supports injecting external artifacts (optimally both maven coordinates or file location) - this would allow to validate the combination of features intended to be used in the launcher b) add a standalone analyser as it was present before - here I could think of not embedding the features but rather produce a sidecar jar with all the dependencies that could be set on the classpath for execution, eliminating the trouble addressed via SLING-8102 in a sligthly different way while still keeping the option to validate in a pre launcher phase via CLI tool c) adding validation capabilities to the launcher to be able to run the analyser tasks via cli through the launcher My personal tendency is that a & c might both be quite reasonable to have around (a giving quick roundtrip times during development cycles/build phase - while c rather matches operational validation where the build of the features happens decoupled from the final aggregation/combination). b rather feels like a workaround of c if we don't want to have the analyser being part of the launcher to keep it as slim as possible. Btw. I don't suggest to make analysis a mandatory step in the launcher but at least an option. WDYT? Cheers Dominik -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org