> I have my main project which is a package pom type.  It has dependencies, a
> compiler plugin and a war plugin.  Essentially:

This is most likely wrong. Your war projects should use package 'war".

Here is how I would structure this:
top-parent project, packaging pom
module lib with its own pom, packaging jar
module generic-war with its own pom, packaging war, depends on lib
module clienta-war with its own pom, packaging war, depends on generic-war
module clientb-war with its own pom, packaging war, depends on generic-war

Generally you should put all your source code in a module with
packaging jar. You probably want to put code in your War module but
this is not a best practice. I suggested a "lib" jar module above, but
feel free to add more as needed and set up dependencies between them.
These jars are dependencies for your wars.

Then you have a generic-war module with packaging war. This is your
"overlay base".

Then you have client- or environment-specific modules with packaging
war that depend on your generic-war base. By simply specifying the
generic-war as a dependency of these war artifacts, your wars will
automatically get overlaid.

Here's more info and examples that I won't get into here:
http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html

All of these modules should have their own unique artifactIds but they
can share one groupId if that is your preference.

> I can compile and execute the war task to create the war.  It of course is
> missing my per server files.  I presume this is correct so far, but please
> let me know if I am already blowing it.

You are already blowing it. ;-)

You should just be able to type "mvn package" and if the project is a
packaging war, it will automatically pull in the war plugin and create
a war file as output. You should not be specifying "mvn war:war" or
other such commands. The war plugin "knows" when it should execute for
packaging war projects.

>    <parent> //??? Am I suppose to be referencing the main project as a
> parent?

Generally yes you should have 1 top parent and optionally multiple
levels of parents on down to the leaf projects which are jar, war,
ear, and other packaging types.

>    <dependency>  //???Am I suppose to be referencing the main project as a
> dependency here?

This is discussed in depth above.

>                <configuration>
>                    <overlays>
>                        <overlay>
>                            <groupId>com.myproject</groupId>
>                            <artifactId>myartifact</artifactId>

This is should only be necessary if the war module does not list the
overlaid war as a dependency, as I suggested above. You should remove
this.

> I get some dependency error that I don't understand.  I am unclear as to the
> relationship of the two projects.
> Does the main project reference the overlay or vice versa?

Draw up your project on a piece of paper. Sort out the dependencies
topographically. The leaf nodes are where overlays should be
happening.

> Also, what are the steps I am suppose to go through to get this built?
> I am presuming that I install the first project, then package the second
> project?  This is a lot more work than when I used the profiles which was a
> one command process, am I missing something?

You should be able to execute a single "mvn package" command from the
top parent and it should build all of the modules in the proper order
resulting in one or more overlaid war files as you expect.

Honestly you need to slow down, read more documentation, and build
some basic sample projects to have a better handle on the "basics" you
are missing before trying to make this work -- you're dealing with
some advanced concepts and techniques. Here are some suggested
resources:
http://maven.apache.org/articles.html

You are trying to just jump into Maven 201 without doing Maven 101
first. Slow down, do it right, and everything will make more sense to
you.

Wayne

PS- Your note to Ron was not private, if that was your intention.
PPS- Nabble is crap. Please just subscribe to the list via email.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to