search

Terracotta-OSS / terracotta-platform

http://terracotta.org
Apache License 2.0
32 stars 48 forks source link

Add settings.xml per project #1117

Closed mathieucarbou closed 1 year ago

mathieucarbou commented 2 years ago

I'd like that we have such things per project (./mvn -s settings.xml ...), that could be optionally used to:

  1. make sure we don't miss any repo for the project
  2. isolate the Maven repository per project, which makes sure no library will be found locally and coming from elsewhere not defined in the pom/settings.
  3. not be impacted by a global settings.xml that could contain overrides, mirrors, etc
  4. avoid us to having to deal with all the troubles coming from settings.xml files repo and mirrors

In this specific case for platform, the settings is blank because the project runs fine with declared repos in the parent pom.

chrisdennis commented 2 years ago

I don't understand the motivation here.

  1. All needed repositories should be listed in the pom.xml
  2. This can be achieved with a single settings.xml in a users .m2, or using a single command line property set.
  3. The global settings.xml is supposed to interact like that - but the project should build by default without one.
  4. The solution to the trouble with "bad" settings.xml is to fix them, not to populate all the repositories with more settings.xml files.
akomakom commented 2 years ago

If there is a desire to test "without" settings.xml modifications, it is easy enough to create a blank one (I have one in ~/.m2/settings-blank.xml):

<settings>
</settings>

and then I can troubleshoot with mvn -s ~/.m2/settings-blank.xml XXXX

mathieucarbou commented 2 years ago

Point 1: is not preventing overrides from a global settings.xml file.

Point 1: is also not preventing mistakes (wrong repo url) or missing repos in the pom in case it is there in the global settings.xml file : I have fixed for example 2 issues like that in angela-ee and tcdb thanks to this.

Point 2: NO. Because the difference here is that it is project-provided. You missed the point of the PR, which is to provide a minimally settings.xml file for dev ensuring the project works. Which means no other repo or mirrors are needed besides those declared in the pom or settings file The goal is not to test with an empty one, the goal is to provided a minimal one. I.e. for people requiring some unblocks, then some mirrors could be setup here (I think it's the case for 4.x). In 10.x right now we are using the wrapper which allows to control that better.

Point 4: I disagree also: this is a way to optionally isolate each repo, also settings, per project. Many build systems also for the same, and its also a supported maven convention to have settings.xml at the project root, even eventually added by default with a maven.config file in .mvn folder. This si exactly equivalent of the gradle fiels we have which are defining repos and settings per project. There is no global gradle file common to all gradle project.

mathieucarbou commented 2 years ago

If there is a desire to test "without" settings.xml modifications, it is easy enough to create a blank one (I have one in ~/.m2/settings-blank.xml):

<settings>
</settings>

and then I can troubleshoot with mvn -s ~/.m2/settings-blank.xml XXXX

The point is not to test with a blank settings...