Is there any plan to mainline dev-java/* packages?

[fpemud]

[wltjr]

The Gentoo community does not want me or my work. I am a former developer and foundation trustee. They have refused to let me return for over a decade. I am on my 3rd year of a total communications ban. This overlay is a result of the community not wanting this work in Gentoo. I might see about donating the work to Funtoo. I doubt it will ever go into Gentoo, and given how I have been treated, I rather not see Gentoo benefit from my work. Even though, I know that only hurts others, not the main devs responsible for preventing my return and direct contributions.

[fpemud]

Sorry for that. I see the main difference related to java between your overlay and gentoo repository is dev-java/jem vs dev-java/java-config in some eclass files. May I ask what the reason is for that? I need to add more java packages to my system, then on top of that, write ebuilds for other packages I need that are not available on the Internet (mainly spring-boot & spring-cloud related).

[wltjr]

Yes, it is an unfortunate situation that only affects users, not the developers who are preventing progress.

Regarding jem and java-config, despite many around Gentoo liking python, java-config is not really maintained. I also found it to be inefficient and has more overhead. I prefer command line tools be coded in an efficient language that can last over long periods of time. Given how many times java-config is used within ebuilds. To me, it made sense to port it to a language that did not break with changes in python version, that I could maintain, and was more efficient for use on embedded systems. Also, ideally, jem is made such that other distributions could use it, whereas java-config is a bit more Gentoo specific. I had intended for jem to replace java-config in Gentoo.

Regarding the eclasses, in short I made modifications for building Java packages with >= jdk 11. Gentoo's eclasses can only handle Java up to 8/1.8. I also made major changes to how Java is handled. The byte code version is now based on the jdk used at build, rather than the jdk/jre version in an ebuilds dependency. That way, you can have all Java code built to the same version, and when new ones come out, you do not need to modify any ebuilds unless it breaks with a newer Java version. It makes it much easier to maintain a massive amount of packages across a wide variety of Java versions. Only downfall, is it is a forward operation. If you want to go back to an older Java version, you need to rebuild everything.

I also do not use ant, maven, gradle or other. Gentoo has eclasses that wrap around ant, that require considerable changes to handle JDK 11+ and some python xml re-writers that are also unmaintained. Not to mention, those ant eclasses are not really developer friendly. I cut all that out and just go with a straight javac wrapper. It makes it easier to maintain the ebuilds, although it does come with some drawbacks like building native code, and having to replicate aspects of the build systems.

I need to get back to further packaging spring. I am stuck on spring 4.x due to 5.x requiring kotlin to build. I need to package kotlin in some form, work on some eclasses for that, and then I can see about building stuff that requires kotlin. I likely cannot package spring-boot, spring-cloud, or related till I address the kotlin situation. Not to mention scala and maybe clojure someday. I was about to modify the eclasses further to replace javac with groovyc, for groovy based builds. I have some of that in progress, just needs refinement and to be committed for groovy. But that should also carry over for replacing javac with kotlin compiler for kotlin code and other java based compilers.

I have done a lot of work, but there is much more to be done. I just lack the time, and its not really anything I benefit from directly or indirectly. Some things I use, but not spring or other stuff. I just packaged what I needed for dependencies of other packages. Plus, at times when I run into issues with one thing, I turn to another. Like Maven and Gradle are close to be semi usable, but each have unique issues I need to overcome. Other things like Netbeans, I just need to get back to the work already in progress. Lots of ideas and plans, little time, and lots of issues at every turn.

I had intended for others to help out, but this far its a one man show. If others in Gentoo would get out of the way, and let me do all this in Gentoo. I could re-constitute the Gentoo Java Team, and really see about tackling some of the larger issues. Until then, its just me doing what I can when I can. Not to mention, most importantly, keeping things up-to-date. Its one thing to do the work, it is another to keep that work updated. Most of the stuff I do, is done in a manner that allows an individual to efficiently maintain a massive amount of ebuilds. If there were a few more, who knows what all could be accomplished.

I also need to strip out a bunch of unused stuff in the eclasses, and further simplify it all. Then document it such that others can create ebuilds, without having to dig through eclasses to understand how to use them in ebuilds. I have made a pretty considerable amount of changes to the eclasses and java system overall. The one thing I have not gotten around to, is modifying eclasses for optional java support. Non-java ebuilds that have optional java bits to build.

Its been years of work. Gentoo could and should be benefiting from, but a handful have decided otherwise, and it prevents progress for many more. I hoped for years that might change, but this overlay is a result of it not changing.