Release non-SNAPSHOT lastnpe.org artifacts to Maven central (regularly, on predicatable schedule)

[ctron]

Regarding the null augments, I think it would make sense to have some sort of rolling-updates. If there was a change to the repository, then for e.g. every month, there should be a new version.

[vorburger]

@ctron I'm in favour of this (and perhaps using 2017.10.0 like release numbering instead of 1.0.0; because it will probably anyway be hard to do real semver across all EEA, but a bit reluctant to "commit" to doing this, or doing it alone.. ;-) also because I'm assuming that you have Maven central releases in mind here, just just changing <version> in pom.xml every month? So if we did say we were going to do this, would you be willing to help with this, every month (sure you have the time?), including pushing to Maven central? Anf if yes, do you know practically how both e.g. you and I (and perhaps in the future a few others as well) can all be enabled to push to Maven central for this project? You may have seen that I can and have (once, for test) - but I've no idea what to do to "permit" you to as well...

@maggu2810 @kwin @sylvainlaurent @kaikreuzer FYI! (And your comments welcome, of course.)

[kwin]

Maybe the approach outlined at http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/ would be an option. That way you would give the release version just as Maven parameter to the CLI build. No need for changing the poms with every release.

[ctron]

@vorburger I am happy to help here. Doing a release on Maven Central doesn't take more than 10 minutes if you have the process setup up properly. It shouldn't be more than mvn release:prepare release:perform, manually checking and clicking in the OSSRH webpage after that. So I definitely can help here.

I also really like the idea of the version schema you suggested. That should do the trick. And we only need to make a release if we had any changes in the month. From what I know you can file a ticket at https://issues.sonatype.org and let Sonatype process that.

@kwin I am not sure you can actually release on maven central with this approach.

[vorburger]

@ctron I've given this a bit more thought since above, and concluded that because I'm still very much evaluating whether or not to push for JDT null analysis in the project I currently spend most of my time on (ODL), and ATM still finding a number of problems with it TBH, I would not be able to publicly commit to doing monthly releases for this community yet - even if it's just "just a command and check and click" - it's still a sort of engagement and creates an expectation which I would not want to create yet and then disappoint.

I AM (very much) hoping to conclude my testing in the sense that the benefit of JDT null analysis is worth the effort (for ODL). At that point I would be keen to release to central, and release often, to use this "in production" (at ODL). As of right now though, this is not a top priority for me, yet. If we did see loads of people contributing lot of EEA, that could change, but as of today I'm still pushing most of the EEA anyway... 😺

