maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 21:52:58 GMT
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.
> 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 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/
>> 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 

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:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message