apache
[MNG-5913] Allow defining aliases for existing server configurations in settings.xml
Add the next tag ids to the server in settings.xml
Additional server will be created in memory by SettingsBuilder, so the generated configuration should be transparent to other as Settings#getServers() will return complete list.
https://issues.apache.org/jira/browse/MNG-5913
This needs to be made sure will not break Maven 3, as same settings is shared by both currently.
This needs to be made sure will not break Maven 3, as same settings is shared by both currently.
unit test, looks ok for me.
I tested with: mvn help:effective-settings
ok, who is willing to work on it with me? If proposition will be generally accepted I will do similar in 3.9.x
I hope such feature will be valuable.
Well, settings with current 3.9.9 are NOT read:
[WARNING]
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'aliases' (position: START_TAG seen ...</id>\n <aliases>... @61:15) @ /home/cstamas/.m2/settings.xml, line 61, column 15
[WARNING]
Or this is "ok"? Is settings loaded partially or discaded?
I am willing to jump in as Njord does something similar, but my concern is that Maven 3.x is not "forgiving" while readint settings.xml AFAIK. And if we modify XML then things like ./mvnw will work ONLY (for user) if 3.9.10 used?
Well, settings with current 3.9.9 are NOT read:
[WARNING] [WARNING] Some problems were encountered while building the effective settings [WARNING] Unrecognised tag: 'aliases' (position: START_TAG seen ...</id>\n <aliases>... @61:15) @ /home/cstamas/.m2/settings.xml, line 61, column 15 [WARNING]Or this is "ok"? Is settings loaded partially or discaded?
it is correct because 3.9.x does not have it yet
I am willing to jump in as Njord does something similar, but my concern is that Maven 3.x is not "forgiving" while readint
settings.xmlAFAIK. And if we modify XML then things like./mvnwwill work ONLY (for user) if 3.9.10 used?
I hope we can have next version of settings schema for 3.9.x ... so if someone update own settings alos will use newer version of Maven
why we need to change deprecated stuff?
PMD or rewrite, might even do both. Spot seems ending up being short:
- https://github.com/apache/maven/pull/2338
why we need to change deprecated stuff?
Found this one related:
deprecated staff can be used by Maven 3 plugins - we need support backward compatibility for Maven 3.x
@gnodet @cstamas any more comments for it?
I will cleanups from comments and will be ready.
I am still unconvinced that this change is backward compatible. Or the idea is that whoever uses this feature must use Maven 4 or latest (upcoming) Maven 3.9.10? What happens if by mistake (or project mvnw) is 3.9.9 or 3.8.8?
I am still unconvinced that this change is backward compatible. Or the idea is that whoever uses this feature must use Maven 4 or latest (upcoming) Maven 3.9.10? What happens if by mistake (or project mvnw) is 3.9.9 or 3.8.8?
Confirm - for new future Maven 4.x (rc-4+) and 3.9.10+ will be needed.
Such futures will be needed for deployments or for special environments where users use more private repositories. So if user want to use it simply needs the latest version of Maven.
For older Maven warning will be printed.
For older Maven warning will be printed.
I am aware of warning, but am unaware what exactly happens when that warning is printed: is whole settings ignored, is only the server (with unknown element) ignored... Given we talk about same file that all Maven 3+ would use, I think we need to be careful here. Maven is already printing a LOT to screen, is very easy to miss one line warning and then tinker why build/deploy/whatever failed...
As I see from my testing only unparsable settings.xml break a Maven build at all settings.xml with correct xml syntax, but with unkown tags are processed, all recognized settings are correctly read
I can add IT for such case - what happens with unrecognized tag in settings.xml - in separate PR if can help you
Kindly reminder - Any more comments here? Anything what I can do more ...?
If there are no more requests, I would like to merge it
Looking at this I am still convinced that is should not be delivered with 3.9.10.
Yet another problem is that we are abusing one server structure for multiple ones, e.g., you are settings headers or other transport-related config. It will be applied to mulitple servers, but you need to split them up actually except credentials.
