On 04/12/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may find
other needs.
Currently, *-resources handles class path resources, which are
required to be treated separately to the package because in many
cases, such as a webapp, the package is not equal to the set of
classpath resources (or equivalent for whatever other language is
being dealt with).
Here, we are processing 'resources' for the package (assembly, war,
tomcat installation, etc). pre-package is basically just a different
process-resources phase.
So, instead of the addition to the 'pre-package' phase, should we
consider generate-package-resources and process-package-resources
phases prior to 'package' in the lifecycle? This would allow us to
generalise the 'resource' lifecycle steps in the same way as for
regular resources, and test resources, including adding
'<packageResources/>' to the POM as a replacement for the custom
webResources configuration for the war plugin and as a way of
introducing things to assemblies without the descriptor (allowing for
more generalised descriptors as we recently discussed).
Sounds good; although in the case of a war, would executing up to the
process-package-resources phase produce the fully exploded war? Or
would the package resources only contain the web resources, omitting
WEB-INF/**?
My use-case would require the full exploded package as it would be archived.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
