From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: store reference detection (was Re: JARs and reference scanning) Date: Fri, 12 May 2017 10:21:53 +0200 Message-ID: <87k25mscwu.fsf@elephly.net> References: <87a876pwaq.fsf@gmail.com> <8760hr7mwl.fsf@gmail.com> <20170426.135333.1620868924745053745.post@thomasdanckaert.be> <87fugu6jzg.fsf@gnu.org> <59022E86.1020709@crazy-compilers.com> <8760hjig4r.fsf@gnu.org> <590F179B.4060306@crazy-compilers.com> <87zieotnzr.fsf@gmail.com> <87vapbkeua.fsf@elephly.net> <87inl7n5tt.fsf@gmail.com> <87a86jy6pk.fsf@elephly.net> <87mvai36r9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d95pw-0000Kh-NB for guix-devel@gnu.org; Fri, 12 May 2017 04:22:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d95pr-0005vy-UY for guix-devel@gnu.org; Fri, 12 May 2017 04:22:08 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21076) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d95pr-0005ud-N3 for guix-devel@gnu.org; Fri, 12 May 2017 04:22:03 -0400 In-reply-to: <87mvai36r9.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org Chris Marusich writes: > Ricardo Wurmus writes: > >> Chris Marusich writes: >> >>>> Jar files can be told to import classes from another Jar by adding it to >>>> the “Class-Path” field of the Jar’s manifest. >>>> >>>> Here’s an example: >>>> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html >>> >>> I didn't know this! That's awesome; it might be just what we need. >> […] >> >> Thanks for testing this! >> >> One limitation appears to be that this only works for applications, not >> for libraries. > > In what way does this not work for libraries? I'm not criticizing you; > I'm genuinely curious. To ask this question another way: how would a > solution that "works for libraries" behave, exactly? I'm not sure what > the phrase "it works for libraries" might mean, since I suspect its > meaning varies depending on what one is trying to accomplish. What I mean is that it may not be transitive. Let’s say “java-foo” depends on “java-hamcrest-core”, so we record the absolute path to the hamcrest core jar in the Class-Path field of the manifest. Now let’s also say that the application “java-bar” depends on “java-foo”, but not directly on “java-hamcrest-core”. Now what I wonder about is whether we would need to record the paths to the jars of both “java-foo” *and* “java-hamcrest-core” in the Class-Path field of the manifest for “java-bar”, or if it would be sufficient to record “java-foo". Would Java respect the Class-Path for all dependencies recursively within their scope? Is this ‘lexically scoped’ (i.e. the specified class path will apply only for the jar on whose manifest it was specified) or will Java traverse all Class-Path fields and create one concatenated big class path that is used to resolve all classes? In the latter case there could be conflicts when one node in the graph demands *one* version of a jar and some other node demands the classes from a *different* jar to be used. Maybe none of this is implemented and all Class-Path does is tell the current *application* where to get its dependencies; in that case the Class-Path field would just be an alternative to using a shell wrapper that sets the CLASSPATH environment variable. Does this make it a little clearer? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net