Arch packages ant from source, which does not contain the optional jar files. Only the binary distribution contains the extra jars. So I've created a PKGBUILD that creates a package using the binary distribution of ant. IMHO, there is no advantage to building ant (nor any other java app) from source, and using the binary distro is so much easier.

The PKGBUILD also removes the Windows .bat/.cmd files, and puts the jars in /usr/share/java/pkgname instead of /usr/lib. This addresses both points in  FS#10472 .

It's generally more flexible to build from source where we can, but we've certainly made exceptions.

These jar files that are missing-- how can one build them? Can't we just add the building of these to the build process for ant somehow? Is the source for them available?

Hi Paul,

There is no need to build the optional dependencies. More accurately, since they are not really a part of the Ant project, it would be more appropriate for them to be built in their own packages. All we need in this context is the prebuilt .jar files.

The list of optional libs is here: http://ant.apache.org/manual/install.html#librarydependencies . As you can see, there's a bunch of them. In order to build Ant from source with all the optional libs, the PKGBUILD would have to download all those jars from various web sites, and put them in ANT_HOME/lib/optional before starting the build process. That would make for an insane PKGBUILD :)

The way I see it, there are only 3 reasonable options:
1) Leave things the way they are right now. This is fine for basic usage, but a java developper will probably wish the package provided more advanced functionalities (like running junit tests from Ant).

2) Use the PKGBUILD I provided above (or similar) to provide a binary Ant with all deps.

3) Cherry-pick only a few optional deps that will add the most popular functionalities without turning the PKGBUILD into a crazy mess.

I think I'm persuaded by your PKGBUILD, Marc. It is elegant, and the fact that these jars ship with the binary distribution means it's a defensible "vanilla" position.

Unless someone objects, I'll plan to implement this fix early next week.

Thanks, Marc, for your well-thought-out PKGBUILD and well-reasoned position.

Hello again Paul,

My PKGBUILD wasn't so well thought out after all. I guess I didn't test it before attaching it to this bug. The problem is that the binaries go under /usr/bin, while the libs go somewhere in /usr/share. They have to all be installed under the same parent directory.

Here's a new PKGBUILD that puts everything in one directory. I chose /usr/share/java/ant; feel free to change it to your liking. I also created /etc/profile.d/apache-ant.sh, that adds the binaries to the PATH, and exports ANT_HOME to the user's env. This is not only recommended by Apache, but also necessary if Ant is no longer going to live directly under /usr. Side note: If you want to change Ant's installation directory, just change ANT_HOME in apache-ant.sh then rerun makepkg. The PKGBUILD gets it's install dir from there.

Finally, I actually tested it this time :) The basic stuff works fine, but I don't currently have any sources that could test the optional deps. (Gimme a few weeks, and I will).

Ciao for now,
Marc

resolved in 1.7.1-2 in testing, to be moved to extra in a week

1.7.1-2 breaks ant for me du to the binaries moved to awkward spots "/usr/share/apache/ant/bin/ant" ore something, anyway it's not in path anymore.
It might be wort to opene anotehr bug for that

It looks like 1.7.1-2 is working for me. It installs an /etc/profile.d/apache-ant.sh which adds it to the PATH. In order to take effect, you probably have to log out and back in.

Oh I see, I alway s leave that box on for weeks and weeks