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 BF36AEE75 for ; Mon, 4 Feb 2013 12:58:34 +0000 (UTC) Received: (qmail 38112 invoked by uid 500); 4 Feb 2013 12:58:32 -0000 Delivered-To: apmail-maven-users-archive@maven.apache.org Received: (qmail 37687 invoked by uid 500); 4 Feb 2013 12:58:27 -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 37639 invoked by uid 99); 4 Feb 2013 12:58:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2013 12:58:26 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.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; Mon, 04 Feb 2013 12:58:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.artifact-software.com (Postfix) with ESMTP id F29E8FEC050 for ; Mon, 4 Feb 2013 07:57:58 -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 Wdk9WnQ-kepe for ; Mon, 4 Feb 2013 07:57:50 -0500 (EST) Received: from [192.168.3.170] (unknown [192.168.3.170]) by smtp.artifact-software.com (Postfix) with ESMTP id 9773AFEC04F for ; Mon, 4 Feb 2013 07:57:50 -0500 (EST) Message-ID: <510FB04A.4000008@artifact-software.com> Date: Mon, 04 Feb 2013 07:57:46 -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> <510839D6.3020409@artifact-software.com> <510851FA.7000403@durchholz.org> <5108E4A2.7000808@durchholz.org> <510F5BE0.2010309@durchholz.org> In-Reply-To: <510F5BE0.2010309@durchholz.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org MRM would help if your company blocked access to the internet. You go to your favourite cyber-caf�. Download the jars. Bring them to the office and put them in your MRM and they would be good for everyone until you wanted to change version. You could also get the indulgence of your system manager to either do the download for you or give you a one-time free pass to the internet for 15 minutes to let you get your downloads. Good to see that you are making good progress with Stephen. Ron On 04/02/2013 1:57 AM, Joachim Durchholz wrote: > Am 30.01.2013 10:44, schrieb Stephen Connolly: >> First off, I am assuming (always a danger of making an ass of you and >> me) >> that we have a multi-module project. > > No multi-module project here, just dependencies (and a parent pom to > capture configuration analogies). > >> I would create a pom.xml for the artifact that I want to use. This >> pom.xml >> will have to correctly identify the runtime dependencies of the >> artifact I >> am providing, so tooling is not really going to help, the artifact will >> have to be hand written due to the nature of these things. > > ? > Let's stick with the assumption that the external coordinate provides > a stable artifact. No need to create anything. > >> [I have experimented with using bytecode analysis to establish >> dependencies >> between a set of .jar files in a lib directory, and it can give you a >> good >> starting point, but too often it gives dependencies which should be >> optional, or misses dependencies that are referenced via reflection. The >> amount of times it has been in error is > 20% in my experience, and that >> error rate is unacceptable for general guidance] > > Agreed, finding dependencies needs to remain mostly manual and cannot > be solved automatically. > Those 80% information that can be extracted automatically are provided > by Tattletale, so no extra tooling for Maven would be required. Since > extraction can't be made part of the Maven workflow, an external tool > is just fine. > >> So you have to write the pom.xml by hand. > > Sure. I'm routinely writing poms by hand anyway; the pom generators in > m2e haven't been helpful for me (archetype selection is useless if you > know the archetypes even less than you know the pom structure). > >> It will look something like this >> >> >> 4.0.0 >> com.yourcompany.thirdparty >> third-party-artifact >> subversion-revision >> >> ... other details as you see fit ... >> >> >> ... list these ... >> >> >> >> >> >> >> org.codehaus.mojo >> wagon-maven-plugin >> 1.0-beta-4 >> >> >> package >> >> download-single >> >> >> some remote url >> third-party-artifact.jar@ >> ${project.version} >> >> ${project.build.outputDirectory}/${project.build.finalName}.jar >> >> >> >> >> >> >> >> >> > > Ah. I had overlooked Wagon as another way to skin that cat. > > Here's my take ("foo" is a stand-in for the external project's name): > > > maven-scm-plugin > > > svn-import-bundled-lwjl > generate-sources > > checkout > update > > > > ${foo.svn.url}/${foo.svn.path} > > > > ${foo.svn.versionType} > ${foo.svn.version} > > ${foo.svn.dir} > ${proj.svn.dir} > > > > > > com.github.goldin > copy-maven-plugin > 0.2.5 > > > copy-jar > package > > copy > > > > ${proj.svn.dir}/${proj.svn.jar} > ${project.build.directory} > > ${project.build.finalName}.jar > > true > true > > > > > > > This works as expected, unfortunately m2e doesn't know that > copy-maven-plugin replaced the jar, so workspace discovery fails. > Which isn't a Maven problem but something to take to the m2e-users list. > > I can try whether Wagon works better in m2e. > >> Now that pom.xml implicitly defines the location of the artifact, though >> you need to read the pom to find out. > > As opposed to looking at the jar's file name directly? > True. That's why I'm renaming the jar in the copy-maven-plugin > configuration via > ${project.build.finalName}.jar > The pom needs to carry an explicit version number. I'm taking it > manually from the download location; it's an SVN site, so I could be > saying > 3.0-SNAPSHOT > or > 3.0.rev4711 > depending on whether I'm pulling from upstream snapshots (and don't > care about stability anyway, yet) or from a fixed upstream revision > and don't want to rely on their tagging. > If I can rely on their tagging, I can set proj. > > > Your project will be a simple >> "check-out and build" assuming they are not behind a corporate proxy >> that >> prevents downloading .jar files from random websites... > > I wouldn't be able to download the jar manually then, so the MRM route > wouldn't help... MRM would help. You go to your favourite cyber-caf�. Download the jars. Bring them to the office and put them in your MRM and they would be good for everyone until you wanted to change version. > > > in which case they >> will need to get an exception for all of them to access that website and >> they will curse you for not just sticking it in a MRM which they at >> least >> got the corporate IT guys to grant an exception to... > > ... and this scenario would be irrelevant then. > >> to install that pom... the pom would probably look mostly the same, >> except >> you would list the origin of the file in the section, e.g. >> >> >> 4.0.0 >> com.yourcompany.thirdparty >> third-party-artifact >> subversion-revision >> >> >> http://some-remote-url/... >> >> >> ... other details as you see fit ... >> >> >> ... list these ... >> >> >> >> >> And here's the best bit about that way... when you write a pom.xml like >> that, it's just perfect for submitting to central in a bundle upload... >> which means that others can receive the benefit of your hard work >> determining the list of dependencies. > > I'll have to think about that one a bit more. > >> Now if you don't provide a pom file to install:install-file or >> deploy:deploy-file those plugins will generate a crappy stub for >> you... we >> need to put some pom there, and the stub will not break things, so it >> should be seen as a stop-gap until you determine the correct >> >> >> Now if you are complaining that the above is too much work, well the >> only >> real work I see is determining the list of dependencies... > > As I said, the dependencies can't be determined automatically. > BTW it's just occurring to me that you can't determine them > automatically no matter what, whether the jar comes as a binary or as > a standard Maven project. You just rely on whoever is providing the > pom to properly specify all the dependencies. > > --------------------------------------------------------------------- > 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