I'm aware that publishing lombok versions to maven central is a very complicated, boring and laborious process that can't be done by nobody else other that the project owners (@rzwitserloot and @rspilker), and this is something that inhibit releasing too many edge versions as official versions.
So, I'm proposing a simple workaround. Create a maven repository hosted at projectlombok.org and upload whichever edge versions generated to there. Since you'll have the full control of the repository, this should make it much easier to publish whichever artifacts you want to whenever you want to.
Also, this solves another issue with edge releases. The edge release that I download today may be different that the edge release that my neighbour downloads tomorrow, and if we work on a project that uses lombok, this might affect its stability and its build reproducibility. By giving a unique version string to each edge version ever published (even if it is something simple like appending the date/time of its generation or something more laborious as using full semantic versioning), this issue would also be solved. Also, this simplifies the live of people who uses maven or gradle.
Finally, uploads to maven central would still be reserved to glorified non-edge releases.
Yes, we were already thinking along these lines.
Can someone tell us exactly what files we should host for a SNAPSHOT repository, and how we can have multiple SNAPSHOT releases wit hthe same version number, build on different days?
I suggest forgetting about releasing as SNAPSHOTs.
Let's say that you release a new edge today. Then you would name it as lombok-1.16.21.20180517. If you release another one tomorrow, call it lombok-1.16.21.20180518. There are other ways to do that, since you can put whichever number versions that you want.
SNAPSHOT versions are not intended to ever be released. Their purpose is to give some version string for the thing that you are coding right now, which is specially useful when you are coding many different modules at the same time and they have some dependency relationship between them.
Distributing versions tagged as SNAPSHOT in maven repositories is a big no-no. They shouldn't ever leave the local repository in your .m2 folder.
BTW, since you are using ant and uses a pom.xml solely to be able to distribute lombok in maven repositories, I don't think that you will ever need to see or care about SNAPSHOTs, just forget them altogether.
Looking at your pom.xml, it looks fine (except for the googlecode issues link being very outdated, but it is not used for anything other than documenting it for people who look inside the pom.xml searching for this data, i.e. nobody).
To release a new version in your own repository, I think that you will only need to publish those files:
http://projectlombok.org/mavenrepo/org/projectlombok/lombok/<your-version-string>/lombok-<your-version-string>.jar
http://projectlombok.org/mavenrepo/org/projectlombok/lombok/<your-version-string>/lombok-<your-version-string>-pom (edit the file contents to match the version string, of course).
http://projectlombok.org/mavenrepo/org/projectlombok/lombok/<your-version-string>/lombok-<your-version-string>-javadoc.jar (optional, but ant can do it easily).
http://projectlombok.org/mavenrepo/org/projectlombok/lombok/<your-version-string>/lombok-<your-version-string>-sources.jar (optional, but ant can do it easily).
A bunch of .asc, .md5, .sha1, .asc.md5 and .asc.sha1 files. I think that they are also optional.
I.E. Just follow the structure already given here.
For publishing them, you can just manually copy the files to the corresponding virtual folder on the site. For lombok, it ends being much more easier doing this manually than trying to make a crazy maven plugin work with that.
If the ant build can be used to install the lombok.jar to the local maven repository (~/.m2/repository), https://jitpack.io/ might be an option.
I want to cite something I saw here:
Maven has plenty of warts - I learned the hard way never to actually use
-SNAPSHOTin my project versions, because it's the magic "download the internet" keyword that convinces Maven to delete perfectly good JARs and try to download them again - great fun on an airplane or through the great firewall of China - I think that one misfeature causes most of the agony and loathing of Maven out there.
Here is a workaround that I use myself. Every day a release is built and published to bintray from the latest head of this repo.
https://github.com/iherasymenko/lombok-publisher
This pull request #1780 might be some of use here.
We're going to do an edge release very soon using jitpack. The edge release page should then contain a link to the right jitpack page. I've just tested using https://jitpack.io/#org.projectlombok/lombok/master-SNAPSHOT and that worked.
@rspilker Not every build succeeds unfortunately.
I've got
Build starting...
Start: Tue Sep 4 00:11:47 UTC 2018 d1
Git:
v1.18.2-68-gb605415
commit b60541526c7047aff0f4b2a1aac37804913c61de
Author: Reinier Zwitserloot
Date: Tue Sep 4 01:59:22 2018 +0200
running the edge-release task also sets the git tag now.
Running install command:
echo "Running a custom install command";ant install-maven
Running a custom install command
Error: JAVA_HOME is not defined correctly.
We cannot execute /usr/lib/jvm/jdk-10/bin/java
EXIT_CODE=1
2018-09-04T00:11:47.642323307Z
Exit code: 1
No build artifacts found
querying org.projectlombok:lombok:master-SNAPSHOT
at https://jitpack.io/org/projectlombok/lombok/master-v1.18.2-gb605415-68/build.log
We now serve our own snapshot releases!
Most helpful comment
I suggest forgetting about releasing as SNAPSHOTs.
Let's say that you release a new edge today. Then you would name it as lombok-1.16.21.20180517. If you release another one tomorrow, call it lombok-1.16.21.20180518. There are other ways to do that, since you can put whichever number versions that you want.
SNAPSHOT versions are not intended to ever be released. Their purpose is to give some version string for the thing that you are coding right now, which is specially useful when you are coding many different modules at the same time and they have some dependency relationship between them.
Distributing versions tagged as SNAPSHOT in maven repositories is a big no-no. They shouldn't ever leave the local repository in your .m2 folder.