Yet anotherthread on the brokenness of version ranges, I so wish they would be "fixed" - but answering the question of what exactly "fixed" is, is rather difficult.
4 plus ones
Shared publicly•View activity
View 18 previous comments
- Oct 1, 2012
- My honest opinion: To fix ranges you would first need to get everyone to agree to a set of semantically compatible versioning schemes. The concept of "this works with this ABI" is fine, but there is no agreed upon way to define an ABI version in Java, so the whole version range thing is hopeless.Oct 1, 2012
- No, you only need to agree within your own organisational unit what they mean as external dependencies are always locked to a single version.Oct 1, 2012
- Maybe by convention the way you do it but that doesn't provide any form of enforcement. Maybe an enforcer module that checks and prevents ranges in any dependency that's NOT in the same groupId as your artifact could enforce that, but otherwise it's just back down to convention and diligence.
Personally think I may be more comfortable if there were no such thing as transitive version ranges - even if you have locked down a version, doesn't mean another range might kick in.
The release plugin should, quite possibly rewrite your POM as part of the release with the resolved poms. release:prepare-with-pom will generate a release-pom.xml but is this the pom thats deployed to the remote repository, or is it only included in the jar?
I do see however that all the goals support a pomFileName attribute, so maybe if we set that to release-pom.xml we could live in a near perfect world.Oct 1, 2012
- so, when you use the Configured libraries, did you lock down all the versions? Or let some of the internal ranges do their thing?Oct 2, 2012
- I lock them down.Oct 2, 2012