[ http://jira.codehaus.org/browse/MNG-2719?page=comments#action_84446 ] Ole Ersoy commented on MNG-2719: --------------------------------
Hey Bob, I kinda got the sense that you were thinking that :-) OK Dud - Here's the deal. This is a plugin for the JPackage project. I'm making it for them because they produce FHS compliant installs of various servers I need. So I could go down the path of just using the current RPM and tweaking it to make sure it does everything I want it to do. But what do I want it to do? What does JPackage want it to do. To answer that I first wrote a document highlighting the design so that JPackage could have input. I wanted to make sure I captured all their requirements and best practices, because the JPackage duds are really good at making RPMs, and I'm just learning as I'm going along here. Which brings me to the next point. I'm learning this as I'm going along. However, I have a very specific architecture in mind for this. I first read the target Maven POM (The one the RPM is being built from) into an EMF model generated entirely from the Maven XML Schema. Why do this instead of using the Maven Model. Because EMF has a lot of capabilities with respect to Derived values, Invarient constraints, generated method bodies, etc. that very useful for generating the Spec file within an architecture that is simple, neat and cutting edge, and is where the center of gravity is as far as modeling goes. It's goooooooooood. Then I take the pom model and map it to a corresponding elements on a model I created to for the JPackage project. It covers their requirements. They suup it up, change the colors, breaks, do whatever, it's indenpendent of Maven completely, and it uses annotations on its attributes to store mappings to the POM, so that the POM mappings can be easily changed. Then this Model is what is fed to a JET template to generate the Spec file. So if I need to update the way the spec file generation, I just update the template and I'm done. Why use the JET? Because there is a lot of tooling and documentation for it, and it integrates well / is built for EMF. So with this design a have a lot of flexibility to make things happen quickly. Look how much effort is required just to get a summary element added to the POM. I'm not talking about the actual effort of adding it, I'm talking about the persuasion part. It's like trying to ripping a steak from a lion. All I want is a summary field....come on man. That has to be simple enough. Lots of people can use it. That should be obvious. Why is this a huge thing? OK Now I gotta finish up this plugin. The main thing to focus on here is the Summary element. No summary element equals lost collaboration opportunities. Please review and understand what I said about that. There has to be a Summary element on the POM or people will be duplicating effort. Cheers, - Ole > Request for Summary element in POM > ---------------------------------- > > Key: MNG-2719 > URL: http://jira.codehaus.org/browse/MNG-2719 > Project: Maven 2 > Issue Type: New Feature > Reporter: Ole Ersoy > Priority: Minor > > If a summary element were added it would make RPM > Spec file generation more efficient, since spec files > "require" both a description and a summary. > A summary element can also be handy for > for other tools that want to generate reports > giving a summary, as well as a longer description > of the project. > If this sounds reasonable I will update the XML Schema for maven with the > summary > element and submit. > Cheers, > - Ole -- 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
