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.
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.
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).
, 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.
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.
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.
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: [email protected]
For additional commands, e-mail: [email protected]
