Package Maven 4 as a standalone derivation that can be customized
independently of maven.
It defaults to jdk25_headless (the JDK can be overridden via that
argument), exposed through a local jdk_headless binding so future JDK
bumps are a one-line change.
maven exposes its package builder as the mkBuildMavenPackage passthru
function, which maven_4 reuses to provide its own buildMavenPackage
without duplicating build-maven-package.nix. The version tests passthru
is exposed as well. buildMaven is intentionally not exposed as it is
semi-deprecated.
The dependency FOD deletes the .meta directory during cleanup: Maven
Resolver 2.0.11+ writes machine- and time-dependent files there, which
would otherwise break the fixed-output derivation's hash.
A section about maven_4 is added to the Maven manual.
Assisted-by: Claude Code (Claude Opus 4.8)
This allows calling `buildMavenPackage` with a function that receives a
`finalAttrs` parameter, much like `stdenv.mkDerivation(finalAttrs: ...)`
works.
Following [Best Practices](https://nix.dev/guides/best-practices#with-scopes),
`with` is a problematic language construction and should be avoided.
Usually it is employed like a "factorization": `[ X.A X.B X.C X.D ]` is written
`with X; [ A B C D ]`.
However, as shown in the link above, the syntatical rules of `with` are not so
intuitive, and this "distributive rule" is very selective, in the sense that
`with X; [ A B C D ]` is not equivalent to `[ X.A X.B X.C X.D ]`.
However, this factorization is still useful to "squeeze" some code, especially
in lists like `meta.maintainers`.
On the other hand, it becomes less justifiable in bigger scopes. This is
especially true in cases like `with lib;` in the top of expression and in sets
like `meta = with lib; { . . . }`.
That being said, this patch removes most of example code in the current
documentation.
The exceptions are, for now
- doc/functions/generators.section.md
- doc/languages-frameworks/coq.section.md
because, well, they are way more complicated, and I couldn't parse them
mentally - yet another reason why `with` should be avoided!
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly.
Notably:
- Line breaks in lists behave differently.
- Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75
- The auto_identifiers uses a different algorithm – I made the previous ones explicit.
- Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist
While at it, I also fixed the following issues:
- ShellSesssion was used
- Removed some pointless docbook tags.
* doc: add function argument order convention
Ordering by usage is the de facto ordering given to arguments. It's
logical, and makes finding argument usage easier. Putting lib first is
common in NixOS modules, so it's reasonable to mirror this in nixpkgs
proper. Additionally, it's not a package as such, has zero dependencies,
and can be found used anywhere in a derivation.
* doc: clean up usage of lib
I used the existing anchors generated by Docbook, so the anchor part
should be a no-op. This could be useful depending on the
infrastructure we choose to use, and it is better to be explicit than
rely on Docbook's id generating algorithms.
I got rid of the metadata segments of the Markdown files, because they
are outdated, inaccurate, and could make people less willing to change
them without speaking with the author.
Add nice markdown documentation for how to use mvn2nix plugin and the
buildMaven function within nixpkgs.
Update doc/languages-frameworks/maven.md
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Apply suggestions from code review
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Apply suggestions from code review
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Apply suggestions from code review
Co-authored-by: Doron Behar <doron.behar@gmail.com>
