[bug#29896] [PATCH core-updates] gnu: java-asm: Update to 6.0.

[bug#29896] [PATCH core-updates] gnu: java-asm: Update to 6.0.

[Gábor Boskovits]

* gnu/packages/java.scm (java-asm): Update to 6.0.
[inputs]: Add java-aqute-bndlib, java-aqute-libg. (New dependencies)
[arguments]: Adjust make-flags, so that the build does not complain about unset properties.
---
 gnu/packages/java.scm | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 41f9af87e..8a244328f 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -2663,15 +2663,18 @@ archives (jar).")
 (define-public java-asm
   (package
     (name "java-asm")
-    (version "5.2")
+    (version "6.0")
     (source (origin
               (method url-fetch)
               (uri (string-append "http://download.forge.ow2.org/asm/"
                                   "asm-" version ".tar.gz"))
               (sha256
                (base32
-                "0kxvmv5275rnjl7jv0442k3wjnq03ngkb7sghs78avf45pzm4qgr"))))
+                "115l5pqblirdkmzi32dxx7gbcm4jy0s14y5wircr6h8jdr9aix00"))))
     (build-system ant-build-system)
+    (inputs
+     `(("java-aqute-bndlib" ,java-aqute-bndlib)
+       ("java-aqute-libg" ,java-aqute-libg)))
     (arguments
      `(#:build-target "compile"
        ;; The tests require an old version of Janino, which no longer compiles
@@ -2679,7 +2682,8 @@ archives (jar).")
        #:tests? #f
        ;; We don't need these extra ant tasks, but the build system asks us to
        ;; provide a path anyway.
-       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo"))
+       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo")
+                          (string-append "-Dbiz.aQute.bnd.path=" (assoc-ref %build-inputs "java-aqute-bndlib")))
        #:phases
        (modify-phases %standard-phases
          (add-before 'install 'build-jars
-- 
2.15.1

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Gábor Boskovits]

* gnu/packages/java.scm (java-asm): Update to 6.0.
[inputs]: Add java-aqute-bndlib, java-aqute-libg. (New dependencies)
[arguments]: Adjust make-flags, so that the build does not complain about unset properties.
---
 gnu/packages/java.scm | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 41f9af87e..8579f7c8b 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -2663,15 +2663,18 @@ archives (jar).")
 (define-public java-asm
   (package
     (name "java-asm")
-    (version "5.2")
+    (version "6.0")
     (source (origin
               (method url-fetch)
               (uri (string-append "http://download.forge.ow2.org/asm/"
                                   "asm-" version ".tar.gz"))
               (sha256
                (base32
-                "0kxvmv5275rnjl7jv0442k3wjnq03ngkb7sghs78avf45pzm4qgr"))))
+                "115l5pqblirdkmzi32dxx7gbcm4jy0s14y5wircr6h8jdr9aix00"))))
     (build-system ant-build-system)
