Simone Gianni wrote:
Kenney Westerhof wrote:
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).
More or less, in the parallel thread "Manipulating the WAR directory
before the WAR file gets built" the problem is not to optimize build
time, but actually to be able to write plugins that can operate on the
WAR file before it is generated. Obviously this could be solved by
generating the war, reopening it, manipulating it, reassemboling it, but
if this is the only solution then maybe even my stupid patch
(http://jira.codehaus.org/browse/MWAR-86 ) can prove useful.
Hm, that sounds complicated, but probably necessary given what the war mojo
currently
does.
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.
Yep, IMO this is it.
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.
generate-resources is intended to generate something in the target
folder? or in the src folders? cause, if it's intended to generate in
the target then there is no problem at all, is the perfect phase to do
everything (overlay the war, pack all the stuff in the target folder,
manipulate it with third party plugins) and the package can simply zip it.
Everything that's generated or modified should put their results in the target/
directory.
Everything under src/ is human-created and most of the times, under version
control.
Having plugins modify or add files in src/ is very bad.
I'm asking this because in
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
it's not specified, and its companion phase generate-sources seems to
mean "generate spacial sources like ejb distribution code or rmi stubs
in src/main/java so that the default compile system will compile them".
No, it means generate sources and register their path as a new compile source
root.
Maybe that page needs to be fine-tuned a bit more, but sources are NEVER added
to src/. All generated sources and resources should be placed in target/, and
mojo's can register them. Take for example the maven-antrun-plugin; it has 2
configuration options to specify locations that should be added to the
compile-list
(for main sources and test sources).
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'.
In the case of third party plugin that needs to work on a war before
it's packed, the work of this third party plugin could be (as it is for
the cocoon deployer plugin) part of the normal build/package/install
cycle of the application, so placing this in a non-lifecycle step is not
a (good) solution.
The statement above was purely meant for creating a monolithic directory
that could be used by say tomcat to deploy the war; deploying a war is not part
of
the lifecycle, at least not up to the package phase. It could be used
by integration tests, but those are after the package phase and have access to
the war file.
For all other purposes, it is not needed that all data be placed in 1 directory
in the correct 'war' structure, as maven knows where all the parts are that
contribute to
the war file.
Inthe case of 3rd party plugins, they can and should be linked to the
generate/process
resource/source phases, as that's what they do. Unless some of the 3rd party
plugins you're
referring to are doing 'more evil' things? ;)
ere are other plugins out there
that do other things?
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'.
See my email "Re: Manipulating the WAR directory before the WAR file
gets built" of 2006-12-04 @17:24 for some usecases I have encountered.
Okay, I'll read up on that thread.
Thanks,
Kenney
Simone
---------------------------------------------------------------------
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]
