You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Dominik Süß <do...@gmail.com> on 2019/05/16 06:02:56 UTC
[Feature Analyser] Usage scenario gap
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
Re: [Feature Analyser] Usage scenario gap
Posted by Karl Pauls <ka...@gmail.com>.
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üß <do...@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 <ka...@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üß <do...@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.bosschaert@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 <cz...@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
> > > > > cziegeler@apache.org
> > > > >
> > > >
> >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> >
--
Karl Pauls
karlpauls@gmail.com
Re: [Feature Analyser] Usage scenario gap
Posted by Dominik Süß <do...@gmail.com>.
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 <ka...@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üß <do...@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.bosschaert@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 <cz...@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
> > > > cziegeler@apache.org
> > > >
> > >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: [Feature Analyser] Usage scenario gap
Posted by Karl Pauls <ka...@gmail.com>.
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üß <do...@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 <da...@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 <cz...@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
> > > cziegeler@apache.org
> > >
> >
--
Karl Pauls
karlpauls@gmail.com
Re: [Feature Analyser] Usage scenario gap
Posted by Dominik Süß <do...@gmail.com>.
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üß <do...@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.bosschaert@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 <cz...@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
>> > cziegeler@apache.org
>> >
>>
>
Re: [Feature Analyser] Usage scenario gap
Posted by Dominik Süß <do...@gmail.com>.
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 <da...@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 <cz...@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
> > cziegeler@apache.org
> >
>
Re: [Feature Analyser] Usage scenario gap
Posted by David Bosschaert <da...@gmail.com>.
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 <cz...@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
> cziegeler@apache.org
>
Re: [Feature Analyser] Usage scenario gap
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org