_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI JReleaser: quick and effortless way to release your project
nja wrote 3 hours 6 min ago:
I just built a library on jReleaser! [1] I wanted to release a jvm lib
on Maven Central -- which no longer requires opening a jira ticket for
a new package! Instead, simple DNS TXT verification is all that's
needed. However, the caveat is that it's the new Maven Central
service, which doesn't have as much support in build tools as the older
sonatype one. jReleaser is one of the few tools which supports it.
So I hacked together a fully self-contained minimally reproducible
example of a Gradle library, built and published in GitHub using
jReleaser.
There were several things that had me scratching my head with
jReleaser, and the docs are strangely organized IMO (it comes from
supporting so many facets, I believe), but it ended up working well
enough!
I ended up adding a doc build and some other stuff to the repo too.
Now I have a full example that I can use to trivially publish new
libraries (such as in-progress [2] ).
(Why Maven Central? Since the demise of jFrog/jCenter/BinTray, there's
not been an easy way to widely publish jvm libraries. At work I've
used GH packages, but that requires a GitHub login even for public
packages, which is a significant barrier IME. JitPack is one option,
but it does on-demand builds linked closely to the origin repo, whereas
I wanted the classic immutable build published on release.)
URI [1]: https://github.com/NJAldwin/maven-central-test
URI [2]: https://github.com/NJAldwin/ambient-consumer
buremba wrote 6 hours 3 min ago:
Is there a doc for Python apps?
gunnarmorling wrote 7 hours 31 min ago:
Very nice to see JReleaser here on HN! I'm very happy with it, using it
for publishing releases of kcctl (a command line client for Kafka
Connect written in Java, compiled and published as native binaries for
Linux/MacOS/Win via GraalVM). Here's the config, in case folks are
looking for an example: [1] . Releases are triggered by running a
parameterized workflow (taking the version to be released) on GitHub
Actions.
A big shout-out to Andres Almiray, the maintainer of JReleaser, who has
always been super-fast to answer any questions and help to sort out
issues when I ran into them.
URI [1]: https://github.com/kcctl/kcctl/blob/main/pom.xml#L430-L530
whartung wrote 7 hours 47 min ago:
When I released my last Java project, I came out with a MacOS DMG, a
Windows EXE installer, a Windows MSI installer, and a Fat Jar for
Linux.
Now we have MacOS ARM, MacOS x86, Linux ARM/x86, Windows ARM/x86.
Even for a basic "cross platform" Java program (that bundles the JRE),
that's 6 installs, which ostensibly need to be built on their
respective platforms. Add on to that if you using something that
includes a binary (like, say, SQLite, much less JavaFX which I work
with).
The release burden is, well, frankly, daunting for a small project.
My honest thinking for my next project release is simply to tell folks
to install the JDK, download the source code, and have them run:
./mvnw javafx:run.
(Or they can run go.sh/go.bat which essentially does the same thing.)
That'll download all of the stuff it needs including the Maven runtime
and all of the libraries, as appropriate, build the project, and run
it. It's Fast Enough (maybe it's awful on a small RPi, I dunno).
When I get more than 5 downloads, folks can vote as to which installer
to work on.
Creating the executables was quite the black hole. I didn't create one
for Linux because I honestly didn't know what packaging scheme to use.
In theory, the CI infrastructure on GitHub will let you build on
different platforms, yet another black hole of time to sink into.
So, yea, at least initially, I think the maven wrapper will be my
"release model". SHOULD be pretty simple.
invalidname wrote 4 hours 19 min ago:
Did you look at [1] ?
URI [1]: https://www.jdeploy.com/
whartung wrote 3 hours 36 min ago:
I did, but at the time it was touted more as a centralized service
that I wasnât really interested in. Maybe itâs better now.
koito17 wrote 7 hours 37 min ago:
Distributing a single uberjar, whenever possible, is generally a good
idea IMO. One major reason I like the JVM as a platform is that I
don't need to mess with containers or native images. To reduce burden
of deployment, native images are out of the question. Thus the
choices are "force user to have Java runtime installed" or "force
user to have container runtime installed". Double-clicking a JAR file
(or running "java -jar ...") tends to be easier than debugging Mac /
Windows quirks with Docker.
Presumably the major issue in distributing JavaFX applications (or
most Java 9+ applications in general) is dealing with jlink. That
leads to the problem in question: having to create N * M executable
blobs, where N = # of operating systems and M = # of CPU
architectures.
whartung wrote 7 hours 17 min ago:
I absolutely agree on the JVM platform, an uber jar file is really
quite easy to use and deploy.
You don't need to do JLink for JavaFX. FX requires binary
libraries, but you can make "platform specific" uber jars (and,
probably, generic uber jars) that bundle correct libraries.
SQLite bundles all of the platforms into a single jar file, for
example.
But that's another reason, at least for me, to look at the maven
wrapper. Maven will "download the right thing" and not "burden"
folks with copies of libraries they don't need. FX binaries can be
quite big, particularly if you include WebKit (which I do simply
for easy in app documentation, it's just a fat pig of a dependency
though).
diggan wrote 7 hours 32 min ago:
> Distributing a single uberjar, whenever possible, is generally a
good idea IMO.
Yeah, seems to work for games well enough. Ship uberjar + small
wrapper shellscript for Linux/macOS, .bat for Windows. Should work
everywhere*
layer8 wrote 8 hours 7 min ago:
This doesnât seem to address building installers, unfortunately.
whartung wrote 7 hours 46 min ago:
It creates MacOS packages, Windows MSI, and Linux bundles. Those are
all "installers", right?
layer8 wrote 7 hours 41 min ago:
My apologies, I couldnât find this in the documentation. Can you
give me a link?
smarx007 wrote 7 hours 37 min ago:
URI [1]: https://jreleaser.org/guide/latest/reference/assemble/de...
brunoluiz wrote 9 hours 14 min ago:
Is it somehow related to GoReleaser? I saw GoReleaser supports multiple
languages now as well
loginatnine wrote 4 hours 55 min ago:
It's inspired by it. It's mentioned here[1]
URI [1]: https://jreleaser.org/guide/latest/index.html#_acknowledgmen...
caarlos0 wrote 6 hours 23 min ago:
GoReleaser author here.
I think jRelease was based on some of GoReleaser's ideas.
GoReleaser just recently started adding support for more languages.
ashishb wrote 6 hours 33 min ago:
I love go-releaser.
I believe it is a great choice for Go-based projects.
I use it for multiple side-projects of mine (that are written in Go).
kbd wrote 6 hours 53 min ago:
Had the same question, surprised it's not addressed in the faq.
DIR <- back to front page