Patch to provide new war-overlay type

Why do you need a new packaging type? We do this since years using packaging type jar and add the war as attached artifact with classifier 'webapp'.

Hi Joerg,
Could you clarify what you mean by this? Are you saying that your overlay is set with a packaging type of jar and an additional webapp artifiact is attached that contains the web content? How does the war that wants to use the overlay specify dependencies? Does it need to declare two dependencies for each overlay, one for the jar and one for the “webapp” type?

Is there any documentation or are there examples somewhere of this?

Thanks,
Alex

Does it need to declare two dependencies for each overlay, one for the jar and one for the “webapp” type?

Yes. I've recommended it more than once, e.g. here:
http://www.mailinglistarchive.com/users@maven.apache.org/msg58383.html

The main problem is IMHO not the declaration of the second artifact, but the proper configuration of the war plugin for each case.

1. The webapp should have the resulting jar within its WEB-INF/lib and it should not contain anything in WEB-INF/classes.
2. The assembling webapp must (apart from the declaration of the two dependencies) exclude everything coming from the overlay's WEB-INF/libs, because it calculates its dependencies now on its own.
3. In a cascading build you have to ensure that you don't inherit unwanted overlays, e.g. webapp A is used as overlay for webapp B which is in turn used as overlay for webapp C. You have to ensure that A is not used directly as overlay again in C, because of the now visible dependency tree.

So does your solution address any of this 3 points automatically or do you only spare the declaration of the 2nd artifact?

Hi Joerg,

Thanks for the clarification... in answer to your 3 points:

1) No, overlay's classes end up in WEB-INF/classes as per the currently behaviour.
2) Yes this is catered for as war-overlay doesn't package dependencies into WEB-INF/lib. It assumes that the war packaging will be responsible for creating the final WEB-INF/lib directory. This has the added advantage of keeping overlay artifacts small.
3) I'm not entirely sure what you're getting at here. If projects A & B are war-overlays and project C is a war project. C depends on B and B depends on A then surely both B and A should be overlaid on C?

Let me know what you think.
Thanks,

Alex

OK, it seems you have a slightly different model in mind. I assume now that a war-overlay project from your proposal generates a war file with a jar file extension, that is only used as an overlay in a real war project.

We have actually a different approach. We assemble in our main web application also several other (overlay) web applications i.e. small web applications (modules) that can be used also on their own. Additionally our main web application might be customized in a project and is used there as overlay. Any of those web applications are standard Maven projects producing a jar as main artifact that is also included in the attached web application. As result we have at any time a web application (individual modules, main web application or the customized one) that can be deployed on its own or that can be used again as overlay without loosing the dependency information.

C depends on B and B depends on A then surely both B and A should be overlaid on C?

No, not in our model. If B excludes or overwrites some web resources of A, you want the B version in C. You don't want to have the changes made in B clobbered (or added) by resources from A in C again. Building C you should not really have to know that A exists and you may have to take care for something. However, this case cannot happen in your model, since you use only overlay-wars for overlays.

Hi Joerg,

Indeed it appears that you have a slightly different model in mind. You are correct in that a war-overlay type is not directly deployable. It can only be used when applied as an overlay to a war project. The generation actually creates a jar as the primary artifact (made available on the classpath) and a zip file containing all web content (obviously excluding web-inf/classes as these are in the jar).

For us overlays are about being able to create logical modules to help break up large applications, although we only ever deploy as a whole. It seems your model is more about creating smaller war files that can be developed and tested in isolation before being merged into one large deployable. I can see that there is definitely a case for both scenarios.

Just to clarify my understanding of your scenario, suppose we flesh out the details of A,B,C :

A (war)
 +- /src/main/java/Class1.java
 +- /src/main/webapp/page1
 +- /src/main/webapp/page2
 +- /src/main/webapp/page3
 
B (war)  [depends on A, exclude /page1]
 +- /src/main/java/Class2.java
 +- /src/main/webapp/page3
 +- /src/main/webapp/page4

C (war) [depends on B]
+- /src/main/java/Class3.java
 +- /page5

You would expect the following:

a.jar  (contains Class1.class) 
a-webapp.war (contains page1,page2,page3 and a.jar (in WEB-INF/lib))
b.jar (contains Class2.class)
b-webapp.war (contains page2.page3(from b), page4, a.jar, b.jar)
c.jar (contains Class3.class)
c-webapp.war (contains page2.page3(from b), page4, page5, a.jar, b.jar, c.jar)

I have tried to create a sample project (attached) to replicate this. It almost works except I cannot seem to stop artifacts from A appearing in C.

Our scenario is slightly different in that we do not have the same resource in more than one place:

A (war-overlay)
 +- /src/main/java/Class1.java
 +- /src/main/webapp/page1
 +- /src/main/webapp/page2
 
B (war-overlay)  [depends on A]
 +- /src/main/java/Class2.java
 +- /src/main/webapp/page3
 +- /src/main/webapp/page4

C (war) [depends on B]
 +- /src/main/java/Class3.java
 +- /page5

Creates:

a.waroverlay  (jar contains Class1.class) 
a -webcontent.waroverlay (contains page1,page2 (has no WEB-INF/lib))
b.waroverlay (contains Class2.class)
b-webcontent.waroverlay (contains page3, page4 (has no WEB-INF/lib))
c.war:
  /page1
  /page2  
  /page3
  /page4
  /page5
  /WEB-INF/classes/Class1.class
  /WEB-INF/classes/Class2.class
  /WEB-INF/classes/Class3.class
  /WEB-INF/lib/ <any dependencies> 

I hope that that helps to clarify the differences between the two approaches and hopefully makes the patch a more attractive proposition. BTW are you a committer for maven-war-plugin?

Hi Alex,

You would expect the following:

Exaclty.

It almost works except I cannot seem to stop artifacts from A appearing in C.

Declare A with scope provided in the depMgmt section. We have a global parent POM where all our attached webapps are declared with this scope (and with the version). To use them as overlay, we have to set the scope to runtime in the individual project.

I hope that that helps to clarify the differences between the two approaches and hopefully makes the patch a more attractive proposition.

I just want to be sure, that everyone understands the implicit part of the model. The war plugin supports already different kind of concepts (e.g. it can create a jar from the class files on its own) which has other implications. With all the explanation here it is now clear what is achieved by the patch.

BTW are you a committer for maven-war-plugin?

No, just a long time user.

War overlays example.