Request for Summary element in POM

can't we use description and shortDescription for this?

The working RPM mojo in the Mojo sandbox uses $

as the default for the long description and $

for the default one-line summary. If these are not suitable, they can be overridden in the plugin's configuration. Can't you do something like that instead of changing the POM schema?

If there is a shortDescription element already,I think that would be
the most ideal thing to map to...but I don't see one in the Schema?

Name I think suggests something a lot different from than summary.

I'm trying to make the process as clean and simple as possible.

Right now I have a summary property on the EMF model that I'm mapping the Maven pom to,
and if the Maven Schema / Model had a summary element then this would make the collaboration
between RPM packagers and builds that use Maven more streamlined and clean.

Here's what could happen if there is no summary or short description field in Maven.

The RPM Packager wants to set the Spec Headings.

She gets to the Summary heading of the Spec.

What should it map to. The people that own the build did not really
put a suitable value in the in the POM she feels, so she just enters
a value in manually in the JPackage RPM generator project.

This project is completely separate from the original build.

It's artifact is an RPM and SRPM only.

So in short:

She has to do more work, because the POM does not have what she needs.

Now if the POM had a summar element it could be that the
owners of the POM filled it in and she could use it.

But suppose they did not.

If she fills it it, it's likely that she wants it maintained on the POM and that
she'll contact the pom owners to have it added.

This streamlines the work and captures it.

That's the goal.

It's a fairly minor thing, but when multiplied by all the Maven projects out there
it could represent a substantial saving in effort.

Then when you start to consider other capabilities that could benefit
from the Summary element as well, like reporting, the benefits multiply.

I think the RPM plugin covers almost anything you would want to do with RPMs, and is configured entirely within the POM. I am wondering why you are not using the RPM plugin that is already built and working for a number of people. From the process description you supplied, it sounds like a completely manual process requiring projects separate from the ones which have the items to be packaged. That doesn't sound very streamlined to me. By placing all of the RPM creation information in the POM of the project containing the items to be packaged, the RPM plugin sounds much more streamlined.

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

Oh - Whoops - Forgot one thing.

This plugin produces RPMs.

RPM production should have it's
own project. Maven projects focus
on producing specific things.

Some produce jars, some produce wars,
some produce documentation, this one
produces RPMs.

This way duds that are concerned about
the installer can work independently
of the duds concerned about lines of code.

The duds doing the coding have their project,
the duds doing the installer have theirs.

Now the duds doing the installer just add
the installer project as a module to the parent
project with a dependency on the target being installed,
and the whole thing streamlined.

Hey Bob,

I looked at the Maven RPM to figure out some things.

Incidentally I think I have a shorter explanation for why
I built one myself first. It was so that I can compare the two approaches.

Anyways, the Maven RPM looks really smart in a lot of ways,
so if you want to I'd be glad to work with you to see how we can combine the
two.

I also need a lot of the todo's mentioned on the Maven RPM Mojo page within
codehaus, so I can go to town on those as well.

Let me know what you think.

Cheers,

• Ole

I think that adding to the existing RPM plugin makes a lot of sense. Why don't you close this issue as "Won't Fix" and open one (or more) for the RPM plugin which describes the changes that need to be made. We can then work off of those issues to get everything resolved.

I prefer to keep this issue
and any RPMMojo changes completely
separate. I already have summary
element on the mojo configuration of the
model that is used to create the Spec file,
but that summary element should map to a summary
element on the pom so that collaboration between
packagers and developers is simplified and streamlined,
with maximum clearity with respect to what maps to what.

Also I have already proposed one solution as to how
new elements can be added quickly to the pom, without
breaking backward compatibility.

http://jira.codehaus.org/browse/MNG-1437

I think Jason is concerned that this could require rework on other
Maven components that reference the Modello generated model directly,
instead of the using the Plexus container, so I'll probably have to create a new
Maven concept to examine whether this is true or not, and showing how to close the gap.

Allthough breaking those components should be done anyways, so that they
become inspired to use the
Plexus container.
If we wanna make an omellete we gotta break a few eggs.

I'm already in the process of merging
some of the elements of the existing RPM
mojo into the new mojo.

Thus this mojo eclipse's the features of the old one.

Some of things in the mojo I created are there for the purpose
of working with other mojo's in a model driven development context.

Plus they are needed for some other work I'm doing with respect
to setting up RPM repositories that mirror the Maven repository, while
ensuring that Maven best practices are met.

So what this means is that in order for the two to be merged, some leg work is required
on your part.

I'm going to publish a developer use case, and user use case document
for the plugin.

You will have to review this and understand the design changed, to see whether you
are comfortable with the changes targeted at the developer use cases.

Assuming you are fine with these, then I'll make sure the elements from the RPM mojo
you created are merged into this mojo.

The changes to the end user are fairly transparent.

Instead of the Mapping elements being contained in the POM,
they are moved to a different document that also targets a specific
POM.

Cheers,

• Ole

Actually,

There's an other alternative as well.

I'm guessing your primary concern is that the introduction
if the mojo I just created could fork developer attention,
thus some ot the todo's on the current RPM mojo don't get done as quickly.

I don't mind at all implementing those on my mojo, and then transferring them to yours
as well. I'm already pretty familiar with the Codehaus RPM mojo.

I think paralell mojo development might make sense in this case, since yours might
satisfy the needs of developers that want to keep the mapping elements within
the existing project, and mine Packagers who want a separate project.

Cheers,

• Ole

The RPM plugin in Codehaus handles being in a separate project quite nicely. I really don't see a need for a second plugin.

Oh OK - Great.

It could be then that there are only architectural differences.

I'm intending to use the one I built in the larger context
of the

RPM Creation and Quality Control Automation effort I have
proposed on the mailing list, but I'm not saying that anyone else has to use it.

It could be that both produce the same end result, and then everyone has a choice.

One of the reasons I'm sticking with the EMF model generation is that it generates
the baseline for the eclipse plugin that goes along with pom2spec mapping, so that
we have a leg up on the corresponding eclipse work as well.

Anyways, I'll publish all this soon, so that we have a clearer context for discussing
various approaches and corresponding user and developer use case scenarios.

Cheers,

• Ole