On 30/01/2013 3:18 PM, Joachim Durchholz wrote:
> 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.
It does.
>
>> 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.
>
In the POM it should G- Where A What V could include the SCM
revision 1.3.4.5687
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.
????? Never had this problem.
>
>>>>> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org