Cool - Why don't we take a look together a little later on, as soon as I get all the mappings finished up?
Here's a brief overview of the approach I'm using: - Create an Ecore (Eclipse EMF Project) of the parameters that the Spec file needs - Set defaults that are specific to the JPackage project (Like Vendor, etc.) (These can be changed simply by opening the ecore xml document, changing the default parameters, and regenerating the model) - Store Annotations that map the spec header model attributes to their corresponding pom elements (I wrote a how cookbook "page" on how to read these annotations) - This way the mapping can be updated simply by changing the value of a fragment and regenerating the model. - The same EMF model is also used to generate an Eclipse editor that can be used to edit the model. I'm also writing a Maven POM structuring best practices mojo that reviews a build analyzing the structure of dependencies, etc. and make recommendations such that the build poms conform to what the JPackage RPM generator expects the structure to look like in order to get a "clean/valid" spec. Right now I'm mainly working on dependencies, but the same will add support for plugin analysis later as well. --- Bob Allison <[EMAIL PROTECTED]> wrote: > The reason I mentioned it is that the plugin WRITES > the spec file it uses. > You might want to see how I mapped POM elements into > the spec file. There > is likely to be a difference in how we are doing > things, in which case it > would be good to use a uniform mapping of elements. > > ----- Original Message ----- > From: "Ole Ersoy" <[EMAIL PROTECTED]> > To: "Maven Developers List" <dev@maven.apache.org> > Sent: Monday, December 25, 2006 9:25 PM > Subject: Re: Request for Summary element in POM > > > > Hey Bob, > > > > Thanks for the tip. I'll probably have a look > later > > for comparison of my approach vs. that mojo's > > approach. Perhaps an even better mojo could be > made > > from the combination of the two approaches :-) > > > > I'm using Eclipse's EMF project that allows me to > > easily map various POM elements to their > corresponding > > spec values using fragment path annotations > > on the SpecDescriptor ecore model I created. I > wanted > > to see whether would lean to a cleaner overall and > > more manageable design. > > > > Anyways, > > > > Regardless of which mojo is used to generate the > spec, > > a Summary element on the POM would still be very > > useful. > > > > I could just put it on the SpecDescriptor model, > but > > then the JPackage project, and any other project, > that > > wants to generate RPMs using Maven would > > need to provide this value outside of Maven. > > > > This means that someone other than the original > > project creator is providing the summary or > > description on the spec file, which equals less > > collaboration / consensus between the original > project > > creator and the spec writer. > > > > Cheers, > > - Ole > > > > > > --- Bob Allison <[EMAIL PROTECTED]> > wrote: > > > >> You might take a look at the RPM plugin in the > Mojo > >> sandbox... > >> > >> ----- Original Message ----- > >> From: "Ole Ersoy" <[EMAIL PROTECTED]> > >> To: "Maven Developers List" > <dev@maven.apache.org> > >> Sent: Sunday, December 24, 2006 4:38 PM > >> Subject: Request for Summary element in POM > >> > >> > >> > Hi, > >> > > >> > I'm in the process of releasing an RPM Spec > >> generator > >> > for the JPackage project, and noticed that > there > >> is a > >> > description element in the pom, but no summary > >> > element. > >> > > >> > If a summary element were added it would make > >> JPackage > >> > spec generation more efficient, assuming > various > >> > projects would put both elements to use. > >> > > >> > Can we add a summary element to the pom? > >> > > >> > I think this would be a convienent element to > have > >> > >> > in the sense that description could now be more > of > >> a > >> > detailed description and the summary...well a > >> summary > >> > :-) > >> > > >> > I could put a JIRA in for this and update the > xml > >> > schema if this sounds reasonable. > >> > > >> > Thanks, > >> > - Ole > >> > > >> > > >> > > >> > > __________________________________________________ > >> > Do You Yahoo!? > >> > Tired of spam? Yahoo! Mail has the best spam > >> protection around > >> > http://mail.yahoo.com > >> > > >> > > >> > > > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: > >> [EMAIL PROTECTED] > >> > For additional commands, e-mail: > >> [EMAIL PROTECTED] > >> > > >> > >> > >> > > > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: > >> [EMAIL PROTECTED] > >> For additional commands, e-mail: > >> [EMAIL PROTECTED] > >> > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
