war plugin cannot add other files to web-inf without workaround

do you really need this?

struts-config.xml can live directly in WEB-INF to start with.

If you want to filter it as a resource, you can always use the standard resources and have it in /WEB-INF/classes, which you can then reference in web.xml instead.

If you are transforming struts-config.xml with XSLT, you'll need maven.xml anyway, and you can probably do that in place on target/webappname/WEB-INF

What do you think?

I think it would be helpful.
Consider the xdoclet plugin that allows you to create a struts-config via xdoclets. If you were to have the resulting file sent to the src\webapps\web-inf it would confuse cvs on commits.
If you were to have it redirect to the target/artifactId/WEB-INF directory then it would require a postGoal (or pre war:webapp goal) that adds it there.

I'm not sure I see what you think the xdoclet plugin should do in this case?

As for CVS confusion... .cvsignore But this just makes it a preGoal rather than a postGoal.

Jason - you've talked about removing pre/postGoal support in plugins - is this a possible use case for it? How would you hook xdoclet in between war:webapp and war:war using any other techniques than a postGoal on war:webapp?

War plugin works in stages:

1. war:webapp goal is coping the files into $

This way of processing is maybe not optimal from the point of view of performance but gives
a full flexibility and IMHO it is fast enough.
ant:copy task takes into consideration the date of the last modification of the file
and only modified files are copied from $

to $

Michal

Thanks Michal. But that's exactly what I was talking about.
But that kind of work around in my mind isn't suffering from performance but rather from the concept of what war plugin should do. A valid war can have multiple files directly under WEB-INF. I know that this is supported in the sense that webapps/WEB-INF files can be incorporated but for autogenerated files this is not where they usually reside. I'm sure it's more of a question of preference and I don't want it to become a religious debate but it would be nice to have this functionality (hence the improvement type

Well I was using xdoclet and my own generator and I was able to instruct them both to generate their stuff into
$

I don't remember details but I think that it is as simple as

changing from:
maven.xdoclet.webdoclet.destDir=$

/xdoclet/webdoclet/WEB-INF

to:
maven.xdoclet.webdoclet.destDir=$

=$

/webapps/my_application

I don't see what's more you might need...

Michal

I'm not sure how you can do that unless you also declare
maven.war.webapp.dir in your project.properties before the struts stuff.
Remember that xdoclet generation must occur before the war plugin starts to process and therefore if you have just that it would evaluate to
C:\WEB-INF (on windows) because it can't find a definition for maven.war.webapp.dir.

Also keep in mind that my using xdoclet generation was an example. I meant for any type of generation.

EXTERNAL MESSAGE:
SUBJECT: RE: [jira] Commented: (MPWAR-16) war plugin cannot add other files to web-inf without workaround
Thanks Michal. But that's exactly what I was talking about.
But that kind of work around in my mind isn't suffering from performance
but rather from the concept of what war plugin should do. A valid war
can have multiple files directly under WEB-INF. I know that this is
supported in the sense that webapps/WEB-INF files can be incorporated
but for autogenerated files this is not where they usually reside. I'm
sure it's more of a question of preference and I don't want it to become
a religious debate but it would be nice to have this functionality
(hence the enhancement priority

Tim Chen
tchen@tampabay.rr.com

----Original Message----
From: jira@codehaus.org jira@codehaus.org
Sent: Thursday, January 15, 2004 3:26 AM
To: tchen@tampabay.rr.com
Subject: [jira] Commented: (MPWAR-16) war plugin cannot add other files
to web-inf without workaround

The following comment has been added to this issue:

Author: Michal Maczka
Created: Thu, 15 Jan 2004 2:25 AM
Body:
War plugin works in stages:

1. war:webapp goal is coping the files into $

This way of processing is maybe not optimal from the point of view of
performance but gives
a full flexibility and IMHO it is fast enough.
ant:copy task takes into consideration the date of the last
modification of the file and only modified files are copied from
$

to $

Michal
---------------------------------------------------------------------
View the issue:

http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPWAR-16

Here is an overview of the issue:
---------------------------------------------------------------------
Key: MPWAR-16
Summary: war plugin cannot add other files to web-inf without
workaround
Type: Improvement

Status: Open
Priority: Major

Original Estimate: 30 minutes
Time Spent: Unknown
Remaining: 30 minutes

Project: maven-war-plugin

Assignee: Jason van Zyl
Reporter: Tim Chen

Created: Wed, 14 Jan 2004 4:33 PM
Updated: Thu, 15 Jan 2004 2:25 AM
Environment: maven 1.0 rc-1
war plugin 1.4 and 1.5 SNAPSHOT

Description:
Consider a struts war which might have:

WEB-INF/
web.xml
struts-config.xml

The current war plugin does not allow you to copy struts-config.xml into
WEB-INF without a maven.xml postgoal hack.

A possible patch would be to add the following to war:webapp

<ant:copy todir="$

">
<ant:fileset dir="$

"
includes="$

"
excludes="$

"/>
</ant:copy>

an example project.properties using this would be: maven.xdoc.date=left
maven.xdoc.version=$

maven.multiproject.type=war

maven.xdoclet.webdoclet.destDir=$

/xdoclet/webdoclet/WEB
-INF
maven.xdoclet.webdoclet.mergeDir=$

/merg
e
maven.xdoclet.webdoclet.jsptaglib.0=false

maven.war.src=$

maven.war.webxml=$

maven.war.webxml.src.includes=struts*.xml

The proposed patch could be enhanced by ignoring web.xml if it is in the
same directory etc.

---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira