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. > > 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.
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". > 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. > > 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. Simone --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
