Brett Okken

The rpm version semantics are very important here in determining what can be upgraded and what cannot. The desire of the plugin is to produce SNAPSHOT rpms which can be...

Using the version goal[1] should allow you to coordinate the same SNAPSHOT build version across a multi-module build. This documentation[2] on rpm versions explicitly states that numbers are considered newer...

RPM has different behavior for configuration files. The first option (which is configuration = true), will keep a copy of the existing file with a .rpmold extension during an upgrade...

Have you provided a different classifier for each of the executions? As I recall, that is what is used to separate the work ares. That is also required to actually...

The documentation could be improved. However, what you are trying to do is invalid from a maven perspective. You cannot produce 2 secondary artifacts with the same classifier. That is...

@sc1478, what you are referring to (jar, war, rpm, etc.) are types. Classifiers are simply an additional qualifier to identify/differentiate secondary artifacts. For a java project, 2 common secondary artifacts...

There is documentation on the site covering the versioning logic/strategy. It boils down to creating an rpm version that matches maven semantics as closely as possible and allows rpm updates...

This certainly is not passive, but it is a great improvement to be able to use the sql exception hierarchy.

I agree with @sehrope that clear documentation on what exact syntax rules being supported are.

There is discussion on https://github.com/pgjdbc/pgjdbc/issues/2226. The specific carve out for `byte[]` is mentioned there as a use case which has never been supported, and the primary focus there was the...