You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Kevin Galligan <ma...@kgalligan.com> on 2006/05/18 23:44:12 UTC
war lifecycle
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.
Re: war lifecycle
Posted by Kevin Galligan <kg...@gmail.com>.
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 <ma...@kgalligan.com> 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 <wa...@gmail.com> 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 < mailinglists@kgalligan.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: war lifecycle
Posted by Kevin Galligan <ma...@kgalligan.com>.
I hate to keep blasting away, but I thought I'd add this in case anybody was
looking for something similar. Here's what I did.
Using 'generate-sources' was problematic for a couple reasons. The main one
was I thought of a different way to do it that would require far less
hacking around. I attached 'war:exploded' to 'process-classes', then
created a new mojo that just executed the packaging step of 'war:war'
without the call to 'buildExplodedWebapp'. This would allow a custom plugin
to be attached to 'process-classes' and be run after 'war:exploded'. I
don't know that this fits in what 'process-classes' is inteded to mean, but
it seems to be functional. Here's the change to
'META-INF/plexus/components.xml'...
<!-- 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-classes>org.apache.maven.plugins:maven-war-plugin:exploded
</process-classes>
<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</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 -->
The new mojo is just a copy of 'WarMojo.java' with '@goal war-package', and
'buildExplodedWebapp' removed from 'performPackaging'.
Obviously this has had no testing at all, other than a basic webapp build.
On 5/19/06, Kevin Galligan <ma...@kgalligan.com> wrote:
>
> 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 <mailinglists@kgalligan.com > 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 < mailinglists@kgalligan.com> 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 < waynefay@gmail.com> 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 < mailinglists@kgalligan.com> 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: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: war lifecycle
Posted by Kevin Galligan <ma...@kgalligan.com>.
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 <ma...@kgalligan.com> 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 < mailinglists@kgalligan.com> 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 < waynefay@gmail.com> 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 < mailinglists@kgalligan.com> 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: war lifecycle
Posted by Kevin Galligan <ma...@kgalligan.com>.
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 <ma...@kgalligan.com> 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 <wa...@gmail.com> 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 < mailinglists@kgalligan.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: war lifecycle
Posted by Kevin Galligan <ma...@kgalligan.com>.
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 <wa...@gmail.com> 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 <ma...@kgalligan.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: war lifecycle
Posted by Wayne Fay <wa...@gmail.com>.
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 <ma...@kgalligan.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org