Actually... if I may. I might be able to end this a little easier by providing some information which I think has been left out of the conversation so far.
The newest release of Nexus does have something to help you in pinpointing a particular revision. Granted, you will need to do a little work in order to make it do what you are looking for... Nexus now comes with a functionality of metadata. You can attach whatever metadata you want to an artifact - and you can query Nexus to get the information later on. The work that would come into play is that you would need to have a plugin created which would detect the current scm revision and then attach that as metadata to the uploaded artifacts. If I recall correctly, someone had written a blog posting about wanting a plugin that would batch-upload to nexus for snapshot in the same way that it batch-uploads for a staging repository. I feel that the addition of this kind of metadata would be an excellent feature to add to such a tool... Anyhow, in order to make this work a little bit of work has to take place which will make using attributes in maven repositories an easier thing to use. Thanks, Roy Lyons Senior Configuration Engineer On 1/30/13 2:18 PM, "Joachim Durchholz" <[email protected]> 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. > >> 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: [email protected] >For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
