maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 20:18:02 GMT
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 

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.

> 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.

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

View raw message