On 30 January 2013 08:30, Joachim Durchholz <j...@durchholz.org> wrote:
> Am 30.01.2013 00:22, schrieb Stephen Connolly: > > On 29 January 2013 22:22, Joachim Durchholz <j...@durchholz.org> wrote: >> >> Am 29.01.2013 21:09, schrieb Stephen Connolly: >>> >>> On Tuesday, 29 January 2013, Joachim Durchholz wrote: >>> >>>> >>>> Am 29.01.2013 19:42, schrieb Anders Hammar: >>>> >>>>> >>>>> The right/correct solution here is to setup an internal Maven >>>>> >>>>>> repository where you deploy those jars to. >>>>>> >>>>>> >>>>>> I still feel very uneasy about that, and I think I can pinpoint the >>>>> reason a bit better now: >>>>> >>>>> One of the promises of Maven is that you can describe the entire >>>>> build process in the poms. Manually installing to a repository is >>>>> outside the poms; it just makes that jar "magically appear". It >>>>> would be okay for those jars where no traceable origin is available >>>>> anymore (the situation would be dubious for other reasons though); >>>>> however, it is NOT okay for those situations where there's a >>>>> perfectly valid traceable origin for the jar, such as a stable >>>>> company website to download it from, an SVN repo with a fixed >>>>> revision number to take it from >>>>> >>>>> >>>> That gives you a false sense of security. >>>> >>>> The maven repository cache does not work the same way... >>>> >>>> >>> That's not a falsifiable statement. >>> First, you don't explain what of a gazillion of potential differences you >>> actually mean. >>> Second, you don't explain how that difference can create problems, and >>> hence doesn't open up a road to getting the problem addressed in some >>> way. >>> >>> >> And you don;t clarify what exactly you mean by "an SVN repo with a fixed >> revision number to take it from"... which I take to mean that evil way >> that >> java.net2 used to be run... >> >> If you (ab)use a SVN repo as a Maven repo then you are opening up trouble >> where people familiar with how SVN works think they can just revert the >> deployment of foo 1.3.2 and redeploy to fix the borked artifact... >> > > 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. Once you publish 1.3.3 to a (pseudo) Maven repository you can NEVER edit it / update it / modify it That is the whole point. 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. > 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. > 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. 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. 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* 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. 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. > > > It is really quite simple: STOP USING SOURCE CONTROL AS A MAVEN >> REPOSITORY, >> THAT WAY MADNESS LIES >> > > 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 > > > 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 > > > > so go for the > >> short-cut "This is the Maven Way" which really means "We have trashed this >> over and over and over and over in the mailing list, search the archives, >> do the research in the Maven mailing list archives, and we are *very* sure >> you will come to agree with us" >> > > If you have argued it over and over, put it in a FAQ page and post the > link. > > > (Note there are a lot of blogs out there by people who never pop their >> head >> on the mailing lists... if they have not had their theories exposed to the >> pool of engaged Maven users and Maven developers... take those theories >> with a pinch of salt) >> > > Yeah, the net is full of recipes that worked once. > That's why I'm here arguing and getting on your nerves rather than ranting > in a blog about how maven's shortcomings (and out myself as an even greater > fool than with arguing here). > > Still, I am under the impression that you're so tired of arguing that you > don't allow for the possibility that there might be a real issue. > > > > Because the local repository cache for m3 onwards stores the source >>>> of the jar, and most likely the sources do not match. >>>> >>> >>> Two potential scenarios here: >>> >>> 1) There are no sources available. (E.g. the jar is proprietary and >>> vendor >>> policy dictates that no sources are released.) >>> Your point is moot there. All that's needed is a pom that takes the >>> Maven version number, maps it to the download version number (whether >>> it's SVN or something else), and installs the download in the local >>> cache repo. >>> >>> 2) Sources are available from the same source as the binary jars; nothing >>> prevents the binary jar download from downloading the sources as well. No >>> room for source mismatches. >>> >>> You have missed the point completely... I am talking about the "source" >> as >> in "where it came from" not "the source code" >> > > Well, I'm positing a stable source. > Which is the norm for SCM (if you use a revision number or tag as part of > the coordinate you're downloading from). > It's also the norm when downloading from sites like Sourceforge - old > revisions never get overwritten, people release a new version using a new > filename that includes a revision number. > > MAVEN IS NOT THE ONLY ENLIGHTENED TOOL FOR VALUING STABILITY. > > Please re-read and may the light of enlightenment shine upon you. >> > > Sigh. > Now it really does apply: 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. If you are building a project which has a different set of repositories, and you need junit:junit:4.11 but the local cache version is not from the "source" configured in the effective list of repositories available for that project, then Maven will go and pretend like the cache is empty. 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. > > > >> 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... up to you to prove the assumption untrue at this point. > > > M2e uses m3 which uses aether under the hood... >>> >>>> >>>> Use a MRM and all the pain is gone >>>> >>>> >>> There's still the pain that the build process (which involves retrieving >>> a jar from some non-Maven but still reliable soure) isn't documented in >>> any pom. No information about which file version it was, about where it >>> came from, nothing. >>> >> >> True, but those details should be in the (possibly stub) pom you upload >> with the artifact. >> > > Hm. Neither the mentions of install-file here on the list nor the usage > examples on install-file explain that that's an option. Nor how it would > work. Nor where the workflow is explained. > It I were the only person who didn't see that, I'd chalk that up to > overlooking it, but it seems I'm not alone with that. From which I conclude > that this is something that needs to be documented, badly. > > > 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. >>> >> >> Nope that comment is a hint that I am aware that I am giving you the "This >> is the Maven Way" speech... >> > > Yes, and I meant that "Maven Way" speech. > > > You should look up the origin of the phrase "drink the kool-aid" >> > > I knew it already. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org > >
