[Bug 272855] Mk/bsd.default-versions.mk: update JAVA_DEFAULT to 21

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272855

--- Comment #26 from Michael Osipov <michaelo@FreeBSD.org> ---
(In reply to Mikhail Teterin from comment #25)
> > Nuke it, unless there is a ports consumer people are better of using Maven,
> > Maven Resolver Ant Tasks, Gradle or something else
>
> If we want consistency, then the same approach -- abandoning ports in favor
> of each "ecosphere's" respective package-mananger -- should be applied to
> Python, Ruby, Perl, Javascript, and Go software. Oh, and Rust too!

This isn't black an white. Rust and Go have to be compiled natively, but there
the download of crates and what ever Go has works from the ports system.
Python, Perl and PHP have the same issue, every often native components. I
don't know anything about JS and Ruby. As soon as you have native components
you depend the system flags and OPTIONs. You can't make them go away by using
upstream. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290653 for
Python with uv. Java has very very little native components built with JARs and
they do not depend on a specific structure like PHP or Python with site
packages do.

> > only the bundled JARs have been tested and blessed by upstream
>
> This is an unfortunate state of affairs, and we don't succumb to
> this logic in other places. For example, libjpeg-turbo was a
> replacement for libjpeg, and we would've dismissed concerns of
> maintainers/authors of any JPEG-using software about potential
> incompatibilities as FUD.

Here again it is ecosystem. In Rust all deps are pinned in the lock file
(Makefile.crates).

> We've also gone through some effort to stop depending on the particular
> version of a shared library in the ports -- the insistence on the
> exact version of each dependency -- is the exact opposite of that view.
> The syntax of pom.xml allows specifying version-ranges, but the
> prevailing opinion in the Java world frowns at that (bizarrely)...

In C/C++ symbol versioning likely solves the problem. It is, again, depending
in the ecosystem. We (the Apache Maven dev team) have soft-deprecated version
ranges because people never really understood/applied them properly and they
gave unreliable build results especially ranges like "[1.2,)". As soon as your
dep hits 2.0 this might break your build -- hooray!

> I wish, FreeBSD's Java-people have developed some way to _uniformly_
> build Maven-using software -- perhaps, with Mk/Uses/maven.mk -- so that:
>
> 1. No individual port for each dependency would be required
>    -- here I agree with Michael -- even if pkg still registered
>    the JARs as runtime dependencies.
> 2. Different packages using the same dependencies (such as log4j)
>    used the same version (preferably the latest) of each dependency.
>    It'd probably require some standardized manipulations of the
>    upstream's pom.xml -- sort of how we manipulate the "auto" tools,
>    replacing versions with ranges and changing dependency types into "system".
> 3. Maven repository lived in a standard location -- /usr/ports/distfiles/m2 ?

I think your goal is very noble -- but ultimately, IMHO, a waste of time:
* Use Java software as it has been bundled by upstream and modify if necessary
-don't recompile
* You'd need to reimplement Maven logic to pull deps (could be done with
Resolver Ant Tasks)
* What if deps have repos in the POMs?

For me, this is a huge undertaking where the benefit is questionable. To what I
could agree is that if a port requires addtional JARs they should be fetchable
conveniently, but then: Why didn't the author a bundle for that? So it boils
down to two type of packages: (a) libraries -- standalone pointless, (b)
runnables/bundles -- which include everything you need to run it, e.g., Tomcat,
Eclipse, Maven, JMeter, Nexus OSS, Jetty, etc.

I think we need sane tradeoff w/o reinventing the wheel.

BTW: PHP's composer suffers from the very same problem. See my port
devel/websvn. I was never able to reconcile the ports tree and composer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.