| JAR Manifest - default vs. custom | JAR Manifest - default vs. custom 2005-06-22 - By Rosenbaum, Thomas
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:
#1.
- Force all disparate J2EE applications to have a custom
MANIFEST.MF file for every archive to be packaged - this is NOT a good
approach.
#2.
- 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
not.
Any help would be greatly appreciated - Thanks!
- Tom
|
|
 |
