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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"