All this "sub phase" talk was based on the assumption that the war plugin has to process its stuff in the package phase. Is there a reason why the war process can't be split up across phases?
I've dug around quite a bit, and here's what I've come up with. Essentially, the war lifecycle is doing 2 things. Its building a war, but its also running all the normal steps involved with building a jar. So its almost like its trying to do 2 things. The lifecycle definition for a war and a jar are almost the same... <!-- START SNIPPET: jar-lifecycle --> <phases> <process-resources> org.apache.maven.plugins:maven-resources-plugin:resources </process-resources> <compile>org.apache.maven.plugins:maven-compiler-plugin:compile</compile> <process-test-resources> org.apache.maven.plugins:maven-resources-plugin:testResources </process-test-resources> <test-compile>org.apache.maven.plugins:maven-compiler-plugin:testCompile </test-compile> <test>org.apache.maven.plugins:maven-surefire-plugin:test</test> <package> org.apache.maven.plugins:maven-jar-plugin:jar </package> <install>org.apache.maven.plugins:maven-install-plugin:install</install> <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy> </phases> <!-- END SNIPPET: jar-lifecycle --> <!-- START SNIPPET: war-lifecycle --> <phases> <process-resources> org.apache.maven.plugins:maven-resources-plugin:resources </process-resources> <compile>org.apache.maven.plugins:maven-compiler-plugin:compile</compile> <process-test-resources> org.apache.maven.plugins:maven-resources-plugin:testResources </process-test-resources> <test-compile>org.apache.maven.plugins:maven-compiler-plugin:testCompile </test-compile> <test>org.apache.maven.plugins:maven-surefire-plugin:test</test> <package>org.apache.maven.plugins:maven-war-plugin:war</package> <install>org.apache.maven.plugins:maven-install-plugin:install</install> <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy> </phases> <!-- END SNIPPET: war-lifecycle --> What I really want to do is copy everything involved in a war build during the process-resources phase. So, one idea would be to split the war build up into multiple individual mojo's. One to copy all war related resourses (dependent war expansion, war rources, libs, etc), and one that will do the final packaging (move compiled classes, build war, etc). The first mojo would be added to 'process-resources', and assuming everything was ok, this should work. However, from what I can gather, you can only have 1 mojo for each phase in the lifecycle definition, and as I'm in a rush, I need to figure out something for an immediate solution. So, what I'm thinking of trying out is splitting the war mojo into the 2 parts specified above, and adding the following line to the war lifecycle... <generate-sources> org.apache.maven.plugins:maven-war-plugin:war-prepare-resources </generate-sources> This should avoid the conflict with 'process-resources' and accomplish the necessary goal. If something like this worked, I'd also like to be able to use the java classes in a dependent war when compiling the current war's java code. This currently does not work, and although its arguable that java code that will be used as a dependency should be put into an external jar package, there are occasionally real life practical reasons why this isn't a great way to go. I'm sure I'm missing something and it'll all end in tears, but its something to try. Any thoughts? Does this make sense or am I totally off? On 5/19/06, Kevin Galligan <[EMAIL PROTECTED]> wrote:
Sorry. Sent from the wrong email. Not sure if it made it. Copy... I've been taking another look at the thing I built at the "day job", and its screaming for this type of thing. Essentially what I did was make a vendor branch of the war mojo, and modified 'AbstractWarMojo' to call into some code of mine in the 'buildExplodedWebapp' method. I tried to make it as un-hacky as possible, but that went out the window. Essentially, I can't get the war plugin to find my custom classes unless I make them a dependency of the war plugin. The war plugin itself, however, is a dependency in my package, so the cross-depend on each other. So, they have to be built individually or it bombs. However, it works, and took care of our needs. That's what I think is missing. The ability to step inside the war plugin's process and apply some programatic changes. If the war plugin could call out to the main maven process and say: run custom phase 'war.process-webapp' It would open the door to applying a custom plugin to the build. I don't know anywhere near enough about the maven internals to figure out even a good hack way of doing this. My hack doesn't even technically work, as the war plugin needs to include the custom code as a dependency, but its the same basic idea. On 5/18/06, Kevin Galligan < [EMAIL PROTECTED]> wrote: > > In detail, I want to edit jsf facelet files in BEA workshop studio. It > does a really good job with jsf jsp files, but if you try to edit non-jsp > files in that view, the helpful jsf features disappear. > > Facelets are essentially valid xml. The whole thing is pretty close to > jsp, except for a few things. The major one is that you declare your > 'taglibs' in the xml namespace at the top level rather than in a special > directive. I think there might be a way to do this with jsp/xml syntax, but > I'm not sure the BEA tool supports that either. > > So, here's what I was thinking. If I could just make sure to stick with > valid xml syntax besides the standard jsp 'taglib' and 'page' directives, I > could do a pretty simple transform on that file. Look for the taglib > directives, stuff those urls into the top level xml namespace, and output > what would hopefully be a valid facelet file. In the standard lifecycle I > think this would be somewhere around ' process-resources' or 'compile'. > However, there's really nowhere to stuff this in with the war build, if I > understand it correctly. > > I mean, before we address if my idea is a good idea, I was just wonering > if there was a way to attach a plugin to the war build lifecylce. As I > stated in the original email, I cracked open the code and hacked together > some stuff previously because I couldn't attach anything to the war > resources. I think there is a general use for this kind of functionalty. > > This is a way out of the box idea. Basically, the phases are a good > idea, but maybe there are situations in which a build doesn't map well to a > fixed set, right? So maybe a particular plugin could "declare" custom build > phases. > > For example, the war build would declare "war:process-resources" as a > special custom phase, and attach it to the global "package" phase. Then it > would attach its own steps to that phase, and I could attach my own plugin > to that war-custom phase. Then maybe it would have "war:package" after > "war:process-resources". In "war:package", it would assemble the war, etc. > This would allow plugins to be built and attached in basically the way they > are now. You'd just need to look in the documentation to see if the plugin > exposes a custom phase. > > It might open the door to builds that are, out of necessity, more > complex than a standard java build. At the same time, it might open the > door to needlessly complex configurations. Who knows. > > Maybe there's something there already that works like what I'm talking > about? > > On 5/18/06, Wayne Fay < [EMAIL PROTECTED]> wrote: > > > > What specifically are you looking to do? What kinds of "things" are > > you looking to "apply" to jsp/servlets? > > > > Please provide input and output examples to facilitate a discussion on > > this subject. I know at least one other person has posted a similar > > question on the User list in the last 60 days -- search the User > > archives for "filter jsp" and you're bound to find it. > > > > Wayne > > > > On 5/18/06, Kevin Galligan < [EMAIL PROTECTED]> wrote: > > > I'd like to run my jsp code through some filters before being > > packaged. Not > > > just simple find and replace filters, though. A little more > > complex. I > > > know there is a feature in the recent version of the war plugin that > > allows > > > some regular filtering, but its not really what I'm looking for. > > > > > > Were this standard java code, I'd just write a plugin and put it > > somewhere > > > in the lifecycle. However, from my previous work with the war > > plugin, there > > > really isn't a "lifecycle" per say. Everything happens in the > > package > > > phase. Is this correct? If so, any reason why? Doesn't anybody > > have a > > > solution for applying things to jsp/servlet artifacts? At my "day > > job" I > > > hacked something together with the war plugin that called out to > > other code, > > > but it was quite hacky and seemed to defeat the purpose of maven and > > > breaking up the build into a lifecycle. > > > > > > Thanks in advance. > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
