[jira] Moved: (MRPM-31) Support automatic generation of a Yum repository from a Maven repository

> Support automatic generation of a Yum repository from a Maven repository
> ------------------------------------------------------------------------
>
>                 Key: MRPM-31
>                 URL: http://jira.codehaus.org/browse/MRPM-31
>             Project: Mojo RPM Plugin
>          Issue Type: Wish
>          Components: rpm
>            Reporter: Chris Hubick
>
> This is my dream:
> Support the automatic generation of a yum repository from a Maven repository.
> This includes automatic generation of a JPackage style and Fedora Packaging Guidelines compliant RPM/spec for any Maven project.
> This is naturally many requests in one:
> -  It should be possible to use this plugin to generate an RPM without requiring any modifications or additions to that project's POM file.  If it's not required by Maven to build the package, it shouldn't be required by the RPM plugin to distribute it...
> - This plugin should make best guesses for defaulting required RPM values given the type of Maven artifact for the project (ie Category 'Development/Java' for jar packages or 'Networking/Daemons' for war's).
> - Maven metadata should be used by default for things like copyright/license automatically.
> - This includes not requiring the Mapping attribute... the plugin should be smart enough to know "if this artifact's packaging is a jar file, all jar files go in /usr/share/java/" automatically by default, etc.
> - Spec files should include automatic sub-rpms for both Javadocs and source code, and know to generate and place them in /usr/share/javadoc or /usr/src/ automatically by default too.
> - Resulting spec files should be capable of doing an --offline source based build of the project (assuming required mvn plugins already installed, along with any dependencies), and SRPMs should be supplied.
> - Resulting spec files should declare BuildRequires and Requires lines for all dependencies, rather than the current method of bundling them.
> - Spec files should use a standard method for automatically converting any and all groupID+artifactID combinations into unique package names guaranteed to have no collisions among Maven based projects.
> - Spec files should have the appropriate hooks to allow projects like Fedora to do native GCJ compilation and including the resulting native libs in their RPM and adding an appropriate prefix/suffix to the project/versions/release name using only custom RPM macros on their build system and without having to modify any of the spec files.
> - Spec files should be relocatable.
> - Spec files should support parallel side-by-side installation of multiple versions of a project (I did work on this at: https://www.jpackage.org/bugzilla/show_bug.cgi?id=143 ).
> - Spec files should support the cross-linking of Javadocs to any other Maven project based RPM (including Java doc rpm's having Requires decls for the Javadoc RPM's of it's deps).
> This would remove the need for the then redundant JPackage project and their duplication of effort spent on manually writing RPM spec files could be channeled towards creating and updating POM files.