I don't think we want this, do we? This makes these examples part of the overall release build (which definitely messed things up before.

It doesn't get deployed because the parent has <skip>true</true> in the the deploy plugin. What else could go wrong?

The maven release plugin looks for these strings and replaces them every time you run a release.

The trick is to not make your modules break if the project version changes. I don't think this one will. It looks safe to me.

I explicitly pulled this out last time I did a release because I didn't want these included in the release.

This isn't anything to do with a release. It's just a property that is used to specify a dependency.

The maven release plugin pulls in everything that is referenced by the top level POM (at least it did the last time I ran a release) so including these as sub-modules for this pom causes them to get pulled into a release.

You can switch off plugins with skip=true (as is done for the deploy plugin in the examples here). But that's probably not what you want - you want to just make sure that the projects don't break if their artifact version changes. I'm pretty sure these ones don't now. The problem is that without this change nothing in the examples is built automatically from the top level, so it's easy to miss something important when refactoring.

The problem is that without this change nothing in the examples is built automatically from the top level, so it's easy to miss something important when refactoring.

my IDE (intellj-idea) won't build the examples unless applying some tricky manual configuration. i suppose we can explicitly skip the deploying steps for the release plugin here's an example configuration

Actually I don't know because I don't know how the release was performed. Is there a script or something? I don't see it in the Github actions.

This is strange, for instance, given that I believe the release plugin has been used: https://github.com/kubernetes-client/java/blob/master/pom.xml#L421 (<skip>true</skip> in the parent). I'm not sure that's a good idea. But mvn deploy would work, once the versions were set up correctly. Personally I don't find the release plugin very useful, but if you do want to use it, probably it's best not to disable it at the top level?

@dsyer

The current release process is documented here:
https://github.com/kubernetes-client/java/blob/master/RELEASES.md

I'm definitely open to suggestions about changing/improving the release process, especially if it included a GitHub action for continuous snapshot releases. I currently find the release process quite cumbersome.

Happy for someone who is more knowledgeable than me about releasing things via Maven take a look. What we have was cobbled together by amateurs :)

A GitHub Action for snapshots would be excellent, but I don't think it's within the scope of this PR. You can easily set one up if you have permission to deploy snapshots somewhere. You could probably ask Sonatype for permission based on whatever credentials you use for the releases.

It looks like there is a bug in the release plugin (https://issues.apache.org/jira/browse/MRELEASE-799) which makes the examples a bit awkward to configure - they have to use a hard-coded version for the kubernetes-api dependencies. That seems like a small price to pay to get this whole thing working properly. (IMO the examples for older versions should just be in a branch in git, but we discussed that before and you didn't agree, so we have to work with this.)

My latest change includes a workaround for that bug, and I tested it by running mvn release:prepare (which failed when it tried to git push the change, but that's expected since I don't have permission).

+1 it will be great if we can publish snapshots on a daily basis via GH actions automatically