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 > > >
