workarea parameter not as documented

[sc1478]

According to http://www.mojohaus.org/rpm-maven-plugin/op-params.html#workarea

Beginning with release 2.0-beta-3, sub-directories will be created within the workarea for each execution of the plugin within a life cycle.

I'm using 2.1.4. That is exactly what I'm doing, but the plugin does not behave that way. At least not for the attached-rpm goal.

I have this setup:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>rpm-maven-plugin</artifactId>
    <version>2.1.4</version>
    <executions>
        <execution>
            <id>attach-is-rpm</id>
            <goals>
                <goal>attached-rpm</goal>
            </goals>
            <configuration>
                ... (execution specific configs)
            </configuration>

        </execution>
        <execution>
            <id>attach-rs-rpm</id>
            <goals>
                <goal>attached-rpm</goal>
            </goals>
            <configuration>
                ... (execution specific configs)
            </configuration>
        </execution>

    </executions>
    <configuration>
        ... (common configs)
    </configuration>
</plugin>

Instead, I get this:

[INFO] --- rpm-maven-plugin:2.1.4:attached-rpm (attach-is-rpm) @ MyProj ---
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/BUILD
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/RPMS
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/SOURCES
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/SPECS
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/SRPMS
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/tmp-buildroot
[INFO] Creating directory /myproj/target/checkout/target/rpm/gensms/buildroot
...
[INFO] --- rpm-maven-plugin:2.1.4:attached-rpm (attach-rs-rpm) @ MyProj ---
[INFO] Directory /myproj/target/checkout/target/rpm/gensms/BUILD already exists. Deleting all contents.
[INFO] Directory /myproj/target/checkout/target/rpm/gensms/RPMS already exists. Deleting all contents.
[INFO] Directory /myproj/target/checkout/target/rpm/gensms/SOURCES already exists. Deleting all contents.
[INFO] Directory /myproj/target/checkout/target/rpm/gensms/SPECS already exists. Deleting all contents.
[INFO] Directory /myproj/target/checkout/target/rpm/gensms/SRPMS already exists. Deleting all contents.
[INFO] Directory /myproj/target/checkout/target/rpm/gensms/tmp-buildroot already exists. Deleting all contents.

Therefore the is-rpm is deleted before anything can be done with it. Instead of using a subdirectory of the workarea for each execution, it's just using the workarea for both executions.

[dantran]

@sc1478 A full sample project is very much appreciated. the ITs should have an existing sample you can reuse

[bokken]

Have you provided a different classifier for each of the executions? As I recall, that is what is used to separate the work ares. That is also required to actually attach unique secondary artifacts to your project.

[sc1478]

@bokken - I am reluctant to use different classifiers because they will have side-effects with on a pre-existing naming scheme I am trying to achieve. Rather than doing that, I would just specify different <workarea>s in the two executions. That is a more straightforward solution in my case since it only affects workareas and nothing else.

If what you say is correct, then the documentation is wrong or incomplete. If using different classifiers is required to get the new post-2.0-beta-3 solution to work, the documentation should say so.

@dantran - If bokken is correct then there is nothing to solve here but documentation. If you still want me to whip up a simple sample, I can. But this is already not an issue for me, as we have adopted an entirely different approach, and I won't spend the time unless you really think it might help

[bokken]

The documentation could be improved. However, what you are trying to do is invalid from a maven perspective. You cannot produce 2 secondary artifacts with the same classifier. That is not a limitation introduced by the rpm plugin. The rpm plugin may be failing (effectively) earlier in the lifecycle, but the failure is still rooted in an invalid configuration.

[sc1478]

@bokken -

This is interesting.

Taking your statement as authoritative (I've been impressed by your knowledge here and elsewhere), it appears that this plugin, and in particular, the <workarea> parameter, provides a way to create "invalid" maven poms. I have done it. Simply by creating two executions, with different workareas and differing only by <release> it is possible to create two rpms without different classifications. And with some work, it is possible to create rpms with a different naming convention than standard Maven allows.

Now why would I go to all this effort to "subvert" the maven standards in this way? I am trying to shoehorn an ancient build and version control system used by our department (a small organization within a large corporation) into the more modern Maven world.

It is common in this system to create several rpms in the same project and directory structure. Typically this would be to create projects related, not by source code but by "server type", an important concept in our system. There might be an application deployed on a "content server" running Tomcat or WebLogic that requires a database schema for a "database server". Deploying the latter creates or modifies the database tables needed by the former. And there are several other "server types" involved, I won't bore you with details.

This organization has "hijacked" the rpm "release" concept to define different "versions" of the rpm for different server types. There is an enormous amount of established practice and custom within the organization that is based on this. And yet the system is creaky and old, and needs to be replaced with something better. Before too long, it may have to be replaced by corporate edict.

This was an initial effort to bridge the two systems and bring the organization toward a more modern system. In this particular instance I found another way to achieve this, and have abandoned this particular effort.

But this "requirement" will be back, I have no doubt, as this effort expands.

I don't like to fly so contrary to what the framework demands. It makes everything harder than it should be. "convention over configuration" and all that. I get it.

So I want to ask you this question: given these requirements:

1) RPMs will continue to be the way this organization delivers software components, be they jar files, war files, Oracle DDL script collections, shell scripts, etc. It offers many advantages.

2) Related collections of such code for different server types must live under a single overarching project.

3) Based on the above, we need to create several rpm files in each project for different server types that may be required, which flies against the "classifier concept" which influences the naming of build products, in particular, file extensions.

What is the best way to do this under Maven?

[sc1478]

Okay, I've looked into classifiers more and I've found an answer that's not invalid by Maven standards and yet allows me to created rpms via the plugin that comport well with my organization's naming standards.

I had previously been under the erroneous assumption that classifiers were limited to well known names like jar, war, rpm, noarch. Not true. The "server type" concept can be woven into the classifier just as easily, so I can have cs.noarch, ds.noarch, etc. and live more harmoniously with Maven's expectations.

[dantran]

@sc1478 nice to know it works out for you

[bokken]

@sc1478, what you are referring to (jar, war, rpm, etc.) are types. Classifiers are simply an additional qualifier to identify/differentiate secondary artifacts. For a java project, 2 common secondary artifacts are sources and javadoc. Each are stored with a type of jar.

In the rpm space, my guess would be that classifiers are often used for os and/or architecture distinctions (when multiple are supported). Regardless of the classifier, the type will still be rpm.

I am glad that you have a found a solution which works for you.