* Maven Build System Dependency Issue
@ 2022-02-08 15:27 Phil Beadling
2022-02-08 20:19 ` Julien Lepiller
0 siblings, 1 reply; 3+ messages in thread
From: Phil Beadling @ 2022-02-08 15:27 UTC (permalink / raw)
To: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 7375 bytes --]
Hi Guixers,
First let me say I'm a Maven novice, so it's possible I'm doing something
dumb on the Maven side of things.
I'm unable to make a bare-bones Maven project build in Guix.
This looks to be a problem with mismatched dependencies in Guix around
java-commons-codec.
I suggest what probably needs to be fixed upstream below (assuming my hunch
is correct!).
However I'm looking for advice on how to workaround this problem today to
get a basic Maven package building.
*My method:*
Following advice here:
https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Using an environment like so:
guix environment --ad-hoc maven
I create a new git repo and put this in the root (so pom.xml, etc, sit in
in the root of the repo)
mvn archetype:generate -DgroupId=com.quantile.app
-DartifactId=java-test-repo
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DinteractiveMode=false
I'm able to package and run everything OK (obviously the dependencies are
being pulled from the web in this case):
mvn package
java -cp target/java-test-repo-1.0-SNAPSHOT.jar com.quantile.app.App
Next I try to create a bare-bones Guix package to build this (this time
there will be no web access during the build):
(define-public java-test-repo-integration
(let ((commit-integration "b9e3894aa3629fc2d60ceadea2f655d4cb6a826b"))
(package
(name "java-test-repo")
(version integration-version)
(source
(git-checkout
(url "ssh://git@vcs:1234/ea/java-test-repo.git")
(commit commit-integration)))
(build-system maven-build-system)
(home-page "https://vcs/projects/EA/repos/java-test-repo/browse")
(synopsis "Java Test Repo Production")
(description "Java/Maven bare-bones framework for testing")
(license license-quantile))))
I get the following build failure:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1.136 s
[INFO] Finished at: 2022-02-08T14:39:36Z
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
on project java-test-repo: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed: Plugin
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4 or one of its
dependencies could not be resolved: Failed to collect dependencies at
org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0-M4 ->
org.apache.maven.surefire:maven-surefire-common:jar:3.0.0-M4 ->
org.apache.maven.surefire:surefire-api:jar:3.0.0-M4 ->
*commons-codec:commons-codec:jar:1.15:
Failed to read artifact descriptor for
commons-codec:commons-codec:jar:1.15: *Cannot access central (
https://repo.maven.apache.org/maven2) in offline mode and the artifact
org.apache.commons:commons-parent:pom:52 has not been downloaded from it
before. -> [Help 1]
After doing some digging I think I know why:
$ guix show java-commons-codec
name: java-commons-codec
version: 1.15
outputs: out
systems: x86_64-linux i686-linux
dependencies: *apache-commons-parent-pom@50* java-commons-lang3@3.9
java-junit@4.12
So it's packaged with a propagated apache-commons-parent-pom at version 50.
See also here for package definition:
https://github.com/guix-mirror/guix/blob/9fe48723c8266ffe8e6a639be2ec2e362cf20cb5/gnu/packages/java.scm#L7671here
But if I look at the POM in the Gnu Store - it is showing version 52 for
the commons-parent which I am assuming (perhaps incorrectly?) should match
the version 50 above?
/gnu/store/7qgi821xidn9nbb07qw35g7wmgv84jln-java-commons-codec-1.15/lib/m2/./commons-codec/commons-codec/1.15/commons-codec-1.15.pom
<parent>
<groupId>org.apache.commons</groupId>
<artifactId>commons-parent</artifactId>
<version>*52*</version>
</parent>
Likewise if I look at the source code on Apache's website - it's 52 too:
https://dlcdn.apache.org//commons/codec/source/commons-codec-1.15-src.tar.gz
<https://dlcdn.apache.org/commons/codec/source/commons-codec-1.15-src.tar.gz>
<parent>
<groupId>org.apache.commons</groupId>
<artifactId>commons-parent</artifactId>
<version>*52*</version>
</parent>
What I think has happened is that java-commons-codec has been promoted from
version 1.14 to version 1.15 without changing the propoagated input?
On version 1.14 everything would match:
https://archive.apache.org/dist/commons/codec/source/commons-codec-1.14-src.tar.gz
<parent>
<groupId>org.apache.commons</groupId>
<artifactId>commons-parent</artifactId>
<version>50</version>
</parent>
*So assuming this isn't going to cause an avalanche of other issues the
solution proper seems to be either downgrade java-common-codec to version
1.14, or upgrade the dependency on apache-commons-parent-pom to 52?*
What I'm looking for today is any workaround which allows me to use Maven
without having to wait to for upstream fix.
My first attempt was to try - adding an inherited package and then swapping
this in place of 1.15:
(define-public java-commons-codec-old
(package
(inherit java-commons-codec)
(version "1.14")))
guix build -L /home/foo/git/guix-packages/packages
--with-input=java-commons-codec=java-commons-codec@1.14 java-test-repo
This seems to just go round in circles never building and throwing Java
exceptions?
I also tried manually patching the whole dependency tree, but I think I've
introduced the same package more than once attempting this as I get symlink
errors:
(define-public java-commons-codec-old
(package
(inherit java-commons-codec)
(version "1.14")))
(define-public java-surefire-api-old
(package
(inherit java-surefire-api)
(propagated-inputs
`(("java-commons-codec" ,java-commons-codec-old)
,@(alist-delete "java-commons-codec" (package-propagated-inputs
java-surefire-api))))))
(define-public maven-surefire-common-old
(package
(inherit maven-surefire-common)
(propagated-inputs
`(("java-surefire-api" ,java-surefire-api-old)
,@(alist-delete "java-surefire-api" (package-propagated-inputs
maven-surefire-common))))))
(define-public maven-surefire-plugin-old
(package
(inherit maven-surefire-plugin)
(propagated-inputs
`(("maven-surefire-common" ,maven-surefire-common-old)
,@(alist-delete "maven-surefire-common" (package-propagated-inputs
maven-surefire-plugin))))))
(define-public java-test-repo-integration
(let ((commit-integration "b9e3894aa3629fc2d60ceadea2f655d4cb6a826b"))
(package
(name "java-test-repo")
(version integration-version)
(source
(git-checkout
(url "ssh://git@vcs:1234/ea/java-test-repo.git")
(commit commit-integration)))
(build-system maven-build-system)
* (arguments `(#:maven-plugins
(("maven-surefire-plugin" ,maven-surefire-plugin-old)
,@(alist-delete "maven-surefire-plugin" (default-maven-plugins)))))*
(home-page "https://vcs/projects/EA/repos/java-test-repo/browse")
(synopsis "Java Test Repo Production")
(description "Java/Maven bare-bones framework for testing")
(license license-quantile))))
Any ideas greatfuly received!
[-- Attachment #2: Type: text/html, Size: 24900 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Maven Build System Dependency Issue
2022-02-08 15:27 Maven Build System Dependency Issue Phil Beadling
@ 2022-02-08 20:19 ` Julien Lepiller
2022-02-09 12:23 ` Phil
0 siblings, 1 reply; 3+ messages in thread
From: Julien Lepiller @ 2022-02-08 20:19 UTC (permalink / raw)
To: Phil Beadling; +Cc: Guix Devel
Hi Phil,
I have already seen the issue previously, and I believe it is now fixed
on master. As you can see here,
https://github.com/guix-mirror/guix/blob/master/gnu/packages/java.scm#L7899
we now propagate the correct parent pom.
In particular, java-jmh is a much more complex package, and it builds
fine with the maven-build-system. So I suggest you to pull to the
latest master commit and enjoy :)
Don't hesitate to get back if you still have issues on master, I'll be
happy to help!
Le Tue, 8 Feb 2022 15:27:14 +0000, Phil Beadling <phil@beadling.co.uk>
a écrit :
> Hi Guixers,
>
> First let me say I'm a Maven novice, so it's possible I'm doing
> something dumb on the Maven side of things.
>
> I'm unable to make a bare-bones Maven project build in Guix.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Maven Build System Dependency Issue
2022-02-08 20:19 ` Julien Lepiller
@ 2022-02-09 12:23 ` Phil
0 siblings, 0 replies; 3+ messages in thread
From: Phil @ 2022-02-09 12:23 UTC (permalink / raw)
To: Julien Lepiller; +Cc: Guix Devel
Julien Lepiller writes:
> Hi Phil,
>
> I have already seen the issue previously, and I believe it is now fixed
> on master. As you can see here,
> https://github.com/guix-mirror/guix/blob/master/gnu/packages/java.scm#L7899
> we now propagate the correct parent pom.
Thanks Julien that looks exactly as I'd expect now. Out of curiosity
was this change only merged to master in the last few days? When I
looked on Guix mirror I ended up seeing the old 50 version just a few
days ago? It's always possible I just looked at the wrong branch by
accident!
One last question - I note your change was committed on 21st Dec, which
is bad luck for me as the Python 3.9 upgrade went in on 17th Dec, and
I'm stuck for non-Guix reasons on 3.8.2 (so my Guix is a bit stale for
now). I'll fix this medium-term on my side, but was wondering if there
is any way around this?
None of my previous e-mail's attempts worked, but using Guix Inferiors
this morning to make "guix" itself the inferior (rather than the maven
package), my pacakge then actually built. Adopting the example given
in the manual, I was able to create a profile out of the below manifest,
which if I then run "guix build" inside it downloaded and built the older
build system on the fly, including java-commons-codec@1.14 - which is
pretty cool.
I could then continue to add packages from current guix alongside this,
although I'm not sure if this is a particularly good idea!
Given that I want to rewind the build system itself rather than a
specific package is this the right/canonical way to do this? There
seems no way of using --with-inputs or --with-source to do this,
presumably because you need to make the change *before* guix itself is
called?
(use-modules (guix inferior) (guix channels)
(srfi srfi-1)) ;for 'first'
(define channels
;; This is the commit id just before java-commons-codec was upgraded 1.14 -> 1.15
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git")
(commit
"a3b6e904484e23db65990be70d76ba32c15fd03f")))) ;; old fix
;;"a348520e2a253bc81fa92566e74f8b3e60fea058")))) ;; future fix
(define inferior
;; An inferior representing the above revision.
(inferior-for-channels channels))
;; Now create a manifest contain guix itself rewound to where java-commons-codec=1.14
(packages->manifest
(list (first (lookup-inferior-packages inferior "guix"))))
;;(specification->package "maven"))) ;; add other packages as required
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-02-09 12:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-02-08 15:27 Maven Build System Dependency Issue Phil Beadling
2022-02-08 20:19 ` Julien Lepiller
2022-02-09 12:23 ` Phil
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).