Regarding documentation, Maven generates a dependencies report, from the
pom.xml, which the user can read.
Regarding changing the artifactId for incompatibility, if you declare
that you use semantic version number, then the user can tell that there
is incompatibility by noticing that the major version number changed. He
must do a full audit of changes when incompatibility is introduced,
regardless of our mechanism of notifying the user that incompatibility
has been introduced.
If you use semantic version numbering, your user will not just assume
that the newest version is compatible. Also, it is unfair on me to just
exclude my transitive dependencies and assume that my code will work
with the newest version of a library I depended on. For all you know,
the newer version of my dependency was released after I the version of
my library you are depending on was released. How was I to know (and
document the fact) that a later version of my dependency would be
incompatible?
We cannot just assume that newer version are compatible. There are very
real cases where a newer version is not compatible. I must anticipate
that the latest version of my dependencies, as they are right now, may
not be compatible with the latest version in 3 months time when someone
tries to build my project. I want the Maven build to fail if the user
ends up with an incompatible version on the classpath, and I want to be
flexible, not forcing my user to use a specific version of my dependency
if he needs a feature from a newer, compatible release. I can achieve
this by depending on a version range, defined in accordance to the
semantics of the versioning scheme of the dependency, hopefully
http://semver.org/.
Cheers,
Jesse
On 30/09/2012 19:08, Ron Wheeler wrote:
Read what I wrote:
If you are making an artifact that is not upward compatible, you need
to prevent people from thinking that they can just up the version
number in their GAV and they will get a better version with bugs fixed.
You are in fact giving them a new artifact that will not only NOT fix
bugs but will give the victim NoSuchMethods or NullPointers (if scope
is "provided") in code that would work with the previous artifact.
I don't care if you use the version number as part of the new
ArtifactID or just add the word "nouveau" at the front of the ArtifactID.
Just make sure that you change the G or the A and not just the V.
Ron
On 29/09/2012 4:50 PM, Mark Derricutt wrote:
Wait,
You're suggesting we starting encoding VERSION NUMBERING into the
artefact NAME now? Isn't that just as bad, if not worse than the
abuse of classifiers we already see out there?
We have the exact same issue being discussed here, and also as
mentioned by others use OSGi. One of the key things to think of in
all these situations to also let your artefacts work FOR you.
1) Separate out APIs from implementations - two artefacts
2) Users depend ONLY on API - NEVER implementations - mock those
implementations for testing, or have a third "fake/test" impl.
3) Use composite artefacts for grouping common dependencies - a POM
only artefact with dependencies, i.e. a testing pom that deps on
testng, fest-assert etc. etc.
4) Often its only really the packaging/distribution that really needs
the range to be resolved so maybe we should enhance the assembly
plugin, or some other new packaging plugin.
On 29/09/2012, at 8:21 AM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:
Not acceptable. If a developer is not going to provide upward
compatibility, then they should change the Artifact id to be sure
that no one gets hurt because of the laziness or lack of
thoughtfulness or just plain bad design of the older version.
Major versions are not incompatible in most libraries.
Hibernate is a good example where the developers realized that
version 3 was completely different from versions.
If they wanted to have reasonably method names without the danger of
people getting hurt by trying to run code written to version 2 specs
against version 3, they had to rename the artifacts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
