[EMAIL PROTECTED] wrote:
"Kevin Galligan" <[EMAIL PROTECTED]> wrote on 10/02/2006 02:11:49 PM:
Just thought I'd send a little back to the community. I coded a
simple eclipse builder plugin that helps speed up webapp development
when using the war plugin.
I'm sure there's something out there that does this already, but this
works pretty well. If you edit and save a file in either the
'src/main/webapp' directory or a java class file, it copies the output
to the exploaded war directory in 'target', so changes should be
visible immediately rather than after running maven.
Obviously, if you have plugins on your project, they won't get run.
This really came out of a need to speed up jsp editing. The plugin
will also listen to the output on the compiled classes directory, so
editing java classes in 'src/main/java' will compile to
'target/classes', and from there be copied to the webapp exploded
directory.
The plugin also takes 'finalName' into account. However, it does not
look into parent pom definitions, etc, so more tricky configurations
are not taken into account.
http://www.bigheadco.com/warplugineclipsebuilder
Comments welcome.
I tackled the same problem in a different manner recently. Are you
familiar with the war:inplace goal? That does the reverse of your eclipse
plugin. It copies the target/classes and lib dependencies from target into
src/main/webapp/WEB-INF/classes and /lib. I added an ignore for those
directories to my svn repository so they won't get checked in. Now just
editing a jsp in eclipse and saving it allows tomcat to see the change. I
got pulled into more backend development since then, so I didn't go the
next step, but I considered modifying eclipse to use the WEB-INF/classes
dir as the compile output folder instead of the default build/classes.
With that in place, you should only need to run war:inplace if you add a
new dependency. Also, I had to setup tomcat's context.xml for the app to
be reloadable=true.
Another nicety I added was to add those WEB-INF/classes and lib
directories to the maven-clean-plugin so that "mvn clean" gets rid of them
too.
I haven't looked at your eclipse plugin in more detail, so I'm not sure of
what extra features your solution may offer over mine, but I thought I'd
throw mine out there for consideration.
I am glad to see that other people are still trying to find a better
solution with eclipse.
I used war:inplace up until today, when I implemented webapp resource
filtering to make my war files configurable per profile for different
customers.
My whole code base is under source control, so my web.xml for instance
is read-only unless I have it checked out. Because I am filtering it,
the mvn package process changes it when copying it to /target and
war:inplace then tries to copy the filtered web.xml over the top of the
read-only original, and fails.
I suppose one work-around would be to move web.xml into
src/main/resources, but I have other issues with war:inplace, such as
the huge time I waste when I forget to revert its actions before doing
some other packaging operation.
It looks like Greg has got a good roadmap to iron out those issues, but
I feel the whole concept is not very future-proof.
I'm going to try out Kevin's plugin for Eclipse now.
It will be v. interesting in the future if maven is produced in
Eclipse-plugin format that is fast and sleek enough to take over all the
compiling, filtering and other lifecycle events itself.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
