Am 30.01.2013 10:20, schrieb Stephen Connolly:
Now that's just crazy, who would roll back an SVN repo and overwrite a
revision past?
I'd download from http://repo/tags/1.3.2. And if that's borked, the
maintainer will provide http://repo/tags/1.3.3 and I'll update the pom to
download from there.
STOP RIGHT THERE.
Hey. Why are you screaming?
Once you publish 1.3.3 to a (pseudo) Maven repository you can NEVER edit it
/ update it / modify it
Yeah. Not happenin. 1.3.3 is at http://repo/tags/1.3.3. 1.3.4 at
http://repo/tags/1.3.4.
And yes it's an SVN repo, not a Maven repo. I have mentioned that time
and again, it's even in the quote above.
I don't know why you're even talking about a Maven pseudo repo. I'm
talking about importing from a non-Maven repo; somehow you've been
missing that point entirely.
The reason is that anyone who downloaded that using Maven will *NEVER* get
the modified version because release versions have the (Maven) contract
that they never change. That is a core principal of Maven.
If you don't get that, well, quite frankly I will just plain stop.
Well, I got that about five messages ago, and have expressed it in at
least two of the three replies I wrote after that.
If you don't get that, well, quite frankly I'll recommend you improve
your reading skills.
Really. It's been quite a while since I tried talking to somebody who
was so intent on *not listening*, constantly reinterpreting what I wrote
into something entirely different.
The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
stable yet),
If the pom is at a GAV of foo:bar:1.3.3 and that pom actually contains a
version of 1.3-SNAPSHOT, sorry all hell will break loose when Maven tries
to unfurl that mess.
Well it isn't, of course.
However, you're more intent on pinpointing errors in my thinking rather
than in looking for ways that the intention might work, but then you'd -
heaven forbid! - *understand* what I'm saying, and you'd have to admit
I'm not just a misguided idiot.
or one of 1.3.2 which would then be updated to 1.3.3 and deployed to a new
maven coordinate (and really be a different pom, in the latter case)
but
Maven is not going to re-download it because Maven repo is write once,
delete never, modify never for all release artifacts.
No SCM matches those semantics, so you will have an impedance mismatch.
???
SCMs don't modify revisions once they are published.
That's generally considered extremely dubious practice.
I am talking about people pushing modifications with a new revision.
Yes, as am I.
How is that breaking Maven's assumptions? I wouldn't download anything
from an SVN HEAD (except for a Maven SNAPSHOT, where it's acceptable as
far as I understand things).
> There
are loads of examples of people using a Subversion repository as a Maven
repository... on the basis that a Maven repository is just a directory
layout convention and a Subversion repository published over http(s) is
just a set of directories.
I am *so not* going to do that. The Maven docs are simply too thing to
even attempt such a thing. I'd probably need to scrape the proper
directory layout from the sources, and risk breakage whenever a new
version of Maven comes out.
The most famous one was java.net2
Where, because it was a Subversion repository, you had people *reverting
commits and publishing new builds of the same version*
If you use revision numbers (e.g. r23462) as coordinates, that's
technically impossible. (Unless somebody unloads the entire history of
the svn repo, edits the trail, and reloads it - nobody would do that. In
git, the equivalent is an SHA hash over the entire history, so its even
technically impossible for such a coordinate to be unstable.)
With tags (strings, usually formatted like "v1.5.3" or something), it is
indeed possible. Anybody who moves a tag to a new artifact deserves his
personal place in hell though; that the Java.net2 guys did such a thing
means that people shouldn't rely on version numbers but on revision
numbers as SCM coordinates.
I guess any plugin that does an SCM import could take a version number
(or maybe the current HEAD tag) to determine the revision to check out,
but the real coordinate is the revision.
When you host a Maven repository on a Subversion repository (never mind
that the file storage costs for binaries in Svn is sub-optimaal) you
encourage people to think that it is like a Subversion repository. It is
not.
That's why I've been talking about importing from an SCM, and never,
never, never about setting up a Maven repository inside an SCM.
Check the messages if you don't believe me. That idea that a Maven
repository could live inside SVN is entirely yours.
Now if you are arguing something else, then we need to be clear on what we
are arguing... but I am saying don't use Subversion repos AS A MAVEN
REPOSITORY... if you want to use them as some other binary artifact
repository, fair enough... just NOT AS A MAVEN REPOSITORY.
Oh. Whew. Finally.
Yes, "some other binary artifact repository" describes it just fine.
Maybe the madness is in the idea that SCMs modify revisions past?
Nope, but maybe you never had to work with the old java.net2 repo
No. It was never very good anyway. The entire dev.java.net structure was
an example how not to do it. I stayed away from it as far as possible -
and I have seen many projects moving elsewhere, too.
Keep in mind, also, that I may be right and fed up arguing,
I'm pretty well aware of this.
I have been in your position in other projects.
However, if the same issue keeps coming up over and over again, that's a
warning flag that something is wrong on the project's side. Either the
project is doing something wrong, or it's explaining something wrong; it's
worth digging up the true cause and squash it once and for all.
I think we are fairly consistent in saying: USE A MRM
Please, no shouting again.
And I'm now explaining for a gazillionth time: an MRM doesn't change
anything about the issue at hand, which is that a manual install,
whether through an MRM or via the command line, will not preserve the
version information, nor the information what origin it was taken from.
I'll try and make the point again...
Please look in your local cache...
If I look in my local cache I will see a bunch of files, e.g.
~/.m2/repository/junit/junit/maven-metadata-central.xml
~/.m2/repository/junit/junit/maven-metadata-local.xml
~/.m2/repository/junit/junit/maven-metadata-cloudbees-internal.xml
~/.m2/repository/junit/junit/resolver-status.properties
and most importantly I will see
~/.m2/repository/junit/junit/4.11/_maven.repositories
Now these files all contribute to tell Maven the *source* of
that ~/.m2/repository/junit/junit/4.11/junit-4.11.pom
and ~/.m2/repository/junit/junit/4.11/junit-4.11.jar in other words, which
repository it was pulled from.
Yep.
It does not say from which SCM URL and revision it was pulled though.
So when I said:
"Because the local repository cache for m3 onwards stores the source
of the jar, and most likely the sources do not match."
That was the meaning of "source" that I was getting at. Please re-read my
quoted sentence and if you still don't get enlightenment, then tell me as I
will then agree that there is no point continuing with you.
It's simply beside the point.
I'm not talking about importing from a repository; that's what
dependencies are for, and I'm not going to reinvent a wheel that's been
installed and in use since Maven has been in existence.
I'm talking about importing from "some other binary source".
This is the one use case where I see a deficit in what Maven offers.
Given the sheer amount of badly imported binaries on Maven Central, I
think that's a general problem - if this were something that happened
just to me, or just for one project, I'd have stopped arguing long ago
since it's simply not worth it.
I'm sorry that I have to be even more blunt than last time, but it
seems I need to:
Statements like that are too near to content-free PR spam to be
anything but revulsive for me.
Also, they are an indicator that you feel the need to sway opionions
by emotional (and factually irrelevant) appeals, indicating further
that you feel your factual arguments are too weak to be convincing.
Please. Drop that. It's insulting because it's assuming I'm an idiot. It's
hypocritical because it's assuming you're not.
I'm pretty sure neither is actually the case, in which case it's based on
an assumption that's simply untrue.
you confused "source = origin" with "source = source code" twice...
Don't complain if you don't get your definitions straight; in software
development, the standard definition is "source code".
While that might be different in Maven terminology, you can't simply
assume that everybody somehow guess what you actually mean.
> up to
you to prove the assumption untrue at this point.
Says the man mixing up SVN and Maven repos all the time... and
thoroughly misunderstanding the issue at hand...
... sorry, but that's hilarious.
And you even had a vague notion that that might be the issue. You just
forgot to ask to clarify before steaming ahead with assumptions... oh
dear, I really need to take a break. This is just priceless.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
