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 Tue, 29 Jan 2013 22:22:55 GMT
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message