From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JENRE-00033n-5G for garchives@archives.gentoo.org; Mon, 14 Jan 2008 11:25:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 37F50E01BE; Mon, 14 Jan 2008 11:25:07 +0000 (UTC) Received: from smtp11.ihug.co.nz (smtp11.ihug.co.nz [203.109.136.111]) by pigeon.gentoo.org (Postfix) with ESMTP id E5283E01BE for ; Mon, 14 Jan 2008 11:25:06 +0000 (UTC) Received: from cust.filter2.content.ihug.net.nz (smtp.mailfilter2.ihug.co.nz) [10.80.50.2] by smtp11.ihug.co.nz with esmtp (Exim 4.60 #1 (Debian); Ihug conf #216) id 1JENRA-00032O-UZ; Tue, 15 Jan 2008 00:25:04 +1300 Ironport-Content-Filter: send-to-smtp Received: from 203-109-169-74.dsl.dyn.ihug.co.nz (HELO [10.1.1.3]) ([203.109.169.74]) by smtp.mailfilter2.ihug.co.nz with ESMTP; 15 Jan 2008 00:24:55 +1300 Message-ID: <478B4663.5050608@gentoo.org> Date: Tue, 15 Jan 2008 00:24:19 +1300 From: Alistair Bush User-Agent: Thunderbird 2.0.0.9 (X11/20071118) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@lists.gentoo.org MIME-Version: 1.0 To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] Virtual troubles References: <4788F734.1020606@gentoo.org> <478B391E.3070509@gentoo.org> <478B421D.1090101@gentoo.org> In-Reply-To: <478B421D.1090101@gentoo.org> X-Enigmail-Version: 0.95.6 OpenPGP: url= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: d32e3168-2fa5-492c-ad99-7c0a3b7d9cf6 X-Archives-Hash: 03b7f816a89512714247e6b809853b3f Vlastimil Babka wrote: > Alistair Bush wrote: >> Have update java-config to (hopefully) do both :) > > Good :) > >> Basically this means that if package is to be suitable for >> java-virtualizing then it must provide a jar that is similarly (or >> more exactly 'exactly') named as every other providers ${API}.jar >> >> javamail -> mail.jar >> servlet-api -> serlvetapi.jar jsp.jar >> grandma's special recipe -> gsr.jar > > OK. Perhaps the name of the 'special' jar should be declared as variable > in the virtual's ebuild and recorded in virtual's file? Are there any > uses for this besides a potential java-check-environment check? :) > Perhaps a 'java-pkg_getjars --virtual' would automatically give you this > jar only? But then it wouldn't be really getjarS, probably even more > confusing than now. So maybe not getjars, but a 'java-pkg_getjar > --virtual javamail' would let you omit the jarname. So --virtual would give the API jar file. Mmmm... interesting suggestion > > And what about virtual provided by the VM, which jar will I get? rt.jar? virtuals providing vms currently have 2 variables, one a list of providers, the other is a relative path from ${JAVA_HOME}. therefore combining a vm's JAVA_HOME with PROVIDER_JAR to form the classpath. Therefore the only requirement is that the jar is named the same across vm instances. (it should be noted that currently we support jar, not jars) > > Caster > -- gentoo-java@lists.gentoo.org mailing list