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 <localRepository>, 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 `<repository>` elements in a
`<profile>` in `settings.xml`,
but these seem to be only used for resolving from, not saving into,
unlike `<localRepository>`,
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 -----
