Return-Path: X-Original-To: apmail-maven-users-archive@www.apache.org Delivered-To: apmail-maven-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C43B1E20B for ; Tue, 29 Jan 2013 21:07:10 +0000 (UTC) Received: (qmail 31362 invoked by uid 500); 29 Jan 2013 21:07:08 -0000 Delivered-To: apmail-maven-users-archive@maven.apache.org Received: (qmail 31285 invoked by uid 500); 29 Jan 2013 21:07:08 -0000 Mailing-List: contact users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Users List" Reply-To: "Maven Users List" Delivered-To: mailing list users@maven.apache.org Received: (qmail 31277 invoked by uid 99); 29 Jan 2013 21:07:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 21:07:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [24.37.79.202] (HELO smtp.artifact-software.com) (24.37.79.202) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 21:07:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.artifact-software.com (Postfix) with ESMTP id 2D4B0FEC053 for ; Tue, 29 Jan 2013 16:06:39 -0500 (EST) X-Virus-Scanned: amavisd-new at artifact-software.com Received: from smtp.artifact-software.com ([127.0.0.1]) by localhost (smtp.artifact-software.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbPNixA4H5AF for ; Tue, 29 Jan 2013 16:06:32 -0500 (EST) Received: from [192.168.3.170] (unknown [192.168.3.170]) by smtp.artifact-software.com (Postfix) with ESMTP id 3C0726A7A70 for ; Tue, 29 Jan 2013 16:06:32 -0500 (EST) Message-ID: <510839D6.3020409@artifact-software.com> Date: Tue, 29 Jan 2013 16:06:30 -0500 From: Ron Wheeler Reply-To: rwheeler@artifact-software.com Organization: Artifact Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: users@maven.apache.org Subject: Re: Jar file not in maven References: <5108273D.3000806@durchholz.org> In-Reply-To: <5108273D.3000806@durchholz.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 29/01/2013 2:47 PM, 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, or something generated > at the bytecode level from otherwise available sources. > Your use case is that you will give them your sources and POMs but not access to your repo? Fair enough. In that case, you will simply have to tell them where to get the files and tell them that they have to be uploaded into their Maven repo with the same GAV that you used in your POM. No one would have trouble with these instructions. Otherwise you are going to have to give them some pretty bizarre instructions about loading stuff onto each developer's workstation and reloading them anytime they blow away their local cache. Maven users are going to scratch their heads at that set of instructions and ask "Why not just download what I need once and put it with the rest of my external jars like a normal Maven project?" They will eventually figure out the right way to do it and probably send you a nice note about how you should have used a Maven repo. If they are really nice, they will fix your instructions for the next person and post it on their blog. There are a few projects that do not distribute POM files with their jars and some that do but do not publish to Maven Central. It is just a fact of life that you have to load some things manually into your repo and some things have to be given a "fake" POM by the repo so you can reference them in a repeatable way. >> 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.) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > For additional commands, e-mail: users-help@maven.apache.org > > -- Ron Wheeler President Artifact Software Inc email: rwheeler@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For additional commands, e-mail: users-help@maven.apache.org