Inherit RPM dependencies from POM dependencies

This is an interesting idea.

It seems like there is no current duplication of effort. That is, no one would currently list a dependency on an RPM.

Would we be able to accurately determine the rpm "package" name to include? It may be more appropriate to declare the "requires" onto one of the "virtual packages" that the dependent rpm "provides."

What to do with versions. Typically, best practice in maven dictates using specific versions and not version ranges. Does that really make sense for RPMs?

You probably would want a switch in the module to handle the versions differently.
We include just the package name in dependencies for RPMs.

Leave the ability to declare the depencies like you have it today.
Add the ability to inherit the depencies from the project dependencies with version numbers or without. This is the fun part

This is exactly what we need. We're dealing with a lot of artefacts and a lot of dependencies. All these artefacts need to be installed on RedHat system, so RPM is a good choice. Since Maven has all the dependency information, mapping it on RPM Requires seems like a logical step. We don't want to include all dependencies in each RPM!

The dependency information must be in the pom. The question is should it be in the <dependencies> section or in the <configuration> section of the rpm plugin.

The <dependencies> section indicates artifacts required to build the current artifact. They are not used to indicate other assemblies that are present at runtime. (The provided scope is kind of an exception to this. But in a java project, for example, a provided dependency marks a dependency that is needed either directly or transitively to compile.)

Much like maven, rpm only requires direct dependencies to be listed. There is no need to list transitive dependencies. So I am not quite sure I see what the benefit is of using the <dependencies> section rather than the <configuration> section. How do you envision this working and what is the advantage?

The dependency (direct dep's no transitive) information should be part of the pom, cause that's the Maven way...but i wouldn't close the way via <configuration>.

I would like to see it in the pom, cause currently i'm already using dependencies between RPM's...so the logical next step will be to put the dependency into the RPM Requires. The result is a large .tar.gz which contains all RPM's.

Based on that a word about the version which might go into the RPM-Requires. Currently Maven handles versions in a particular way (best practise is to fix the versions in pom's)....so the first step might be to put the exact version into the requires section for the RPM..but this would result in a problem with a larger system which comprises of e.g. hundredths of RPM's (let use assume version 1.0). If there are dependencies defined between them it can be very complicated to replace one RPM's e.g. with version 1.0.1 (based on a Bug fix)...so it should be possible to define either name only or name plus version (which goes into the required area for the RPM).

"The result is a large .tar.gz which contains all RPM's." This sounds like a completely different artifact (with its own pom).
And even that case, how do you pick (and configure the assembly plugin) as to which transitive dependencies to include (rpms, jars, wars, zips, .tar.gzs, etc.)? Remember that rpm projects almost certainly have actual build time dependencies (something has to go in the rpm).

I admit I may be slow, but I am missing the use case. Why would my rpm project my-tomcat-assembly have a build time dependency (which is what <dependencies> section is for) on my-http-server.rpm? What from my-http-server.rpm do I need to /build/ my-tomcat-assembly.rpm?

I cannot think of a single use case to have data duplicated in <dependencies> and rpm.<configuration>.<requires>.

What am I missing?