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
