Hi,
Some ramblings, trying to analyze a use-case and finding a solution without
modifying the lifecycle:
Michael Horwitz wrote:
Hi,
As a side note it strikes me that the primary problem is that the war:war
goal does a little too much in a single go during the packaging phase.
Could
the issue be solved by spreading the work of the war:war goal through the
existing phases?
Now this is the one idea I like.
I'm basically -0 on adding generate-package-resources/process-package-resources
since it doesn't add anything new - things done there can be done in
generate-resources/process-resources. There's no need to duplicate those pases
later on in the lifecycle (right?).
The real problem is that people want an unpacked artifact, probably since
packaging
a war artifact is too slow (lots of dependencies copied, and zipping up zips is
slow).
If we require everyhing to be present in target/ prior to the package phase,
then the
package phase would just zip it up, as it was intended to with 'jar' packagings.
For jar packaging, would require the pom.properties and pom.xml to be generated
during generate-sources, which
is needed anyway because when you use those files at runtime and you're running
from your IDE those aren't
present yet.
For ear/ejb packaging, make sure metadata descriptors like application.xml are
created during the generate
resources phase.
So basically: don't modify the content's of the artifact during packaging,
except maybe to
include dependencies.
Now, war's are a bit strange compared to 'normal' jars. The src/main/java and src/main/resources
don't end up in the archive root, but in /WEB-INF/classes, which is part of the artifact's classpath.
The src/main/webapp, the real 'war' resources (not on the classpath, but used
by the webapp), end up
in the archive root.
A solution for this case would be to not allow any code in war projects;
everything that goes in /WEB-INF/classes
should just be in a dependency placed in /WEB-INF/lib. Then, the war packaging would be simplified to not filter-copy
src/main/resources to the archive root; this is then handled during the normal resources phases. No more src/main/webapp.
What it does right now is correct, though: src/main/resources should end up in the classpath. I'm proposing a change
to deal with 'war' project resources differently.
Also, overlaying could be handled in generate-resources.
This would simplify the war goal, as Michael suggests.
As it is, war packaging is comparable to an 'uberjar' packaging or an assembly.
There's currently no way to replace
the main artifact with an assembly, which is a problem in this case.
We've got one problem left: maven currently can handle testing projects and
running webapps without having to copy
all the dependencies since it can resolve them from the local repo/reactor.
They are typically included in the
artifact during the package phase.
For jetty:run, it is not needed to copy them since it also resolves them using
maven. So we need a phase to hook
jetty into that's before package and after testing. This would simply be solved
by adding @execute phase='test'.
Then, if we allow the package phase to include other dependencies, like how
it's done in the ear plugin, the war
problem is solved. If you want an unpacked war, you can call the non-lifecycle
mojo unpacked-war
(or whatever it's called), that also @execute phase='test'.
Btw, the '@execute phase=".."' is basically the same as a 'depends' clause, in
that it enables you to run
something after another phase has run, but before the next phase.
WDYT?
I'd like to gather all use cases that would benefit from a 'prepare-package' phase,
and see if there are solutions that don't require lifecycle phases. As Jason said, it will
be something that we can never take back. Also, most packaging mojo's would require re-wiring to that
phase and leave the 'zipping up' to a simple mojo bound to 'package'.
-- Kenney
Mike Horwitz
On 12/4/06, Mark Hobson <[EMAIL PROTECTED]> wrote:
On 03/12/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> Pretty sure the issue already exists... should just be done IMO.
Ah-ha, found it.. :)
http://jira.codehaus.org/browse/MNG-2097
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
