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