+    (inputs
+     `(("java-aqute-bndlib" ,java-aqute-bndlib)
+       ("java-aqute-libg" ,java-aqute-libg)))
     (arguments
      `(#:build-target "compile"
        ;; The tests require an old version of Janino, which no longer compiles
@@ -2679,7 +2682,9 @@ archives (jar).")
        #:tests? #f
        ;; We don't need these extra ant tasks, but the build system asks us to
        ;; provide a path anyway.
-       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo"))
+       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo")
+                          (string-append "-Dbiz.aQute.bnd.path="
+                                         (assoc-ref %build-inputs "java-aqute-bndlib")))
        #:phases
        (modify-phases %standard-phases
          (add-before 'install 'build-jars
-- 
2.15.1

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 109 bytes --]

The second version of this patch passes guix lint. The first one contains a
line too long.
Sorry about that.

[-- Attachment #2: Type: text/html, Size: 140 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Gábor Boskovits <boskovits@gmail.com> writes:

> +    (inputs
> +     `(("java-aqute-bndlib" ,java-aqute-bndlib)
> +       ("java-aqute-libg" ,java-aqute-libg)))
>      (arguments
>       `(#:build-target "compile"
>         ;; The tests require an old version of Janino, which no longer compiles
> @@ -2679,7 +2682,9 @@ archives (jar).")
>         #:tests? #f
>         ;; We don't need these extra ant tasks, but the build system asks us to
>         ;; provide a path anyway.
> -       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo"))
> +       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo")
> +                          (string-append "-Dbiz.aQute.bnd.path="
> +                                         (assoc-ref %build-inputs "java-aqute-bndlib")))

Even though we added some inputs, there appear to be no retained
references in the output, as shown by this command:

  guix gc --referrers $(./pre-inst-env guix build java-asm)

Is this expected?  At first blush, this seems reasonable only if
java-aqute-bndlib and java-aqute-libg are not required at runtime.
Perhaps Ricardo knows more, since he has more experience working with
the ant-build-system.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

Actually I did forget to check if it is used runtime.
It is used to build and OSGi bundle.
At first I tried to fake the dependency like for the ant tasks,
but I got compilation errors.

2018-01-19 7:35 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
> > +    (inputs
> > +     `(("java-aqute-bndlib" ,java-aqute-bndlib)
> > +       ("java-aqute-libg" ,java-aqute-libg)))
> >      (arguments
> >       `(#:build-target "compile"
> >         ;; The tests require an old version of Janino, which no longer
> compiles
> > @@ -2679,7 +2682,9 @@ archives (jar).")
> >         #:tests? #f
> >         ;; We don't need these extra ant tasks, but the build system
> asks us to
> >         ;; provide a path anyway.
> > -       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=
> foo"))
> > +       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=
> foo")
> > +                          (string-append "-Dbiz.aQute.bnd.path="
> > +                                         (assoc-ref %build-inputs
> "java-aqute-bndlib")))
>
> Even though we added some inputs, there appear to be no retained
> references in the output, as shown by this command:
>
>   guix gc --referrers $(./pre-inst-env guix build java-asm)
>
> Is this expected?  At first blush, this seems reasonable only if
> java-aqute-bndlib and java-aqute-libg are not required at runtime.
> Perhaps Ricardo knows more, since he has more experience working with
> the ant-build-system.
>
> --
> Chris
>

[-- Attachment #2: Type: text/html, Size: 2270 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

Gábor Boskovits <boskovits@gmail.com> writes:

> Actually I did forget to check if it is used runtime.
> It is used to build and OSGi bundle.
> At first I tried to fake the dependency like for the ant tasks,
> but I got compilation errors.

If the new input is also required at runtime, then I'm not sure this
package definition is correct.  I would normally expect a "runtime
dependency" to be either retained as a reference in the output, or
declared as a propagated-input (so that it gets installed alongside this
package when this package is installed into a profile).  Perhaps I am
missing some information here.

I'm hoping Ricardo can comment on how this is intended to work for Java
packages, since he originally added the ant-build-system.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
>> Actually I did forget to check if it is used runtime.
>> It is used to build and OSGi bundle.
>> At first I tried to fake the dependency like for the ant tasks,
>> but I got compilation errors.
>
> If the new input is also required at runtime, then I'm not sure this
> package definition is correct.  I would normally expect a "runtime
> dependency" to be either retained as a reference in the output, or
> declared as a propagated-input (so that it gets installed alongside this
> package when this package is installed into a profile).  Perhaps I am
> missing some information here.
>
> I'm hoping Ricardo can comment on how this is intended to work for Java
> packages, since he originally added the ant-build-system.

The jars that the ant-build-system generates are uncompressed and thus
allow the scanner to find embedded store references.  The problem seems
to be that references to other *jars* are not kept, because they are
never recorded anywhere.  That’s normal for Java, which looks for named
classes on the classpath, i.e. a list of jars.  It behaves very much
like Python and its PYTHONPATH in this regard.

The best we can do here is to propagate inputs.  The alternative is to
try to be smart and record the effective runtime classpath, but that’s
hard/impossible to get right.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote:
> Gábor Boskovits <boskovits@gmail.com> writes:
> 
> > +    (inputs
> > +     `(("java-aqute-bndlib" ,java-aqute-bndlib)
> > +       ("java-aqute-libg" ,java-aqute-libg)))
> >      (arguments
> >       `(#:build-target "compile"
> >         ;; The tests require an old version of Janino, which no longer compiles
> > @@ -2679,7 +2682,9 @@ archives (jar).")
> >         #:tests? #f
> >         ;; We don't need these extra ant tasks, but the build system asks us to
> >         ;; provide a path anyway.
> > -       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo"))
> > +       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo")
> > +                          (string-append "-Dbiz.aQute.bnd.path="
> > +                                         (assoc-ref %build-inputs "java-aqute-bndlib")))
> 
> Even though we added some inputs, there appear to be no retained
> references in the output, as shown by this command:
> 
>   guix gc --referrers $(./pre-inst-env guix build java-asm)

To check the retained references in the output [0], it's actually `guix
gc --references $(./pre-inst-env guix build ...)`.

[0] To clarify "retained references", they are literally occurences of
strings that begin with '/gnu/store/', then a Guix hash, then a hyphen,
and then a package name.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 3125 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote:
>> Even though we added some inputs, there appear to be no retained
>> references in the output, as shown by this command:
>> 
>>   guix gc --referrers $(./pre-inst-env guix build java-asm)
>
> To check the retained references in the output [0], it's actually `guix
> gc --references $(./pre-inst-env guix build ...)`.
>
> [0] To clarify "retained references", they are literally occurences of
> strings that begin with '/gnu/store/', then a Guix hash, then a hyphen,
> and then a package name.

You're right; this was a "thinko" on my part.  I meant to write
"--references" instead of "--referrers".  The output of the correct
command is still empty, so there are still no references.

Ricardo Wurmus <rekado@elephly.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> If the new input is also required at runtime, then I'm not sure this
>> package definition is correct.  I would normally expect a "runtime
>> dependency" to be either retained as a reference in the output, or
>> declared as a propagated-input (so that it gets installed alongside this
>> package when this package is installed into a profile).  Perhaps I am
>> missing some information here.
>>
>> I'm hoping Ricardo can comment on how this is intended to work for Java
>> packages, since he originally added the ant-build-system.
>
> The jars that the ant-build-system generates are uncompressed and thus
> allow the scanner to find embedded store references.  The problem seems
> to be that references to other *jars* are not kept, because they are
> never recorded anywhere.  That’s normal for Java, which looks for named
> classes on the classpath, i.e. a list of jars.  It behaves very much
> like Python and its PYTHONPATH in this regard.
>
> The best we can do here is to propagate inputs.  The alternative is to
> try to be smart and record the effective runtime classpath, but that’s
> hard/impossible to get right.

OK - thank you for the explanation!  In light of that information, I
think that in the case of a package that uses the ant-build-system (like
java-asm), if we know for sure that an input is required at runtime, we
should make it a propagated input.  The installed software still won't
work without additional work on the part of the user (e.g., the user
needs to set the CLASSPATH when invoking java, or use java's -cp
option), but for now at least making the input a propagated input will
ensure that it gets installed alongside the package which at runtime
requires it, which is better than nothing.

Here's an updated patch that makes this change.  In addition, I
discovered that (1) the build succeeds and produces the same JAR file
even when I removed java-aqute-libg as an input, so I've removed that,
and (2) the build succeeds and produces the same JAR file even when I
use a dummy value for the biz.aQute.bnd.path Ant property, so I did that
to make it clear that it wasn't important to the build.  What do you
think?

-- 
Chris

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-java-asm-Update-to-6.0.patch --]
[-- Type: text/x-patch, Size: 2321 bytes --]

From b7ab0f263338f54d3982b6d1cc91306f4691116a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= <boskovits@gmail.com>
Date: Sun, 7 Jan 2018 22:23:56 +0100
Subject: [PATCH] gnu: java-asm: Update to 6.0.

* gnu/packages/java.scm (java-asm): Update to 6.0.
[propagated-inputs]: Add java-aqute-bndlib (new dependency).
[arguments]: Adjust make-flags, so that the build does not complain about
unset properties.
---
 gnu/packages/java.scm | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index c04b45c53..38bfffaf5 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -2660,23 +2660,31 @@ archives (jar).")
 (define-public java-asm
   (package
     (name "java-asm")
-    (version "5.2")
+    (version "6.0")
     (source (origin
               (method url-fetch)
               (uri (string-append "http://download.forge.ow2.org/asm/"
                                   "asm-" version ".tar.gz"))
               (sha256
                (base32
-                "0kxvmv5275rnjl7jv0442k3wjnq03ngkb7sghs78avf45pzm4qgr"))))
+                "115l5pqblirdkmzi32dxx7gbcm4jy0s14y5wircr6h8jdr9aix00"))))
     (build-system ant-build-system)
+    (propagated-inputs
+     `(("java-aqute-bndlib" ,java-aqute-bndlib)))
     (arguments
      `(#:build-target "compile"
        ;; The tests require an old version of Janino, which no longer compiles
        ;; with the JDK7.
        #:tests? #f
-       ;; We don't need these extra ant tasks, but the build system asks us to
-       ;; provide a path anyway.
-       #:make-flags (list (string-append "-Dobjectweb.ant.tasks.path=foo"))
+       #:make-flags
+       (list
+        ;; We don't need these extra ant tasks, but the build system asks us to
+        ;; provide a path anyway.
+        "-Dobjectweb.ant.tasks.path=dummy-path"
+        ;; The java-aqute.bndlib JAR file will be put onto the classpath and
+        ;; used during the build automatically by ant-build-system, but
+        ;; java-asm's build.xml fails unless we provide something here.
+        "-Dbiz.aQute.bnd.path=dummy-path")
        #:phases
        (modify-phases %standard-phases
          (add-before 'install 'build-jars
-- 
2.15.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 3526 bytes --]

2018-01-20 8:50 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> Leo Famulari <leo@famulari.name> writes:
>
> > On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote:
> >> Even though we added some inputs, there appear to be no retained
> >> references in the output, as shown by this command:
> >>
> >>   guix gc --referrers $(./pre-inst-env guix build java-asm)
> >
> > To check the retained references in the output [0], it's actually `guix
> > gc --references $(./pre-inst-env guix build ...)`.
> >
> > [0] To clarify "retained references", they are literally occurences of
> > strings that begin with '/gnu/store/', then a Guix hash, then a hyphen,
> > and then a package name.
>
> You're right; this was a "thinko" on my part.  I meant to write
> "--references" instead of "--referrers".  The output of the correct
> command is still empty, so there are still no references.
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Chris Marusich <cmmarusich@gmail.com> writes:
> >
> >> If the new input is also required at runtime, then I'm not sure this
> >> package definition is correct.  I would normally expect a "runtime
> >> dependency" to be either retained as a reference in the output, or
> >> declared as a propagated-input (so that it gets installed alongside this
> >> package when this package is installed into a profile).  Perhaps I am
> >> missing some information here.
> >>
> >> I'm hoping Ricardo can comment on how this is intended to work for Java
> >> packages, since he originally added the ant-build-system.
> >
> > The jars that the ant-build-system generates are uncompressed and thus
> > allow the scanner to find embedded store references.  The problem seems
> > to be that references to other *jars* are not kept, because they are
> > never recorded anywhere.  That’s normal for Java, which looks for named
> > classes on the classpath, i.e. a list of jars.  It behaves very much
> > like Python and its PYTHONPATH in this regard.
> >
> > The best we can do here is to propagate inputs.  The alternative is to
> > try to be smart and record the effective runtime classpath, but that’s
> > hard/impossible to get right.
>
> OK - thank you for the explanation!  In light of that information, I
> think that in the case of a package that uses the ant-build-system (like
> java-asm), if we know for sure that an input is required at runtime, we
> should make it a propagated input.  The installed software still won't
> work without additional work on the part of the user (e.g., the user
> needs to set the CLASSPATH when invoking java, or use java's -cp
> option), but for now at least making the input a propagated input will
> ensure that it gets installed alongside the package which at runtime
> requires it, which is better than nothing.
>
> Here's an updated patch that makes this change.  In addition, I
> discovered that (1) the build succeeds and produces the same JAR file
> even when I removed java-aqute-libg as an input, so I've removed that,
> and (2) the build succeeds and produces the same JAR file even when I
> use a dummy value for the biz.aQute.bnd.path Ant property, so I did that
> to make it clear that it wasn't important to the build.  What do you
> think?
>
> I think this is ok. I also noticed, that a dummy value would do, but I had
no policy
at hand about what to do in this case.

Actually I am not sure, that bnd is used runtime. How could we check that?


> --
> Chris
>

[-- Attachment #2: Type: text/html, Size: 4678 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Julien Lepiller]

Le Sat, 20 Jan 2018 10:08:04 +0100,
Gábor Boskovits <boskovits@gmail.com> a écrit :

> 2018-01-20 8:50 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:
> 
> > Leo Famulari <leo@famulari.name> writes:
> >  
> > > On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote:  
> > >> Even though we added some inputs, there appear to be no retained
> > >> references in the output, as shown by this command:
> > >>
> > >>   guix gc --referrers $(./pre-inst-env guix build java-asm)  
> > >
> > > To check the retained references in the output [0], it's actually
> > > `guix gc --references $(./pre-inst-env guix build ...)`.
> > >
> > > [0] To clarify "retained references", they are literally
> > > occurences of strings that begin with '/gnu/store/', then a Guix
> > > hash, then a hyphen, and then a package name.  
> >
> > You're right; this was a "thinko" on my part.  I meant to write
> > "--references" instead of "--referrers".  The output of the correct
> > command is still empty, so there are still no references.
> >
> > Ricardo Wurmus <rekado@elephly.net> writes:
> >  
> > > Chris Marusich <cmmarusich@gmail.com> writes:
> > >  
> > >> If the new input is also required at runtime, then I'm not sure
> > >> this package definition is correct.  I would normally expect a
> > >> "runtime dependency" to be either retained as a reference in the
> > >> output, or declared as a propagated-input (so that it gets
> > >> installed alongside this package when this package is installed
> > >> into a profile).  Perhaps I am missing some information here.
> > >>
> > >> I'm hoping Ricardo can comment on how this is intended to work
> > >> for Java packages, since he originally added the
> > >> ant-build-system.  
> > >
> > > The jars that the ant-build-system generates are uncompressed and
> > > thus allow the scanner to find embedded store references.  The
> > > problem seems to be that references to other *jars* are not kept,
> > > because they are never recorded anywhere.  That’s normal for
> > > Java, which looks for named classes on the classpath, i.e. a list
> > > of jars.  It behaves very much like Python and its PYTHONPATH in
> > > this regard.
> > >
> > > The best we can do here is to propagate inputs.  The alternative
> > > is to try to be smart and record the effective runtime classpath,
> > > but that’s hard/impossible to get right.  
> >
> > OK - thank you for the explanation!  In light of that information, I
> > think that in the case of a package that uses the ant-build-system
> > (like java-asm), if we know for sure that an input is required at
> > runtime, we should make it a propagated input.  The installed
> > software still won't work without additional work on the part of
> > the user (e.g., the user needs to set the CLASSPATH when invoking
> > java, or use java's -cp option), but for now at least making the
> > input a propagated input will ensure that it gets installed
> > alongside the package which at runtime requires it, which is better
> > than nothing.
> >
> > Here's an updated patch that makes this change.  In addition, I
> > discovered that (1) the build succeeds and produces the same JAR
> > file even when I removed java-aqute-libg as an input, so I've
> > removed that, and (2) the build succeeds and produces the same JAR
> > file even when I use a dummy value for the biz.aQute.bnd.path Ant
> > property, so I did that to make it clear that it wasn't important
> > to the build.  What do you think?
> >
> > I think this is ok. I also noticed, that a dummy value would do,
> > but I had  
> no policy
> at hand about what to do in this case.
> 
> Actually I am not sure, that bnd is used runtime. How could we check
> that?

Try to run it when bnd is not in the CLASSPATH?

There's a method to get references to a dependency in java: you can put
it in the MANIFEST.MF file as:

Class-Path: /gnu/store/...

It's a space-separated list of jar files that have to be added to the
classpath. This could be done in a phase that runs just before the
build phase, like the phase that adds a Main-Class.

> 
> 
> > --
> > Chris
> >  

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> The installed software still won't
> work without additional work on the part of the user (e.g., the user
> needs to set the CLASSPATH when invoking java, or use java's -cp
> option), but for now at least making the input a propagated input will
> ensure that it gets installed alongside the package which at runtime
> requires it, which is better than nothing.

This can be fixed by adding a search path specification for CLASSPATH to
the icedtea packages.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#29896: [PATCH] gnu: java-asm: Update to 6.0.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Gábor Boskovits <boskovits@gmail.com> writes:

> Actually I am not sure, that bnd is used runtime. How could we check that?

The only class in the java-asm source code that uses bnd seems to be
ModuleInfoBndPlugin.java.  I checked by grepping for imports that
mentioned the string "bnd".  This class is declared public, and it is
included in the output JAR, so it is technically possible for code that
depends on java-asm to use this class (and therefore java-aqute-bndlib)
at runtime, even though there might also be code that depends on
java-asm that does not use this class at runtime.  So it seems
reasonable to make it a propagated-input.  The only downside is that
java-aqute-bndlib is 125% larger than java-asm (1.8 MiB compared to 0.8
MiB).

I've committed this patch as d0e9ded713e06790aad4992de7c26d075d18b86d,
with the changes we agreed upon.  I've also added a copyright line for
both you and me gnu/packages/java.scm.

Julien Lepiller <julien@lepiller.eu> writes:

> There's a method to get references to a dependency in java: you can put
> it in the MANIFEST.MF file as:
>
> Class-Path: /gnu/store/...
>
> It's a space-separated list of jar files that have to be added to the
> classpath. This could be done in a phase that runs just before the
> build phase, like the phase that adds a Main-Class.

We've considered using this feature, but I don't know if anybody
followed through and tried it out.  Your help would be welcome!  Prior
discussions can be found here:

https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00249.html
https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00019.html

If you want to discuss this further, please start a new thread on
guix-devel@gnu.org.

Ricardo Wurmus <rekado@elephly.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> The installed software still won't
>> work without additional work on the part of the user (e.g., the user
>> needs to set the CLASSPATH when invoking java, or use java's -cp
>> option), but for now at least making the input a propagated input will
>> ensure that it gets installed alongside the package which at runtime
>> requires it, which is better than nothing.
>
> This can be fixed by adding a search path specification for CLASSPATH to
> the icedtea packages.

I think that's a good idea!  I'll follow up with a separate patch later,
unless you beat me to it.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.

[Ricardo Wurmus]

> Julien Lepiller <julien@lepiller.eu> writes:
>
>> There's a method to get references to a dependency in java: you can put
>> it in the MANIFEST.MF file as:
>>
>> Class-Path: /gnu/store/...
>>
>> It's a space-separated list of jar files that have to be added to the
>> classpath. This could be done in a phase that runs just before the
>> build phase, like the phase that adds a Main-Class.
>
> We've considered using this feature, but I don't know if anybody
> followed through and tried it out.

It would only work for applications, not for libraries.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net