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 <karlpa...@gmail.com> 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üß <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 >
