From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FibvQ-0007AY-JB for garchives@archives.gentoo.org; Tue, 23 May 2006 18:48:13 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4NIlimE022115; Tue, 23 May 2006 18:47:44 GMT Received: from banta-im.com (roy-rogers.nfic.com [208.231.230.100]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4NIlh09028117 for ; Tue, 23 May 2006 18:47:44 GMT Received: from by banta-im.com (8.9.3/8.9.3) with ESMTP id OAA28173; Tue, 23 May 2006 14:47:41 -0400 (EDT) Message-ID: <447358CD.2040507@gentoo.org> Date: Tue, 23 May 2006 14:47:41 -0400 From: Joshua Nichols User-Agent: Thunderbird 1.5.0.2 (X11/20060510) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 To: Vincent Schut , gentoo-java Subject: Re: [gentoo-java] java 5 classpath policy? References: <4472D13B.5030002@sarvision.nl> In-Reply-To: <4472D13B.5030002@sarvision.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archives-Salt: 6e04cc4b-e1fc-448a-a01d-213c7065ba81 X-Archives-Hash: 3c90ac929b803b61ada4e0fd8d1dabbe Vincent Schut wrote: > Hi all, > > when using java-config-2 from migration-overlay, it says 'deprecated' > for all classpath related functions. I tried to find some more info on > this, but couldn't find it. Maybe someone here can elaborate a bit more > on how to work with java classpath (system and user) in the new gentoo > java system? E.g. if I want to have some packages in my classpath, how > would I do that using the new system? And how is this working > together/conflicting with the current (old) items in /etc/env.d/ ? > > Cheers, > Vincent. > Setting a user and system wide classpath is deprecated because it can cause several issues. For example, say you put the classes from foo-2.0 on your classpath. Then you emerge something that uses foo-1.0. This would because foo would be slotted. However, when the build takes place, foo-2.0 could be on the classpath before foo-1.0. It may have the same classnames and whatnot, but different API. The differences between the APIs could then cause the build to fail. Similarly, this scenario may also occur while running an application. foo-1.0 might be expected, but foo-2.0 is on the classpath first... so it may be missing methods, or have different behavior, and so on. As for what to do instead of setting the classpath, it depends on what you're trying to do. If you have an application that needs a certain thing on the classpath, it is best to have a launcher script which sets the right CLASSPATH. If you're building something that needs a particular library, you should make the something be explicitly aware of what it needs. In ant, this could mean having a lib directory with all the jars (or symlinks to them), then you create a that all your and 's use. This would really be dependent on how you're building your project. This problem, and workarounds for it, are in the updated user documentation (https://svn.gentooexperimental.org/svn/java/migration/docs/java-user.html). Hope this clarifies, Josh -- gentoo-java@gentoo.org mailing list