guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Julien Lepiller
Subject: Re: Testing the maven build system: Symlink error on duplicate inputs
Date: Sun, 20 Sep 2020 07:35:44 -0400
User-agent: K-9 Mail for Android


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 :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]