Why a redundant version in the artifactId?
See original GitHub issueLeaving the groupId aside (this has to be decided in a consistent way for all parts of upcoming releases) I noticed a redundant static version number in the artifactId microprofile-config_1.0_api
.
Why should a JAR be named microprofile-config_1.0_api-1.0-SNAPSHOT.jar
or later microprofile-config_1.0_api-1.0.jar
? That makes no sense. The version will be part of the file name anyway.
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
java - Eliminate Maven POM redundancy
I'm using Maven version 2.1.0. Not possible. With Maven 2.x, you must declare the parent element in child module and the parent element ......
Read more >Remove redundant explicit dependency versions - OpenRewrite
Remove explicitly-specified dependency versions when a parent POM's dependencyManagement specifies the version. · This recipe has no required configuration ...
Read more >Remove Duplicate Dependencies with Maven
Learn how to detect duplicate dependencies in Maven using the mvn dependency:tree and mvn dependency:analyze-duplicate commands.
Read more >Maven auto-import adds redundant library dependencies ...
Maven auto-import adds redundant library dependencies for EAR build ; Assignee, Nikolay Chashnikov ; Subsystem, Build. Maven ; Affected versions, Not specified.
Read more >false positive ...
It affects at least versions 4.1.4 and 4.1.3. ... SpotBug] Redundant null check at SpotBug.java:[line 11] ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Though I understand the reasoning, I’d let @struberg explain. However, even if it would be the best approach, I wouldn’t make these decisions without discussing first in the open, ideally mailing list. Please, Mark, don’t make any changes like this without a previous discussion, otherwise it will get messy. Everybody needs to understand the reason and it should be documented, otherwise nobody will keep the same convention.
This is fixed.