Thanks for the confirmation. I've created a bug report at as SLING-10060
for tracking.
On Mon, Jan 11, 2021 at 10:44 PM Carsten Ziegeler <cziege...@apache.org>
wrote:
> Hi,
>
> thanks for checking - I would consider this a bug in the current
> implementation and go with #1. #2 is introducing a new format which
> would be incompatible to the current format and you can get the same
> support via the properties section:
>
> <properties>
> <name2>some-${name1}</name2>
> </properties>
>
> and then use name2 in replacePropertyVariables.
>
> Regards
> Carsten
>
> Am 11.01.2021 um 19:12 schrieb Eric Norman:
> > As far as I can tell, it is generally the maven expression evaluator that
> > picks the system property value over the project property with the same
> > name. So an expression like ${property.name1.here} in the pom would get
> > the system property value instead of the project property value.
> However,
> > if I am reading it correctly, the MavenProject#getProperties api call
> > doesn't appear to consider the system property values in the map that it
> > returns and it is simply the model that was parsed from the pom xml.
> >
> > So I can imagine a couple of solutions to my problem:
> > 1. Simply, enhance the slingfeature-maven-plugin Substitution handling
> > of replacePropertyVariables to first check for a system property with the
> > same name and use that value if it is available. If no system property
> > exists, then fallback to the project property value with the same name as
> > the default value.
> >
> > 2. Or refactor the slingfeature-maven-plugin "replacePropertyVariables"
> > configuration to accept a map-like structure instead of just property
> names
> > and let the maven expression evaluator choose the values with something
> > like this:
> >
> > <configuration>
> > <replacePropertyVariables>
> >
> <property.name1.here>${property.name1.here}</property.name1.here>
> >
> <property.name2.here>${property.name2.here}</property.name2.here>
> > </replacePropertyVariables>
> > ...
> > </configuration>
> >
> >
> > Solution #1 would be much easier to implement, but perhaps #2 adds
> > flexibility that could be useful to someone in the future?
> >
> > Let me know if you have any thoughts.
> >
> > Regards,
> > -Eric
> >
> > On Mon, Jan 11, 2021 at 12:50 AM Carsten Ziegeler <cziege...@apache.org>
> > wrote:
> >
> >> Ok, I guess I'm wrong but I thought if you specify the property in
> >> "replacePropertyVariables" then the property value is picked up from the
> >> maven project - which should allow for overrides via system properties -
> >> meaning maven should already do the replacement.
> >>
> >> I assume that is not the case?
> >>
> >> Regards
> >> Carsten
> >>
> >> Am 11.01.2021 um 09:06 schrieb Eric Norman:
> >>> Yes, well i did make an explicit decision and declared my property name
> >> in
> >>> "replacePropertyVariables". My use case is purely for testing so I
> don't
> >>> care much about the reproducibility of the builds.
> >>>
> >>> My question was more about if it is necessary to ignore the system
> >> property
> >>> value supplied on the command line and be forced to use the hardcoded
> >> value
> >>> from the pom? For example, the use case of a parameterized jenkins job
> >>> where the users choice should be passed along to maven and used to
> >>> configure/prepare the environment to run a set of tests against.
> >>>
> >>>
> >>> On Sun, Jan 10, 2021 at 10:41 PM Carsten Ziegeler <
> cziege...@apache.org>
> >>> wrote:
> >>>
> >>>> This is done on purpose - as soon as you allow user input (via system
> >>>> properties), you end up with non reproducible builds.
> >>>>
> >>>> Now, if you are in full control over your project, you can either
> enable
> >>>> "enableLegacyVariableReplacement" or open it up to system properties
> via
> >>>> the "properties" section in your pom and mentioning the property in
> >>>> "replacePropertyVariables" - but this needs to be an explicit
> decision.
> >>>>
> >>>> Regards
> >>>> Carsten
> >>>>
> >>>> Am 10.01.2021 um 23:58 schrieb Eric Norman:
> >>>>> I see that the changes from SLING-9503 changed the variable
> replacement
> >>>> in
> >>>>> slingfeature-maven-plugin to be more limited.
> >>>>>
> >>>>> Is there an expectation that the substitutions for the limited
> >>>>> "replacePropertyVariables" values would only use the property value
> >>>>> hardcoded in the pom and ignore the system property with the same
> name?
> >>>>>
> >>>>> I was expecting that when supplying a system property (with the same
> >>>> name)
> >>>>> on the mvn command line, that the value from the system property
> would
> >> be
> >>>>> used for the substitutions but is not used and the value always comes
> >>>> from
> >>>>> the property defined in the pom.
> >>>>>
> >>>>> If this is not done on purpose, I can provide a fix to check for a
> >> system
> >>>>> property value first before a fallback to the project property.
> >>>>>
> >>>>> Let me know what you think.
> >>>>>
> >>>>> -Eric
> >>>>>
> >>>>
> >>>> --
> >>>> --
> >>>> Carsten Ziegeler
> >>>> Adobe Research Switzerland
> >>>> cziege...@apache.org
> >>>>
> >>>
> >>
> >> --
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
> >
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
