Building JAVA-applications with maven

[Mikhail T.]

Application-authors using maven tend to rely on the tool to download -- 
at build-time -- the third-party JARs their application needs to build 
and/or run. The number of such downloads can be substantial.

For example, to build jruby from source (which the port is not currently 
doing), mvn downloads over 300 JAR-files.

This poses obvious challenges for all porters -- be they FreeBSD ports, 
Net/OpenBSD pkgsrc, or even Linux RPM/deb maintainers. I think, we'd all 
like:

 1. the downloads to happen at the download stage (a.k.a. make fetch)
 2. the checksums of the downloaded files to be verified (although maven
    can do this itself)
 3. the downloaded JARs to be shared between multiple users -- mvn would
    stick them into ${HOME}/.m2 if allowed
 4. the downloaded JARs to survive make clean -- so they should not be
    under ${WRKDIR} either
 5. to avoid downloads and bundling of JARs, which are parts of other,
    already ported packages and applications -- right now I count 18 (!)
    ports, which bundle junit.jar, for example -- a shame.

Currently the ports of maven-using applications seem to either resign to 
simply installing pre-built JAVA-applications (instead of building them 
from source as port ought to), or -- like eclipse -- using pre-bundled 
dependencies. Neither is very satisfactory...

Ports-system needs some way of dealing with these issues properly and 
orderly. What should the strategy be?

How about allowing a port to declare the following needs, which would be 
taken care of for it:

 1. It needs the following JARs, which /aren't/ already available from
    other ports, downloaded -- into ${DISTDIR}/jars or some such.
 2. It needs its pom.xml file(s) patched to use the following list of
    JARs, which /are/ available from other ports, directly. (Hopefully,
    the JARs on the first list of each port will gradually make its way
    into the second.)

This may still leave the a. and b. unsatisfied -- or partially satisfied 
-- but those really are the least important of the problems. The item 2. 
may be "hairy" -- somewhat like the patching of libtool and friends 
we've had for some time. But it is doable...

Does this seem like a valid concern? Does the proposal seem like a good 
idea? Anyone up to creating Uses/maven.mk? Even just testing the new 
facility with a port of their own would be helpful...

    -mi