Depends on what you use it for. As an Eclipse user I found that Eclipse can display Javadoc attached to Java source, and as newer Maven Projects always include Javadoc I very rarely use a dedicated web site.

However, there is a very valid reason for doing so if you have configuration (like a Dependency Injection glue class) where you want to expose that as a web page.

Depends on the use case.

To have a website with the javadoc accessible.

NAS traditional has a web site with javadoc.

Actually I'm not sure this is important. Is it?

Out of curiosity - why? The Maven build process attach the javadoc to the sources automatically already.

We should also consider using the

        <groupId>com.github.github</groupId>
        <artifactId>site-maven-plugin</artifactId>

plugin to deploy the Maven site, the only important thing being the javadoc.

Or we can do as we do now in the current NAS Maven build, and deploy the Maven1 jars to the SBForge.org Nexus, and refere to the transitive H1 dependencies directly in the pom.

This is hopefully all a temporary measure until we move on to H3, which is a native Maven project.

Most of the jars included in the "ant releasezipball" zip are present in Maven Central. Notably heritrix 1 with snapshot dependencies are not (and our locally modified wayback 1.8), so a decision has to be made on how to handle that. Either we can create a heritrix 1 artifact with dependencies and push to Maven Central, or we can have a maven project carrying the jars inside our git repository and have a set of install actions responsible for deploying the jars into your personal repository. The action taken depends on how long we want to stay in a Maven build using Heritrix 1.

Gradle has in my opinion not yet reached critical mass, and I do not see anything in the current ant build that cannot relatively easily be done with plain Maven (after reorganizing the source a bit to conform with the "one project; one artifact" mentality of Maven). Hence, I think that the tooling support of plain Maven in IDE's and Jenkins and others, outweighs all the disadvantages which would compel you to use something else. What we have is - all in all - a relatively simple multi-war, multi-jar source tree, which Maven is fine for.

Vi should consider switched directly to Gradle, which might be considered a successor to Maven (at least seen from my hope for the future).