From: Ian Darwin Subject: Re: Ports support for building Java progs with Maven, Take II(b) ("portgen for Java") To: ports@openbsd.org Date: Fri, 18 Sep 2026 14:54:53 -0600 On 9/18/26 9:32 AM, Kirill A. Korinsky wrote: > Hi, > > your portgen_java trigger some thoughts and I recall this project: > https://framagit.org/upt/upt > > maybe we should bring it to ports for a good use and add java frontend? > Interesting, but slightly different aims. upt builds a port to convert existing packages. My stuff is a port for building a port that compiles, packages and installs. Though upt does create a port with Makefile, so maybe there's hope 🙂 The hard part for either: for compiling Java, pbuild cannot download at package build time. So IF we want to go with upt instead of my work, one way forward would be to insist that the user makes an uber-jar before running upt?? They'd also have to set up the uber-jar on a public server. The generated package could include a startup script or an rc.d script based on whether it's a swing or cli vs it's a service - not sure a reliable heuristic for determining which. The other way would be what I did in portgen_java, that is, force Maven to give us the list of downloads at port-generator-running time. I do have some trepidation about unmaintained software though: * The openbsd backend was last updated 2019 and doesn't do PERMIT_* correctly (e.g. uses PERMIT_PACKAGE_CDROM). * UPT itself has only one commit in the last 5 years, though 🙁 (and it was just to bump Python versions). I have contacted the upt maintainer to ask if he thinks the project is still "alive", but "did not hear back by press time". Ian On 9/17/26 4:56 PM, Ian Darwin wrote: > This is a parallel to portgen, specifically for Java. It's designed to > build (the skeleton of) a port that will build and install a Java app > that is built from source using Maven. > > I worked on this several hackathons ago, but never got it finished. > This week I rewrote and worked on it to be more robust (the previous > version tried to parse the output of `mvn dependency:list`; the > current tells Maven to `go-offline` which makes it download all the > deps, and uses that to generate a list to download in the Makefile). > > I'm sending it at this stage to see if anybody thinks it's a good or > bad approach, or has any suggestions on the non-obvious work still to > be done (the Makefile template is obviously not ready for prime time). > > One thing I'm a bit stuck on is the "system dependencies" - when given > the temporary , Maven will download about 80 MB of > its own Jar files in addition to the deps for the target program. I > could save those in /usr/local someplace (I *think* they only change > when Maven version is updated; this would be a separate rdep port > (named like "maven-system-deps"?)). If we could fix this, > portgen_java's run of Maven would only download jar files that are > needed specifically for the app. I think this complication can be left > for later - the download is "only" about 80MB and only a small number > of ports are predicted to use it before we get to this issue. > > The port to install portgen_java is attached as tar.gz. You can look > at the code of the program at > https://github.com/IanDarwin/portgen_java (pull requests welcome if > you use that and feel ambitious; otherwise comments or diffs also > welcome). > > Thanks for looking. > > ----- portgen_java README ----- > > = portgen_java > > A simple Java program to generate an OpenBSD port to build a package > from a Java > program that has a pom file but doesn't offer precompiled packages or > for which > those are not trusted by the porter. > > This it cannot go into base because it depends on a Java port (e.g., > jdk-25) being installed. > > == Usage > >     portgen_java [-f][-d][-v][-k] source-dir > > The given `source-dir` must be a project that has a pom file, and > should have an > `assembly:single` task to build a finished jar. > > Options: > > * -d - debugging output > * -f - force removal of the generated port directory before starting > * -k - keep the temporary local repostiroy (it is by default deleted > at the end) > * -v - verbose - information less detailed than the debugging output. > > == What it does > > Checks for, and reads, the pom file in the target directory. Extracts > the name and version. > > Runs maven with some options to make it download all the dependencies > into a new temporary dir. > Gets the list of required files from the temporary dir. > > Plugs the name and version into a minimal `Makefile`, along with the > list of deps as `DISTFILES1`, > and saves the Makefile under `/usr/ports/mystuff/java/NAME/Makefile`, > where `NAME` is > the name element at the top of the `pom` file. > > == What it does not do > > Due to the huge variability of Java programs, > the generated `Makefile` will need considerable editing. > > This program doesn't yet generate (but these are trivial): > > * for programs, a run script in /usr/local/bin and a desktop file for > GUI start; > * for services, an `/etc/rc.d` file. > > == Future Work > > === Work around limitations ("bugs") in Maven itself > > The familiar `mvn` command is just a skeleton. Running it on an > trivial "Hello World" java > demo project downloads about 80MB of "standard" dependencies plus any > that are needed by the app. > > Maven further does not distinguish between a user and system "local" > directories, so there's no way to just package these standard deps > separately from the app-specific ones and have Maven find them. > However, if there were a separate port/package of these deps, a future > version of this program could just cp -r that into the temp folder. > > I tried to work around this using the `` elements in a > `` in `settings.xml`, > but these seem to be only used for resolving from, not saving into, > unlike ``, > of which you can have only one (in the XML schema). That experiment is > in the file > `settings-global.xml`. > > === Base Portgen is written in Perl > > Perl can call Java, using `Inline::Java` - if we had that in base, > this could be > called directly from the existing portgen. > > Alternately, if somebody wants to manually (not using AI) translate > this into Perl, > it could be added as a module into the standard perl-based `portgen` > in base. > But then you get to take over as maintainer! > > ----- End of README -----