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