Fabian Christ wrote:
Simone Gianni schrieb:
Steve Loughran wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would somehow assemble WARs
and EJB beans to make a working app, presumably through some GUI that
required the same work to be repeated every release.
If you are doing lots of late binding tuning to the WAR file, then
perhaps build time is the wrong place to do it; it should really be
done as part of the deployment process, where per machine
optimisations can go in. In this world what you want from the outset
is the exploded WAR, which is then taken with server-specific options
to create the target WAR for the target system.
It's not late binding tuning with custom parameters. For example the
cocoon plugin was ment to unpack and write some configuration files in
the WAR, configuration files which are not bindings to external servers,
but settings for the internal servlets. In that case, it is a build
problem, and not a configuration one. Also, the web.xml often contains
directives which are "configuration" in the strict sense (like various
init parameters), but also contains all the assembly informations of a
web application, being unable to write plugins that can manipulate these
file in the build phase is, IMMO, a problem.
Hi together,
I followed with interest your discussion about manipulating a WAR structure
before building the WAR file. Here are some of my thoughts at this topic:
First, the problem is not WAR specific as others here mentioned before. A WAR is
nothing more than a zipped file structure. Now the problems described here arise
when you try to modularize your web application. This is what Cocoon does with
their blocks. Each block consists of Code and of WebApp-Resources. During the
build process the code and the resources are repackaged as a WAR.
A new pre-package phase in Maven might solve some problems that these people
have when modularizing such a WAR. Now there is a concrete phase where such a
job can be done. But I think the problem is more complex.
I had the same problem some time ago and was thinking about something like a WAF
(a Web Archive Fragment). A WAF describes a fragment of a WAR similar to Cocoon
blocks. A WAF contains of a) Code and b) Resources. Now a WAR can depend on
several WAFs that are integrated during the build. Here you get again problems,
e.g.: How do you specify the order in which the WAFs are integrated? How do you
handle conflicts when files from different WAFs are overwritten (patching)? How
can you depend on code from a WAF (same problem with WARs today)?
I came to the idea that at first you have to split code and resources in a WAF.
This means that a WAF can produce two artifacts: a JAR and a file structure. So
Maven must have support for defining projects that can have more than one
artifact as result.
As I said this problems are not WAR specific - other archive structures have the
same problem. I think a general solution can be found here. Such a solution
might look like:
- allow multiple artifacts from one project (code JAR and resources ZIP)
- allow configurable overlay of file structures (resources) with configurable
orders, includes and excludes
- allow file patching during the overlay as different modules might modify the
same file and not overwrite each others changes
By this you don't need something like a WAR plugin in the end as each project
can define itself how the resulting archive is constructed from code and
resources by an overlay mechanism. This is an important use case I think as you
get independent for future archive formats. I know that those ideas are beyond
the current discussion and break the philosophy of Maven in some points but
perhaps someone is interested.
- Fabian
I'm really enjoying this discussion too, because it shows up interesting
deployment use cases.
composite JARs/WARs/EARs are not that unusual. EAR files are the worst
in class, especially if you have to edit the manifest.mf /classpath to
provide relative references to other JARS. I think tools need to address
this problem.
In maven, you'd probably want to split each sub-piece into its own
build, and have a meta-project to pull them all together. Which of
course may mean restructuring your build.
In ant, well, you can create the stuff and use <ear> or <war> to stick
things together, but even those two tools punt on the problems of
getting the application.xml set up right (I normally hand code mine and
use Ivy to retrieve the dependencies without any -version tags), or of
doing manifest fixup (which i think is utterly wrong, BTW).
Its because of those target specific xml files that you do need specific
code in the plugins...
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
