Testing the maven build system: Symlink error on duplicate inputs

Testing the maven build system: Symlink error on duplicate inputs

[Björn Höfling]

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

Hi Julien,
Hi Guix,

thanks for adding the maven-build-system to Guix! This week I found the
time to look over it and tested it. It works great!

First I head a problem with symlinks when I tried out your example from
your git:


(define-public maven-test
+  (let ((commit "775960a985785913fb85428979d253c0b0e1d774")
+        (version "1.0-SNAPSHOT")
+        (revision "0"))
+    (package
+      (name "maven-test")
+      (version (git-version version revision commit))
+      (source (origin
+                (method git-fetch)
+                (uri (git-reference
+                      (url "https://framagit.org/tyreunom/maven-example-project")
+                      (commit commit)))
+                (file-name (git-file-name name version))
+                (sha256
+                 (base32
+                  "056p1kc4dpdp8rzxrbp9y0z278hjzpqkrjq63wgcyi0ns5jbc5nv"))))
+      (build-system maven-build-system)
+      (native-inputs
+       `(("maven-resources-plugin" ,maven-resources-plugin)
+         ("maven-compiler-plugin" ,maven-compiler-plugin)
+         ("maven-surefire-plugin" ,maven-surefire-plugin)
+         ("maven-jar-plugin" ,maven-jar-plugin)
+         ("maven-install-plugin" ,maven-install-plugin)
+         ("java-surefire-junit4" ,java-surefire-junit4)))
+      (home-page "")
+      (synopsis "")
+      (description "")
+      ;; Note: this package is generated automatically by maven, which is under asl2.0
+      (license license:asl2.0))))

It failed with 

I would symlink: "/gnu/store/p92knvjyvmg0krb7hlkj4gj8yf64y1r5-maven-resources-plugin-3.1.0/lib/m2/./org/apache/maven/plugins/maven-resources-plugin/3.1.0/maven-resources-plugin-3.1.0.jar" --> "/tmp/guix-build-maven-test-1.0-SNAPSHOT-0.775960a.drv-0/source/build-home/.m2/repository/./org/apache/maven/plugins/maven-resources-plugin/3.1.0/maven-resources-plugin-3.1.0.jar".
Backtrace:
          10 (primitive-load "/gnu/store/icabl1p2m3xf83hkanpkgzk0mkz?")
In ice-9/eval.scm:
   191:35  9 (_ _)
In guix/build/gnu-build-system.scm:
    838:2  8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16  6 (every1 #<procedure 7ffff4b4c5a0 at guix/build/gnu-bui?> ?)
In guix/build/gnu-build-system.scm:
   847:30  5 (_ _)
In guix/build/maven-build-system.scm:
     55:4  4 (configure #:inputs _)
In ice-9/boot-9.scm:
   260:13  3 (for-each #<procedure 7ffff522cbb8 at guix/build/maven?> ?)
   260:13  2 (for-each #<procedure 7ffff4fc9020 at guix/build/maven?> ?)
In unknown file:
           1 (symlink "/gnu/store/p92knvjyvmg0krb7hlkj4gj8yf64y1r5-?" ?)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure symlink: File exists

Then I noticed that the configure phase has duplicate inputs and that
lead to the failure. After removing all native-inputs from the example,
I was able to successfully build this Hello-World example.

Would that maybe cause real problems when the same two inputs come from
different dependencies in real-world examples?

I quickly tried to find a real-world problem to play with like slf4j or
Apache Commons, but all had either direct dependencies or
plugin-dependencies.

Does someone have plans to add real-world packages that make use of the
maven-build-system? Next, an automated importer with
dependency-resolution would be nice :-)

Thanks Julien for working on this,

Björn


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Testing the maven build system: Symlink error on duplicate inputs

[Julien Lepiller]

Le 20 septembre 2020 04:55:55 GMT-04:00, "Björn Höfling" <bjoern.hoefling@bjoernhoefling.de> a écrit :
>Hi Julien,
>Hi Guix,
>
>thanks for adding the maven-build-system to Guix! This week I found the
>time to look over it and tested it. It works great!
>
>First I head a problem with symlinks when I tried out your example from
>your git:
>
> […]
>
>Then I noticed that the configure phase has duplicate inputs and that
>lead to the failure. After removing all native-inputs from the example,
>I was able to successfully build this Hello-World example.

Yes, that package was made for a slightly different version of tge build systen than what I pushed, so it's not too surprising that it doesn't work as-is :)

>
>Would that maybe cause real problems when the same two inputs come from
>different dependencies in real-world examples?
>
>I quickly tried to find a real-world problem to play with like slf4j or
>Apache Commons, but all had either direct dependencies or
>plugin-dependencies.
>
>Does someone have plans to add real-world packages that make use of the
>maven-build-system? Next, an automated importer with
>dependency-resolution would be nice :-)

The issue with the importer is that maven doesn't record source information. We could have dependency resolution, but the resulting packages will lack any source (and for most packages also homepage and description).

One thing we have to decide on is what to do with maven build dependencies. Currently, things like test dependencies of dependencies are in the graph below maven, which means we have a lot of packages that cannot use the maven-build-system.

There are two possibilities: we can change the bootstrap path to maven to be minimal and only include runtime dependencies, and eventually rebuild maven with the maven-build-system. The other possibility is to keep it as is, and convert packages to install to lib/m2 as needed.

I tend to prefer the first solution, but that's also a lot of work. Our current maven package has bugs that are probably due to the way we build it (it doesn't honor user config, the build and test targets are mixed together, so are dependencies…). Building a proper maven with a minimal maven could help ensure it's built in the intended way, so these bugs could go away.

wdyt?

>
>Thanks Julien for working on this,
>
>Björn

Thanks for your interest :)

Re: Testing the maven build system: Symlink error on duplicate inputs

[Björn Höfling]

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

On Sun, 20 Sep 2020 07:35:44 -0400
Julien Lepiller <julien@lepiller.eu> wrote:

> >Does someone have plans to add real-world packages that make use of
> >the maven-build-system? Next, an automated importer with
> >dependency-resolution would be nice :-)  
> 
> The issue with the importer is that maven doesn't record source
> information. We could have dependency resolution, but the resulting
> packages will lack any source (and for most packages also homepage
> and description).
> 
> One thing we have to decide on is what to do with maven build
> dependencies. Currently, things like test dependencies of
> dependencies are in the graph below maven, which means we have a lot
> of packages that cannot use the maven-build-system.
> 
> There are two possibilities: we can change the bootstrap path to
> maven to be minimal and only include runtime dependencies, and
> eventually rebuild maven with the maven-build-system. The other
> possibility is to keep it as is, and convert packages to install to
> lib/m2 as needed.
> 
> I tend to prefer the first solution, but that's also a lot of work.
> Our current maven package has bugs that are probably due to the way
> we build it (it doesn't honor user config, the build and test targets
> are mixed together, so are dependencies…). Building a proper maven
> with a minimal maven could help ensure it's built in the intended
> way, so these bugs could go away.
> 
> wdyt?

I think the former is much more work but cleaner and would worth it.

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]