Am 30.01.2013 00:22, schrieb Stephen Connolly:
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...
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.
The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
stable yet), 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.
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?
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.
> 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'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.
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: [email protected]
For additional commands, e-mail: [email protected]
