maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lyons, Roy" <>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 20:45:23 GMT
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


Roy Lyons
Senior Configuration Engineer

On 1/30/13 2: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
>>> 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
>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*
>> 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
>> 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
>>> 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
>>> ???
>>> 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
>> 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
>>> warning flag that something is wrong on the project's side. Either the
>>> project is doing something wrong, or it's explaining something wrong;
>>> 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/
>> 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,
>> repository it was pulled from.
>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
>> 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.
>>> hypocritical because it's assuming you're not.
>>> I'm pretty sure neither is actually the case, in which case it's based
>>> 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:

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

View raw message