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 1JEMZd-0007W5-0E for garchives@archives.gentoo.org; Mon, 14 Jan 2008 10:29:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C77AE0114; Mon, 14 Jan 2008 10:28:25 +0000 (UTC) Received: from smtp3.ihug.co.nz (smtp3.ihug.co.nz [203.109.136.103]) by pigeon.gentoo.org (Postfix) with ESMTP id 06D2DE0114 for ; Mon, 14 Jan 2008 10:28:25 +0000 (UTC) Received: from cust.filter3.content.ihug.net.nz (smtp.mailfilter3.ihug.co.nz) [10.80.50.3] by smtp3.ihug.co.nz with esmtp (Exim 4.60 #1 (Debian); Ihug conf #192) id 1JEMYI-00086a-Gn; Mon, 14 Jan 2008 23:28:22 +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.mailfilter3.ihug.co.nz with ESMTP; 14 Jan 2008 23:28:19 +1300 Message-ID: <478B391E.3070509@gentoo.org> Date: Mon, 14 Jan 2008 23:27:42 +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> In-Reply-To: <4788F734.1020606@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: 6b835f19-e269-4cda-a1ca-e363179481a2 X-Archives-Hash: 80309c4bed7224d6562e480b87def133 Vlastimil Babka wrote: > Hi, > > Discovered some problems with virtuals today. :) > > First one is in the depend-java-query tool, which can't correctly parse > dependencies as =java-virtuals/servlet-api-2.3* - transforms to > "servlet-api-2.3*" which it can't find, and raises exception - see how > it ends up in bug 205453 :) So, only deps like > "~java-virtuals/servlet-api-2.3" work. Should be fixed, or we decide to > go with slot deps and start sticking EAPI=1 in our ebuilds? I'm not sure > it can even parse 'java-virtuals/servlet-api:2.3' in current version :) Have update java-config to (hopefully) do both :) java-config -p package:slot works at least (is a little dump tho as package:0 won't currently work) > > The other trouble I have is with eclass functions. It's confusing that > java-pkg_getjars() doesn't have --virtual parameter, but if you look > into what the parameter does, you realize it really doesn't need it. > Still, confusing :) > The worse trouble is with the functions that actually take the > parameter, java-pkg_jar-from $package $jar and java-pkg_getjar. By > passing --virtual, you say "I can't know what the particular provider's > jar names are, so depend on the whole package", but still you have to > pass an actual 'foo.jar' parameter. That's strange. What if there's new > provider with different jar name? What if the virtual is satisfied by > the VM itself? Suddenly you get an error, or am I wrong? Let me clarify this as "I can't know the name of any implementing jars (if they are separate) but I do know the name of the api as that is fixed" So basically sun-javamail and gnu-javamail implement (surprise surprise) the javamail api. sun-javamail has one jar (mail.jar, API and Implementation) gnu-javamail has 2 (mail.jar, the API and another, the actual implementation) so java-pkg_jarfrom --virtual javamail mail.jar will retrieve mail.jar without recording the dependency as just that jar (as we can't know whether they are separate or not) as the other functions don't record jar level deps the option is mute. 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 > > VB Sorry It has taken me time to reply, decided it was better to fix before explain. -- gentoo-java@lists.gentoo.org mailing list