I just noticed that I missed to add details why using the maven build failed for me - at this build time I only have the cachefolder available as "local repository" - the way that the repository goal produces this cache folder doesn't generate/download the pom.xml files for the artifacts. I first was trying to use install:install-file to make the external feature addressable which did work, but the analyzer subsequently fails as when running in the maven context the analyzer only supports reading artifacts via maven.
So this opens another option to solve the problem, which is adding support for a local cache folder "bypassing" the maven lookup (e.g. configuring a local cache folder would bypass maven lookup). Cheers Dominik On Thu, May 16, 2019 at 10:34 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 >> > >> >
