Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Is there a tracking issue for Java 11 on Bugzilla? Kaibo Ma On Wed, 14 Apr 2021 at 15:45, Miroslav Šulc wrote: > hi guys, > > we're still far from unmasking java 11 on gentoo, but i hope it will > happen, one day (or another...). currently there is one issue across the > whole gentoo tree that is a sure blocker and could and should be easily > resolved. as java 11 does not compile bytecode older than 1.6, > everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail to > compile and run. these deps should be lifted up to > virtual/(jdk|jre)-1.8. also, packages that depend on > virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the > lowest version that we support on gentoo and future versions of java > might drop support for 1.6 and 1.7 as well, but it's not a blocker for now. > > just to get an idea how many ebuilds are affected, here's a short summary: > > $ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c >1 virtual/jdk-1.2 >7 virtual/jdk-1.3 > 68 virtual/jdk-1.4 > 119 virtual/jdk-1.5 > 444 virtual/jdk-1.6 > 136 virtual/jdk-1.7 >1 virtual/jre-1.2 >7 virtual/jre-1.3 > 68 virtual/jre-1.4 > 124 virtual/jre-1.5 > 460 virtual/jre-1.6 > 113 virtual/jre-1.7 > > here's the list of all packages where java 1.5 or older is used: > > $ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E > "s%/[^/]+$%%g" | sort | uniq > app-accessibility/brltty > app-accessibility/freetts > app-crypt/jacksum > app-emacs/jde > app-misc/jitac > app-office/hourglass > app-text/hyperestraier > dev-db/db-je > dev-db/hsqldb > dev-db/qdbm > dev-java/ant-contrib > dev-java/ant-owanttask > dev-java/apple-java-extensions-bin > dev-java/apt-mirror > dev-java/aspectj > dev-java/avalon-framework > dev-java/bcel > dev-java/bnd-junit > dev-java/bndlib > dev-java/browserlauncher2 > dev-java/bytelist > dev-java/cal10n > dev-java/cdegroot-db > dev-java/cldc-api > dev-java/codemodel > dev-java/commons-el > dev-java/commons-fileupload > dev-java/commons-lang > dev-java/commons-math > dev-java/commons-net > dev-java/commons-pool > dev-java/commons-validator > dev-java/dtdparser > dev-java/easymock-classextension > dev-java/ehcache > dev-java/ezmorph > dev-java/fastinfoset > dev-java/fscript > dev-java/glassfish-persistence > dev-java/gnu-classpath > dev-java/gson > dev-java/hamcrest-integration > dev-java/hawtjni-runtime > dev-java/helpgui > dev-java/higlayout > dev-java/htmlcleaner > dev-java/ical4j > dev-java/jansi > dev-java/jarbundler > dev-java/java-dep-check > dev-java/java-getopt > dev-java/javahelp > dev-java/java-service-wrapper > dev-java/javolution > dev-java/jaxen > dev-java/jbitcollider-core > dev-java/jboss-logmanager > dev-java/jcmdline > dev-java/jcodings > dev-java/jdbc2-stdext > dev-java/jdbm > dev-java/jebl > dev-java/jgoodies-looks > dev-java/jid3 > dev-java/jinput > dev-java/jisp > dev-java/jlibeps > dev-java/jnr-ffi > dev-java/jnr-netdb > dev-java/joni > dev-java/jortho > dev-java/jreleaseinfo > dev-java/jstun > dev-java/jta > dev-java/junit-addons > dev-java/junrar > dev-java/jvmstat > dev-java/jvyamlb > dev-java/jzlib > dev-java/j2ssh > dev-java/ldapsdk > dev-java/libg > dev-java/libmatthew-java > dev-java/l2fprod-common > dev-java/miglayout > dev-java/minlog > dev-java/mockito > dev-java/msv > dev-java/nekohtml > dev-java/odfdom > dev-java/osgi-compendium > dev-java/osgi-enterprise-api > dev-java/osgi-foundation > dev-java/pdf-renderer > dev-java/picocontainer > dev-java/prefuse > dev-java/radeox > dev-java/resin-servlet-api > dev-java/sblim-cim-client > dev-java/skinlf > dev-java/slf4j-ext > dev-java/spymemcached > dev-java/squareness-jlf > dev-java/stax-ex > dev-java/stax2-api > dev-java/sun-httpserver-bin > dev-java/sun-jai-bin > dev-java/sun-jimi > dev-java/sun-jms > dev-java/sun-jmx > dev-java/swingx > dev-java/swt > dev-java/tagsoup > dev-java/tapestry > dev-java/validation-api > dev-java/werken-xpath > dev-java/wsdl4j > dev-java/xmlstreambuffer > dev-java/xom > dev-java/zeus-jscl > dev-lang/interprolog > dev-lang/R > dev-lang/xsb > dev-libs/OpenNI > dev-libs/OpenNI2 > dev-lisp/abcl > dev-ruby/rjb > dev-tex/tex4ht > dev-util/android-sdk-update-manager > dev-util/jarwizard > dev-util/oprofile > games-board/domination > games-board/megamek > games-puzzle/pauker > java-virtuals/jmx > media-gfx/freewrl > media-gfx/graphviz > media-gfx/povtree > media-libs/li
Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository
>What do you think about this alternative idea? It looks pretty straightforward at a first glance, but I think it would require other components because you are not providing any information of the direct dependencies of the java packages/artifacts, which means it might have to consult other sources (probably a remote repo) first, and then attempts to resolve to a local JAR from your WorkspaceReader. Have you tested this with --offline and the local maven cache (~/.m2) cleared beforehand to see if your extension can actually work in a sandboxed environment? XMvn does make use of this but it does more than just this, it generates full POMs which might be very hard to tackle. Another thing is for gradle. It does not expose public API for custom repositories. It does have the API for it, but it is not documented and it is subject to change. XMvn has a gradle connector, but it is already outdated and would only work for older gradle versions. I have tried to create a gradle plugin with a custom repository, but the internal API was very confusing, and it wasn't clear what I should do. It seems that having a local maven repository is the only straightforward and easy solution which doesn't involve much heavy patching of build files or deep understanding of the infrastructure with a large amount of effort in order to maintain the project. Kaibo Ma
Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository
>1. We need to be able to tell the build system that it should only >lookup artifacts from a particular repository, the system wide one. I don't think this would be a big problem. For ebuilds, they can just enable offline mode which would restrict maven/gradle from using remote artifacts. As gradle/maven dependency caches are on a per-user basis, the portage user would not encounter issues such as using a previously fetched artifact from the cache. >2. We need to be able to tell the build system to install it's artifacts >in a particular local repository, nowhere else. This would be hard for maven I think. But for gradle, init scripts could be installed to GRADLE_HOME/init.d/ by eselect-gradle which will add the local repository to publishing, plugins, and dependencies repos. See https://docs.gradle.org/current/userguide/init_scripts.html.
[gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository
Hi all, This is an RFC copied from a bug (https://bugs.gentoo.org/776007), and I have added a new section because I realized maven local would not be a good destination for system-wide packages. - 0. Motivation Java packaging has become more difficult on Gentoo because maven/Gradle, the two main build systems for java, is unsupported. When java packages migrated from their ant builds to maven/Gradle, most of the packages have not been updated since. I know that in Java overlay, the packaging practices in general is to patch the pom.xml files to work with local jars, but it does not work with Gradle and can be difficult when working with large projects. 1. Challenges - maven modules/artifacts do not work well with java-config. They generally have a group, which resolves name collisions, but java-config currently does not have a group variable. - it will be hard to reinvent the wheel. If the solution was to rewrite pom.xml/build.gradle files, it would have to resolve the dependencies correctly with all the version constraints instead of relying on the build system. Currently, for java-config packages can only depend on a specific slot of a library, but some might work with newer versions of their dependencies. - plugins are also hard to create in Gradle. Custom resolution of dependencies or specifying a custom repository is not easy because it involves "internal" API without much documentation. Fedora's XMvn project can be used as a starting point but at the time of writing, XMvn is outdated and missing some implementations for newly added interface methods in Gradle's API. 2. Proposed idea Maven/Gradle both have an offline mode which restricts them from fetching online files. For java libraries, they will be published to the local maven repository, which makes it available for other java programs using maven/gradle that depends on the library. Packages that still use java-pkg-simple.eclass can be kept because they are generally not available in maven, so it is rare for other packages to depend on them. The eclass and java-config should be updated for some packages that depend on other packages that get published to mavenLocal, but this seems like a rare case. Those packages can also just get converted to a maven/project using patches. For applications, the launcher scripts should also be changed to parse local artifacts with POM files. If this were to be implemented, newer (revisions/subslots? Or old slots with -new at the end?) packages would be incompatible with older versions of packages. 3. ERRATA The local maven repository would not be a good fit since it is on a per-user basis (~/.m2). The correct way would be to define a path for installing (such as /usr/share/.m2), and pass that to build tools as a URL (file:///usr/share/.m2). Feel free to reply if you have any questions or improvements. Kaibo Ma
