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
>
