ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rosenbaum, Thomas" <>
Subject JAR Manifest - default vs. custom
Date Wed, 22 Jun 2005 22:25:30 GMT
Hello all,

I am wondering if anyone has any ideas on how to better solve this ANT
issue ...  

My constraint is that I need a single build file (driven by a single,
main project properties file) to process/package any number of different
J2EE projects.  In all aspects this is working quite well, EXCEPT - some
projects need to specify custom MANIFEST.MF files for the EJB-jar and
WAR archives, while other projects simply need the default MANIFEST.MF.

As such, it would seem that I am forced to use a combination of the JAR
and WAR attribute "manifest", along with the nested <manifest>.  The
issue is that in using this approach, the attribute "manifest" requires
that the file be present or it fails.  The only solutions/workarounds
that I have discovered thus far are to:
		- Force all disparate J2EE applications to have a custom
MANIFEST.MF file for every archive to be packaged - this is NOT a good
		- Create two duplicate tasks with the only difference
being that in one "manifest" attribute is present, and in the other it
is not
		- use <available> to check for the existence of a
MANIFEST.MF file and conditionally set a property
		- call both targets and use the "if" attribute on the
task elements determine execution.

For large, intricate JAR and WAR tasks, creating 4 tasks (2 for JAR, and
2 for WAR) with nearly all duplicate code is really cumbersome, lengthy,
and confusing to maintain.

Is there a better way???  Ideally, the attribute would "fall-through"
... that is, use the specified manifest file (via the attribute) if it
exists, but provide for a default (via the nested element) if it does

Any help would be greatly appreciated - Thanks!
- Tom  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message