Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MNG-7914] Provide a single entry point for configuration #1595

Merged
merged 4 commits into from
Aug 22, 2024

Conversation

gnodet
Copy link
Contributor

@gnodet gnodet commented Jul 4, 2024

No description provided.

Copy link
Member

@michael-o michael-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a conceptual problem here. There are only Maven user properties and Java system properties, but not Maven system properties. We are trying to get rid of them. That should clear in a new solution. I wouldn't even try to make system properties right. @slawekjaranowski

@gnodet
Copy link
Contributor Author

gnodet commented Jul 5, 2024

There is a conceptual problem here. There are only Maven user properties and Java system properties, but not Maven system properties. We are trying to get rid of them. That should clear in a new solution. I wouldn't even try to make system properties right. @slawekjaranowski

Yes, it makes sense. I've removed the system properties support to only keep maven.properties which are user properties.

@michael-o
Copy link
Member

There is one conceptual problem I have here: How does this relate to maven.config doesn't it cause confusion? Add even more complexity?

@gnodet
Copy link
Contributor Author

gnodet commented Jul 5, 2024

There is one conceptual problem I have here: How does this relate to maven.config doesn't it cause confusion? Add even more complexity?

It's imho, a much better way to provide configuration properties. maven.config can be used to provide command line arguments, but it has a few problems: it does not have the usual multi-level that we have for settings or toolchains (global, user, project). In addition, the syntax is not user friendly, does not support inclusions of other files and does not support substitutions.
Imho, we should keep maven.config for actual CLI arguments and users should use maven.properties to define properties such as https://maven.apache.org/resolver/configuration.html (we should have a similar one for maven).

@michael-o
Copy link
Member

There is one conceptual problem I have here: How does this relate to maven.config doesn't it cause confusion? Add even more complexity?

It's imho, a much better way to provide configuration properties. maven.config can be used to provide command line arguments, but it has a few problems: it does not have the usual multi-level that we have for settings or toolchains (global, user, project). In addition, the syntax is not user friendly, does not support inclusions of other files and does not support substitutions. Imho, we should keep maven.config for actual CLI arguments and users should use maven.properties to define properties such as https://maven.apache.org/resolver/configuration.html (we should have a similar one for maven).

I see, then we also should educate users when to use what.

@gnodet
Copy link
Contributor Author

gnodet commented Jul 5, 2024

There is one conceptual problem I have here: How does this relate to maven.config doesn't it cause confusion? Add even more complexity?

It's imho, a much better way to provide configuration properties. maven.config can be used to provide command line arguments, but it has a few problems: it does not have the usual multi-level that we have for settings or toolchains (global, user, project). In addition, the syntax is not user friendly, does not support inclusions of other files and does not support substitutions. Imho, we should keep maven.config for actual CLI arguments and users should use maven.properties to define properties such as https://maven.apache.org/resolver/configuration.html (we should have a similar one for maven).

I see, then we also should educate users when to use what.

Agreed. I suppose enhancing https://maven.apache.org/configure.html would be a first step.

@gnodet gnodet force-pushed the MNG-7914-config-properties branch from c7c6455 to f658846 Compare July 5, 2024 13:15
@gnodet gnodet modified the milestones: 4.0.0-beta-4, 4.0.0 Jul 6, 2024
@slawekjaranowski slawekjaranowski self-requested a review July 6, 2024 11:05
@michael-o
Copy link
Member

I will get back to this tomorrow. This is a crucial change which needs careful design.

@gnodet gnodet force-pushed the MNG-7914-config-properties branch from f658846 to 0cb4067 Compare July 10, 2024 11:11
@gnodet gnodet force-pushed the MNG-7914-config-properties branch 3 times, most recently from 4481525 to 72e905d Compare July 10, 2024 14:00
# Comma-separated list of files to include.
# Each item may be enclosed in quotes to gracefully include spaces. Items are trimmed before being loaded.
# If the first character of an item is a question mark, the load will silently fail if the file does not exist.
${includes} = "?${maven.user.conf}/maven.properties", \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you are quoting now the value, wouldn't it be more natural to put the question mark at the end? Unless you want to use "¿" as well. Maybe qoutes should be mandatory. Worth looking into Tomcat code for ths. I do not remember the motiviation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure quotes are mandatory, but they certainly avoid any problem with spaces inside path.
About the location of the '?', I fear that putting it at end will be less prominent.
It's also the same syntax than for optional profiles, see https://maven.apache.org/guides/introduction/introduction-to-profiles.html#explicit-profile-activation

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. Shouldn't then the question mark be outside of the quotation marks to make the entire space-containing value optional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, makes sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added support for moving the '?' before the quotes (both before and after are supported), the default config file moves them before.

@slawekjaranowski
Copy link
Member

my test in project .mvn/maven.properties with content:

${includes}=default.properties,?env-${env:envName}.properties

looks like ${env...} is not interpolated in project properties

executed:

envName=test mvn ...

It will be great to support user properties in such case to have a possibility:

${includes}=default.properties,?env-${envName}.properties

and

mvn -DenvName=test ...

@gnodet
Copy link
Contributor Author

gnodet commented Jul 11, 2024

my test in project .mvn/maven.properties with content:

${includes}=default.properties,?env-${env:envName}.properties

looks like ${env...} is not interpolated in project properties

executed:

envName=test mvn ...

It will be great to support user properties in such case to have a possibility:

${includes}=default.properties,?env-${envName}.properties

and

mvn -DenvName=test ...

I've added a unit test showing this now works.

@gnodet
Copy link
Contributor Author

gnodet commented Aug 17, 2024

@michael-o @slawekjaranowski @cstamas any more comments on that one ?

@michael-o
Copy link
Member

@michael-o @slawekjaranowski @cstamas any more comments on that one ?

Will give it a spin again today

Copy link
Member

@michael-o michael-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is lacking completely is documentation how feature rich this approach is with inclusiion and optional files w/o reading source code.

userProperties.stringPropertyNames().stream()
.filter(k -> !sys.contains(k))
.forEach(k -> System.setProperty(k, userProperties.getProperty(k)));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We must seriously reconsider this promotion in the future before GA.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The best we should not change a System property at all

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've raised #1661 to assess if there are any failing ITs as a first step.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Invoker and friends are our worst enemies here.

Copy link
Member

@slawekjaranowski slawekjaranowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

evaluate properties from cmd

@gnodet
Copy link
Contributor Author

gnodet commented Aug 17, 2024

evaluate properties from cmd

Could you expand a bit more ?

@slawekjaranowski
Copy link
Member

slawekjaranowski commented Aug 17, 2024

evaluate properties from cmd

Could you expand a bit more ?

more in comments: #1595 (review)

#1595 (comment)

here only as reason why I marek PR as require change

@gnodet
Copy link
Contributor Author

gnodet commented Aug 17, 2024

evaluate properties from cmd

Could you expand a bit more ?

more in comments: #1595 (review)

#1595 (comment)

here only as reason why I marek PR as require change

Thx. I modified the UT and fixed the use case.

Copy link
Member

@slawekjaranowski slawekjaranowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ok for me.

We need to review documentation for it at all, generated and manually written.

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great

@gnodet gnodet merged commit 6ac914d into apache:master Aug 22, 2024
13 checks passed
@gnodet gnodet deleted the MNG-7914-config-properties branch August 30, 2024 14:28
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants