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üß <dominik.su...@gmail.com> 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 <cziege...@apache.org> > > 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 > > > > > -- Karl Pauls karlpa...@gmail.com
