maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 15:14:45 GMT
You are arguing with the guys who wrote Maven and are responsible for 
maintaining it.
They are giving you good advice about how to use it properly.

Why not try it their way for a week and see if it solves your problems.

Stephen has tried to give you concrete reasons why your way will lead to 
a constant battle.

I can only tell you that our team was once where you are - starting out, 
learning "the Maven way" without a repo.
Once we got the repo, a lot of good things happened in terms of our 
understanding of the Maven way, our ability to deal with third party 
jars and our ability to manage projects in a sensible and efficient way.

I have also seen a lot of new people come in and have trouble getting 
It leads to a lot of traffic before they get rid of the ideas that once 
drove their builds and conformed to the Maven way of doing things.
Frequently it is an Ant mindset that slows adoption and sometimes it is 
a homemade build methodology.


On 30/01/2013 3:30 AM, Joachim Durchholz wrote:
> Am 30.01.2013 00:22, schrieb Stephen Connolly:
>> On 29 January 2013 22:22, Joachim Durchholz <> 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 
> 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.
>> 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:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message