From nobody Thu Dec 25 10:29:28 2025 X-Original-To: java@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dcQ3D5fLPz6LdB4 for ; Thu, 25 Dec 2025 10:29:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dcQ3D4mBrz3Jbn for ; Thu, 25 Dec 2025 10:29:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766658568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZY0IG2kcyjEgYv6Gdd5qtPbt8mhu51sYulHzycC/xvo=; b=sivqTqONYHZfGEbkz3iK/ylW9Pq2eR/AEcZgo1FFlGFR3pERMrstoZkXOC/WkbTv80KQ57 COcC/m2X036Ru0SXsKbWXiioA7K4nBHHGjYQ9od3DB1pWBOsYVo4pO8oHOvW0YvApyAkrP S3ef+EHM6/HaoMJuGNtqM+3KqE8mvlcfMFkvfX8+Jv6QxU/SpH01sVg/1Pss80zP9OtOP8 wjxY/iaU2JvtCC21rHDefaCwEQ71imit3cr91jjNnphZdLUgEhIIUlZdedoeniwBC0GvoK R7Vn0rCyNuFU6zQOmoifPa7fmBKlwmJt485SkQ9765+tpo4ZtdLS+Yn2Dk4kfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766658568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZY0IG2kcyjEgYv6Gdd5qtPbt8mhu51sYulHzycC/xvo=; b=xjTDDG7nzzpjqj6jNxoEqwYK+EYCPGVFQk7rcZ2B2qV9qSxj+byXjVHJj/+f+/VTbiexdC /H4NrID7waEgU77oakZlVp9xVm91XRFfpI9SBhoxTbRkItv/+YoSJlfFcnxdy3MMxay9Wx ty0vWwn36OiquaCDaw1bnVdYw5G9wjFVW6pob/qBL2hT31EVR8+ZiwrY1isjOa4kPs64BL 2UD3Q0OD5MnmQYU28qhPfBqTs0n8ixiy05QgXi2Mo0FdoEemGfTj/V3Qc9d3EpzdIdnz1d UbYU0MghETL+OBLrkb0nOO7beqOrtVHKicDsYQGTTiWt7iSXSNBynU/4w9BT9w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766658568; a=rsa-sha256; cv=none; b=dCnief5olL0gU+TN87kZNz6STzbuSOmNbi96BGgmFq1UFulJbBwpA0A4x0AXjwhIWgz+6f PvF9JPOzOH2Gab5kHjw1WPmx/jA64E/g+Yb1kLUbVr6VUykMgaDQnBxcEaWbjFlRkzn93I eAlwDC+J4hRo1IEUBjNvKcx04TbIojkTZuTfBQm3XgMEgcrMmxaEb7niyQ5FmSmWt3DjZR XiL5VyPWn5q8e3Prm/pqh88evlQhTbNkF3ffhWbGXUvFpPZxnLflfjPLab/gfBPkIHjx/h mEtDjWQGShUrIWAcAymnpEgdTcG9IcxRpQncAgVg/VmprNF1H5sorNW8D3YA1Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4dcQ3D46Ctz7wJ for ; Thu, 25 Dec 2025 10:29:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 5BPATSDt043884 for ; Thu, 25 Dec 2025 10:29:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 5BPATS2B043883 for java@FreeBSD.org; Thu, 25 Dec 2025 10:29:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 272855] Mk/bsd.default-versions.mk: update JAVA_DEFAULT to 21 Date: Thu, 25 Dec 2025 10:29:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: michaelo@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting Java to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-java List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-java@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272855 --- Comment #26 from Michael Osipov --- (In reply to Mikhail Teterin from comment #25) > > Nuke it, unless there is a ports consumer people are better of using Ma= ven, > > Maven Resolver Ant Tasks, Gradle or something else > > If we want consistency, then the same approach -- abandoning ports in fav= or > 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 th= ere 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 usi= ng upstream. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2906= 53 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, dependi= ng in the ecosystem. We (the Apache Maven dev team) have soft-deprecated versi= on ranges because people never really understood/applied them properly and they gave unreliable build results especially ranges like "[1.2,)". As soon as y= our 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 "sys= tem". > 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 necess= ary -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 wh= at I could agree is that if a port requires addtional JARs they should be fetcha= ble 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., Tom= cat, 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=