Both Q4E and m2eclipse plugins (for Maven support in Eclipse) do resource filtering. I suppose you could point to the webapp target directory for src/main/webapp and then use that as a context, but in general I think filtering all of your webapp resource files is a bad idea (because I imagine it'd be slow and error-prone as your app grows). This is obviously web framework dependent but for example with Tapestry, you wouldn't need to filter the resources but the framework would allow to set the context path for resources that need it. In a traditional servlet/jsp-environment, a CSS file could be a JSP file.
Kalle On Mon, Aug 4, 2008 at 12:38 AM, Istvan Devai <[EMAIL PROTECTED]>wrote: > Hi Kalle, > > Thank you for your reply. > > Yesterday I spent a few hours tinkering with various setups and realized > that mvn jetty:run basically works in the way you described below (classes > from /target/classes, webapp resources from /src/main/webapp). This works > nicely, and - as you kindly describe - could be a working setup for Tomcat, > too. > > My only problem with this setup, is that the servlet container sees the > unfiltered resources in the webapp directory. Imagine I've got a .css file > in webapp, and in the CSS file, i've got an absolute path to an image. I > would like to have a filter variable for the servlet context, so the CSS > file will work in various deployment environments.. > > Another possibility would be to start Jetty with mvn jetty:run-exploded > which would use the directory /target/myapp-1.0-SNAPSHOT (the extracted war > contents). However, the problem with this one is that when I edit a file in > Eclipse, the changes will not be copied to this directory, only to > /target/classes, etc. Which means, that Jetty (or Tomcat if run with > war-exploded) won't pick up the changes until I issue a mvn package). > Maybe a solution could be to write a shell script that monitors the > /src/main folder and if there is any change, automatically runs mvn package? > (which will update /target/myapp-1.0-SNAPSHOT contents with filtered > resources, new classfiles, etc.) > > Best regards, > Istvan > > > Kalle Korhonen wrote: > >> If you use Sysdeo's Eclipse Tomcat Launcher plugin ( >> http://www.eclipsetotale.com/tomcatPlugin.html) and its devloader, you >> can >> point to src/main/webapp for context, pick up the class files from >> target/classes and the libraries from your local m2 repo directories. It's >> both faster and more reliable than Eclipse WTP's built-in container >> support. >> There's also http://merve.sourceforge.net/, which offers less options >> than >> Sysdeo's but is more automatic. Similarly for Jetty you can use >> run-jetty-run (http://code.google.com/p/run-jetty-run/). I never create a >> war while developing a webapp and I even try to avoid container restarts >> (several solutions exist for hot-code swapping depending on your web >> framework and platform). >> >> Kalle >> >> >> On Sun, Aug 3, 2008 at 4:23 AM, Devai Istvan <[EMAIL PROTECTED]> wrote: >> >> >> >>> Dear Sirs, >>> >>> Currently I'm developing a webapp in eclipse running on a tomcat >>> instance. >>> When I edit a .html or a .java file in eclipse, the modification can be >>> immediately observed (because Automatic building is turned on in Eclipse >>> and >>> I'm using a context file that specifies the docbase of the context as the >>> ouput directory of Eclipse). >>> >>> Now, I'd like to convert the project to use maven and preserve the above >>> way of development. How to do this? >>> >>> The problem is that if I place stuff into the /src/main/webapp directory, >>> it does not get copied to /target/classes, which means I cannot use >>> target/classes as the docbase of the context. >>> >>> Since my pom specifies war as a packaging mode, >>> /target/myapp-1.0-SNAPSHOT >>> contains the exploded WAR contents. If I specify this directory as a >>> docbase >>> for the tomcat context, everything works as intended, the only problem is >>> that if I edit something in eclipse, the changes will be only visible >>> after >>> doing a mvn package.. >>> >>> Anyone has a solution for this? >>> What about Jetty, is there a solution for that too? >>> >>> Best regards, >>> Istvan >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
