[
http://jira.codehaus.org/browse/MOJO-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Okken closed MOJO-968.
----------------------------
Resolution: Won't Fix
Creating a YUM repo is out of scope for this plugin.
Please log individual requests for other items. Patches and tests are always
welcome.
> Support automatic generation of a Yum repository from a Maven repository
> ------------------------------------------------------------------------
>
> Key: MOJO-968
> URL: http://jira.codehaus.org/browse/MOJO-968
> Project: Mojo
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
