This introduces a pom.xml which tells Maven how the
project is structured. To avoid a boatload of disruptive
renames, we override some of Maven's default settings.

It also removes the Ant build files to avoid maintaining
multiple build systems.

This change is only for the lifetime of the SciJava fork;
I am really hoping the Mavenization will be merged upstream.

This hopefully avoids any possible confusion with official versions.

These sections are required for OSS Sonatype.

Unfortunately, the maven-release-plugin does not seem to like the soft
${project.version} references, since they appear to be SNAPSHOTs until
after the project version is actually bumped to the release version.

Signed-off-by: Jenkins <jenkins@imagej.net>

Unlike vecmath and j3dcore, j3dutils is not licensed under the
GPLv2 + Classpath exception, but rather a BSD 2-clause license.

This version has renamed package prefixes:
* javax.vecmath -> org.scijava.vecmath
* javax.media.j3d -> org.scijava.java3d

For a rationale, see:
* scijava/vecmath@f9291bc
* scijava/java3d-core@925def3

This avoids a serious problem with Java 3D on OS X 10.11 "El Capitan":
it is no longer possible for users to easily delete the Java 3D 1.3
artifacts out of /System/Library/Java/Extensions, thanks to El Capitan's
new System Integrity Protection (SIP, a.k.a "rootless") feature.

So, even with the new Java 3D 1.6 on the classpath, the old Java 3D 1.3
always takes precedence because /System/Library/Java/Extensions is on
OS X's java.ext.path by default. Worse, the old Java 3D 1.3 crashes
Oracle Java 8.

I thought of two different ways to address this new difficulty:

1. Change the package prefix to avoid a clash.
2. Manually manipulate the java.ext.path.

Option 2 is a deployment-centric solution, which only solves the problem
in environments where tweaking the Java runtime parameters is possible.
It is also a pain because there is no way to simply blacklist the
undesirable directory; instead, the java.ext.path must be built from the
ground up to include all the directories which Java includes by default,
except for /System/Java/Library/Extensions. Furthermore, there _are_
libraries in said directory that might continue to be useful for ImageJ
users, such as the support for AppleScript. It would be a shame to lose
access to _all_ Apple-specific Java extensions, just because of three
bad apples (the old Java 3D 1.3 JARs).

Therefore, this commit opts for option 1.

I am maintaining this fork; Harvey Harrison maintains upstream.

Signed-off-by: Jenkins <jenkins@imagej.net>

The GitHub platform is discontinuing support for it.

See: https://github.blog/2021-09-01-improving-git-protocol-security-github/#whats-changing