On 29 January 2013 22:22, Joachim Durchholz <[email protected]> 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... 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. It is really quite simple: STOP USING SOURCE CONTROL AS A MAVEN REPOSITORY, THAT WAY MADNESS LIES > In other words, you're blocking all roads except the One True Way that you > think is best, regardless of whether you're right or not. > Well, I am not forcing which MRM to use, and I would be much happier if you used a simple HTTP backed repo that is not also a Subversion repository if you really feel the lack of need for a MRM... but performance will be affected if you are not using a proxying MRM which collapses all required repositories into one. Keep in mind, also, that I may be right and fed up arguing, 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" > That's quite an unfair style of arguing. You're essentially ramming down > your beliefs down my throat, "believe it or leave it but don't question my > superior knowledge of build processes" (a claim that I would want to test > thoroughly before accepting it from anybody, including Donald E. Knuth > Himself). Nope, we are saying "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" (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) > > > , or something generated at the bytecode level from otherwise >>> available sources. >>> >>> It's been discussed so many times here by people trying to have an >>> >>>> alternative solution blessed. There are other hackish ways to >>>> work around this, but you will then run into other issues. For >>>> sure. >>>> >>>> >>> Been there, done that, can show the bite marks. Even got it working >>> so that mvn install would do The Right Thing, but m2e's Workspace >>> Resolution wouldn't recognize the jar, so the toolchain was still >>> incomplete. (I have been unable to resolve that problem, not even >>> with the help of the m2e-users list. Dunno where to take it from >>> there, so I dropped it and am living with an even more hacky >>> solution.) >>> >> >> 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" Please re-read and may the light of enlightenment shine upon you. > > 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. > An MRM changes nothing about that, so no pain is gone. (An MRM would help > with other tasks, of course.) > > Case in point: lwjgl. > It was not mavenized until 2.8.0, so all older and some newver > mavenizations listed on Central are binary-only, just a pom and a jar. > The sgine and philcali variants put the version number in the artifactId > - not quite what artifactId is supposed to carry, and I suspect that isn't > going to play nice with all usages. > The projectdarkstar variant is even worse - it carries a version number > of "2.0rc2", which refers to the version of projectdarkstar, not to the > lwjgl version. Downloading the artifacts doesn't reveal any useful version > number information either, the jars weren't built with anything useful in > the manifests. That's essentially unusable - use that as a dependency, hit > a bug, and you don't even know against which version of LWJGL to report > that bug. > > If these artifacts were created using install-file, then your consistent > recommendation of using install-file has been promoting bad practices. > The fact that people keep trying to work around install-file is not > necessarily an indication that everybody is dumb. It could be that Maven is > doing things in an unintuitive manner here. > > > Drink the kook-aid, it tastes great >> > > 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... You should look up the origin of the phrase "drink the kool-aid" > > Please, please, please stop using them. > Using Maven, and how to best do that, is a technical issue. > Religious argumentation patterns may be a good fit for religion and for > vi-vs-emacs crusades, but they are hardly appropriate for technical matters. > > Regards, > Jo > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
