maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz ...@durchholz.org>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 08:30:22 GMT
Am 30.01.2013 00:22, schrieb Stephen Connolly:
> On 29 January 2013 22:22, Joachim Durchholz <jo@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.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message