Delany <delany.middle...@gmail.com> wrote: > Oh hi Nils. Yeah well a compromise is reached. I would still support a ban > on <servers> tag in project-specific settings - more for enforcer. > Its just about maintaining good abstractions. "User settings" what should > that mean? Its basically the settings that a user doesn't want to commit. > > You wanted "This is currently the only artifact repository that our build > pipelines can access, but developers will sometimes want to build a project > locally that requires other artifact repositories, e.g. a third-party > GitHub project or an experimental Proof of Concept project which requires > dependencies from a repository that hasn't been added to our in-company > artifact repository yet. A global settings file that defaults to our > private artifact repository would interfere with such local builds." > > I just don't get the use case since I regularly make use of an alternative > repository configured in my user settings when I test maven pre-releases > > <profile> > <id>stage</id> > <activation> > <property> > <name>stage</name> > </property> > </activation> > <repositories> > <repository> > <id>staging</id> > <name>Maven Staging</name> > <url> > https://repository.apache.org/content/repositories/maven-${stage}/</url> > </repository> > </repositories> > <pluginRepositories> > <pluginRepository> > <id>staging-plugin</id> > <name>Maven Staging</name> > <url> > https://repository.apache.org/content/repositories/maven-${stage}/</url> > </pluginRepository> > </pluginRepositories> > </profile> > </profiles> > </settings> > > When abstractions erode it becomes difficult to think. In this case though > the idea of user settings was never a strong one.
We want our internal projects to be self-contained, so they work without a requirement for specific user or global Maven configuration, and we don’t want to require any non-internal projects to require any specific user or global Maven configuration either. I’ve worked at companies we’re they said ‘your ~/.m2/settings.xml file needs to look exactly like this’, but then working with projects from outside the company (open source projects from GitHub for instance) became a hassle, because you need to temporarily change your user settings whenever you want to work with an external project on your machine. And of course there were always issues with people using an outdated or otherwise incorrect user settings file. To get rid of those issues, we put `--settings=.mvn/settings.xml` in .mvn/maven.config in our internal projects to automatically apply the settings file included in the project (we have a Spring Initializr-based project generator which automatically adds these files in every project), which works, except that it doesn’t when Maven is not run from the root directory of a multi-module project. I understand project-specific settings should get rid of that limitation. If anyone can think of a nicer solution than project-specific settings to accomplish such self-contained projects, I’d love to hear about it, because I agree that the project-specific settings feature also opens a new door to “you’re doing it wrong”. Nils. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
