ant: missing dependency on JRE, needed at runtime

[copumpkin]

See https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/apache-ant/default.nix.

It has a pretty hefty "launcher" script that calls readlink -f (and dirname) without referencing coreutils. Since the native readlink on Mac OS doesn't support -f, the script fails at startup. If you fix that, you get something like:

Unable to locate an executable at "/System/Library/Frameworks/JavaVM.framework/Versions/A/bin/java" (-1)

What confuses me more is that the launcher seems to deliberately go out of its way to find a jvm the hard way, without having the expression itself depend on java. I'm not sure why that's a good idea in nix, but given that @edolstra maintains it, I feel like I must be missing something.

[copumpkin]

Ah, @edolstra gives rationale here: 54d1721.

Also, Ant no longer has a build-time dependency on a particular JDK.
It finds the JDK via $JAVA_HOME or $PATH (by looking up javac). This
way, we don't need to have separate packages like apacheAntOpenJDK and
apacheAntOracleJDK. It also seems reasonable: after all, installing
GNU Make doesn't give you a C compiler either. It does mean that
instead of

buildInputs = [ ant ];

you now need to write something like

buildInputs = [ ant jdk ];

I'm not sure I buy the rationale, but however it depends on the java runtime, it doesn't work on Mac OS 😄

[shlevy]

I don't understand the reasoning in that commit. ant doesn't just manage java builds, it needs java to run. This is like not only failing to bundle gcc with make (which makes sense) but also failing to bundle glibc with make and finding it dynamically at runtime.

And if overriding a single drop-in replacement dependency one level deep is too onerous perhaps we should reconsider our package composition style?

[wmertens]

On Tue, Sep 16, 2014 at 4:38 AM, Shea Levy [email protected] wrote:

I don't understand the reasoning in that commit. ant doesn't just manage
java builds, it needs java to run. This is like not only failing to bundle
gcc with make (which makes sense) but also failing to bundle glibc with
make and finding it dynamically at runtime.

Agreed, ant should depend on jdk, and obviously the heavy binary part can
be in a separate, wrapped, package.

The one thing I wonder about is if ant can build for a different JDK than
it is using itself?

[edolstra]

It works for me:

$ nix-shell -p openjdk ant
[nix-shell:~]$ ant -version
Apache Ant(TM) version 1.9.3 compiled on December 23 2013

[copumpkin]

But isn't the point to minimize the opportunity of "works for me"-style problems?

Ant needs a JRE at runtime so why, in principle, shouldn't it depend on one? If I were to change the ant expression to build the java code rather than download the binary tarball, would the answer be different?

On Sep 16, 2014, at 6:03, Eelco Dolstra [email protected] wrote:

It works for me:

$ nix-shell -p openjdk ant
[nix-shell:~]$ ant -version
Apache Ant(TM) version 1.9.3 compiled on December 23 2013
—
Reply to this email directly or view it on GitHub.

[copumpkin]

Anyway, I'm not really sure what to do here, because I need ant. Would you oppose me making a pull request with a more conventional dependency on the JRE? My main concern is that I don't really understand the use cases you had that warranted today's weird set-up. I'm happy to do the naive thing though and see.

[stephenjudkins]

I second that ant should explicitly depend on a JDK. That's how apache-maven expression works, why not apache-ant? Seems like we should either change maven to work with this weird setup, or preferably change ant to explicitly depend on a JDK.

Who ends up making these decisions? Should someone just make a pull request?

[vcunat]

@stephenjudkins: Decisions are typically done by people who have commit access and are "interested" in the particular issue/package. Submitting a PR is nice way to nudge them, and non-controversial reasonable changes are rarely rejected.

[Profpatsch]

(triage) still a problem?

[wmertens]

@copumpkin care to make that PR?

[copumpkin]

Probably, but it's fairly low on my priority list right now. I'll try to get to it in the next couple of weeks.

[murnieza]

I had to export JAVA_HOME=$(/usr/libexec/java_home) to make it work.

[copumpkin]

Still broken!

[shlevy]

As is the logic behind the original change 🦆

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[Gaelan]

Still broken; ant just hangs forever unless you do (e.g.) nix shell nixpkgs#ant nixpkgs#jdk

[tomodachi94]

This will be fixed by #359451, since we elect to hard-code values like the path to JAVA_HOME (we use the JRE in this case).