Now, having said that, it's still not too early for me if you want to pursue this anyway! So if you (not me) want to open a Sonatype ticket requesting permission to push into "my" org.lastnpe namespace, refering to my original https://issues.sonatype.org/browse/OSSRH-26693 and linking to this issue as "proof" that I'm perfectly OK with you @ctron taking this initiative, then ... go for it!! (You'll also have to raise PRs to adjust the version numbers, of course. Perhaps harmonizing the currently still a bit divergent version numbers between examples/ and libraries/ and their respective would be in order as well.)

PS: One thing we perhaps should give some more thought to is whether or not you want to version this entire repo with rolling monthly version numbers, or separately release individual libraries? If you think ahead, something like say... our Guava EEA should (normally) "stabilize" at some point. Do you anticipate still pushing new versions of it every month, without changes? They're small, so it's not a huge issue. Release Notes (as simple as a CHANGES.md file? auto generated would be neat..) could / should specify what's really new where?

[ctron]

So what I can definitely do is offer to push out a release every now and then. As I am also not seriously using EEAs, I do understand your dilemma. However I think that this also is a chicken and egg problem.

I could think is going for a trail period of 6 months. Going for the simply approach. Releasing everything and that is it. I don't think adding a few redundant versions of Maven Central hurt anyone. But being able to do an "all in one" release and being able to have a POM file which only specifies one version for all EEAs is probably helpful too. And there is no need to write any tools 😉

I am not sure the approach of linking to this issue will work. I guess it would be best if you simply raise a new ticket and ask for adding "ctron" to the lastnpe namespace.

[vorburger]

@ctron sorry for the delay, but I've now finally opened https://issues.sonatype.org/browse/OSSRH-35441

[triller-telekom]

In the Eclipse SmartHome project we are currently discussing how to best integrate external annotations, see: eclipse-archived/smarthome#4321 (comment)

My idea is in this PR: eclipse-archived/smarthome#4513

So basically what I would like from this project here is ONE zip file containing ALL eea's on ONE url that is valid all the time. Possibly something like linux distributions are doing all the time by using symbolic links: last-npe-eeas-latest.zip pointing to last-npe-eeas-2017-11-07.zip

That way I could include the URL http://www.whatever.tld/path/last-npe-eeas-latest.zip in our pom.xml which downloads it in the maven initialize phase and places it in the local filesystem to be accessed by the eclipse-jdt compiler. Also our Eclipse IDE setup would use a setup task that has a "Ressource Copy" which dowloads and copies the file into the local file system where all projects can use it in their "external annotation path".

The reason behind using a zip file instead of a folder where one could use the IDE to add additional annotations is that we would like to have these annotations as somehow read-only for the every day developer that just wants to code for ESH and do not want to bother them with having an additional project in the IDE that contains the eea files. Also all developers should have the same zip file with the same up-to-date version of the eeas.

Does that sound like a valid idea? Or am I thinking in the wrong direction?

[vorburger]

@triller-telekom thanks for your interest in LastNPE.org !

Re. "ONE zip file containing ALL eea's on ONE" I like that, see new #51.

Re. including the URL in your project's pom.xml, you could do that and knock yourself out having fun - but why use a HTTP URL DL when you have Maven? ;-) See how this is done in examples/maven/parent/pom.xml - that works great, thanks to the <dependency> and <annotationpath>CLASSPATH.

Re. your Eclipse IDE setup would use a setup task that has a "Ressource Copy", you can have fun and do that of course, but this overlaps with what eclipse-external-annotations-m2e-plugin can do for you - have you seen that? That Eclipse plugin treats EEA JARs as just another Maven artifact, and works both if the annotations are open in a project (through M2E's "workspace resolution") or as JAR in ~/.m2 - just like any other Maven dependency.

PS: Let us keep this issue focused on releasing non-SNAPSHOT lastnpe.org artifacts to Maven central, and have other issues or (better) PRs for other new ideas, or discussions about new ideas.

[maggu2810]

The lastnpe page states "regularly publishes those EEA to Maven central" the one I found (https://search.maven.org/search?q=org.lastnpe) are very old 02-DEC-2016.
Where can I find the latest published EEAs?

[vorburger]

@maggu2810 if I'm not totally mistaken, those were manually mvn deploy'd, by me, back on 02-Dec-2016. The goal of this issue here was to automate it, but we never did that. I cannot commit to manually doing monthly releases for this project, and am currently not set up anymore do this in 30s unfortunately.

@ctron in https://issues.sonatype.org/browse/OSSRH-35441 got access to push to the org.lastnpe namespace on Maven central... perhaps he would like to do a manual push of the latest state of this repo?

Beyond that, there are 2 ways forward: I'm happy to open more tickets like https://issues.sonatype.org/browse/OSSRH-35441 to grant anyone who is already a current committer on this project the same privilege to be able to manually push to Maven central - just comment here, clarifying the login ID you use on Sonatype, and I'll raise another ticket with them like I had for @ctron in Oct 2017.

Ideally though, someone should work on setting up an automated (e.g. monthly) scheduled mvn deploy from TravisCI. http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/ looks like a nice idea. Unfortunately I really don't have the time to help set this up - but I'll support anyone wanting to do this however I can.

[maggu2810]

Perhaps it would make sense to remove the "regularly publishes ... to Maven central" message from the page if there are no ones.

I don't have any time to spend here, sorry.

I just integrated the EEA usage to a project and looked at the current state of your EEAs.

[ctron]

Ok, I am trying a release right now. And see how this works out.

[ctron]

Ok, first question I run into: release as what version? Currently it says "1.0.0", the last release on Maven central was "0.0.1", and one module as "1.0.0".

[vorburger]

Jens, your call, but how about simply v0.0.2?

…

[ctron]

Sounds good. I am having a bit of trouble releasing, as the master branch is locked (which I am not questioning). The question to me is just, "how" to release in that mode. Does it make sense to switch to a non-protected release branch?

[ZeeD]

Is there still work on publishing artifacts on maven central?

[vorburger]

Only if YOU would be interested in doing such work... ;-)

…

[J-N-K]

This can be closed, new annotations are release within a short timeframe after they are merged. There is no point in re-relasing unchanged annotations to have a regular cycle.