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 >
