of course you execute in the web app. i'm asking what you do when in IDEA you edit a source file that belongs to the other subprojects (and not the web project) - in your case, you'd have to mvn install it to make tomcat:run work, right?
On Fri, Nov 21, 2008 at 8:12 PM, Hugo Palma <[EMAIL PROTECTED]> wrote: > I execute the tomcat plugin in the web app project POM and not in its > parent. > Why would you execute it from the parent POM ? > > On Fri, Nov 21, 2008 at 6:03 PM, Andreas Andreou <[EMAIL PROTECTED]> wrote: > >> Hugo, the only (unrelated to T5) problem i have in such a setup >> is when it's a multiproject pom - in that case mvn tomcat:run uses >> the installed artifacts of each subproject, meaning that compiling from IDE >> and >> rerunning mvn tomcat:run wont work - how are you dealing with such a case? >> >> On Fri, Nov 21, 2008 at 11:34 AM, Hugo Palma <[EMAIL PROTECTED]> >> wrote: >> > No, i'm a very happy IntelliJ user :o) >> > My dev environment couldn't be simpler: >> > >> > - I use maven for building and i run my app by just typing "mvn >> tomcat:run" >> > in the console. >> > - Whenever i change a class of template i just press the build button in >> > IntelliJ and see the changes immediatly on the running tomcat (without >> > reloading the context). >> > >> > I don't even have to worry about building an exploded structure for >> tomcat. >> > The plugin uses the classes right from the build directory of maven. >> That's >> > why nothing more than a simple build in IntelliJ (or any other IDE) >> causes >> > the live class reload. >> > >> > >> > On Thu, Nov 20, 2008 at 7:04 PM, Kalle Korhonen >> > <[EMAIL PROTECTED]>wrote: >> > >> >> Tomcat doesn't have a "unhappy tendency to copy resources to a secondary >> >> location", it just depends on how you set it up. >> >> >> >> Hugo, are you using sysdeo's Tomcat plugin for Eclipse in development? I >> >> haven't tried but what I've read about T5's class reloading, I think >> live >> >> class reloading should work with it without any issues, just need to >> >> disable >> >> JVM hot code swapping (with which I've been enjoying live class >> reloading >> >> in >> >> T4 development for years). >> >> >> >> Kalle >> >> >> >> >> >> On Thu, Nov 20, 2008 at 9:06 AM, Howard Lewis Ship <[EMAIL PROTECTED]> >> >> wrote: >> >> >> >> > There are certainly some limitations with LCR imposed by the different >> >> > servlet container implementations; the ability to scan the classpath >> >> > for class files within packages, and to resolve a loaded class to a >> >> > URL is going far beyond whats in the servlet spec. >> >> > >> >> > Jetty is sensible; the class files are easy to find, the class loaders >> >> > make sense, the URLs are standard jar: URLs. >> >> > >> >> > Tomcat works differently, with an unhappy tendency to copy resources >> >> > to a secondary location once, use its own format URLs for those >> >> > resources, and not copy changes to the real file over the the >> >> > secondary location. >> >> > >> >> > On Thu, Nov 20, 2008 at 8:33 AM, Peter Stavrinides >> >> > <[EMAIL PROTECTED]> wrote: >> >> > > The truth is LCR wont work correctly with vanilla Tomcat (as >> mentioned >> >> by >> >> > others the maven plugin for Tomcat may work, but personally I had to >> >> fiddle >> >> > with it to get it working... it was sketchy in tandem with non >> Tapestry >> >> > filters and anything else out of the ordinary), whereas jetty just >> works. >> >> > > >> >> > > Web tools platform Tomcat (no maven plugin) picks up changes and >> does a >> >> > partial restart, which is far from ideal because: >> >> > > a) The session is lost >> >> > > b) Its pretty slow! In a sizable application with other j2ee modules >> >> > attached this is very noticeable, whereas the jetty implementation >> works >> >> > instantly >> >> > > >> >> > > Some of our developers use Tomcat because we have a requirement to >> work >> >> > with multiple modules from source (not jars)... yes, there is probably >> a >> >> way >> >> > to do this better with maven and the jetty plugin, but I spent hours >> >> trying >> >> > and failed to configure it. Recently I found: >> >> > http://maven.apache.org/maven-1.x/using/multiproject.html, but >> haven't >> >> had >> >> > a chance to look more closely into this. It would be fantastic if >> there >> >> was >> >> > more detail on how to configure/tweak enterprise tapestry projects for >> >> > maven. I am not sure about Netbeans, but in eclipse, LCR can fail if >> your >> >> > build path is not set correctly, and the exact configuration may >> differ >> >> > between maven plugin versions and eclipse versions. >> >> > > >> >> > > cheers >> >> > > Peter >> >> > > >> >> > > >> >> > > ----- Original Message ----- >> >> > > From: "Hugo Palma" <[EMAIL PROTECTED]> >> >> > > To: "Tapestry users" <users@tapestry.apache.org>, "Alex Kotchnev" < >> >> > [EMAIL PROTECTED]> >> >> > > Sent: Thursday, 20 November, 2008 5:05:51 PM GMT +02:00 Athens, >> Beirut, >> >> > Bucharest, Istanbul >> >> > > Subject: Re: Live class reloading problems >> >> > > >> >> > > I would say that this problems with LCR should be dealt with case by >> >> > case. >> >> > > I'm sure that "LCR only works on Jetty" is false because i have it >> >> > working >> >> > > in tomcat with no additional configuration. It just worked. >> >> > > >> >> > > That's not to say there aren't any problems or limitations with the >> LCR >> >> > > implementation, i'm sure there are. But i think the way to go would >> be >> >> > for >> >> > > everyone to whom LCR doesn't work as expected and documented to >> create >> >> an >> >> > > issue describing the exact environment they're executing on and the >> >> > > community will take it from there. >> >> > > >> >> > > On Thu, Nov 20, 2008 at 2:15 PM, Alex Kotchnev <[EMAIL PROTECTED]> >> >> > wrote: >> >> > > >> >> > >> This is awkward.. if live class reloading (LCR) doesn't work on >> >> Tomcat, >> >> > and >> >> > >> Glassfish, because JBoss uses Tomcat under the covers, I'd guess >> that >> >> it >> >> > >> doesn't work on JBoss either. Although I haven't used webLogic or >> >> > Websphere, >> >> > >> I can't make an intelligent guess on whether it works there or >> not.. >> >> But >> >> > it >> >> > >> seems very misleading to state in the docs that T5 has LCR, if it >> >> > doesn't >> >> > >> work with probably 50%+ of the java app servers/servlet containers >> (I >> >> > guess >> >> > >> that Tomcat, Jboss, and glassfish cover probably 75%+ of java web >> app >> >> > >> developers). If Tomcat had a miniscule market share, then one could >> be >> >> > >> justified in saying 'T5 works, Tomcat is broken', however w/ things >> >> > being as >> >> > >> I described the majority of deployed T5 apps don't support LCR. >> >> > >> >> >> > >> Now, if Jetty is the only setup that works reliably (that is LCR >> w/o >> >> > having >> >> > >> to redeploy), wouldn't it serve everyone best to clearly state that >> in >> >> > the >> >> > >> docs? That is, the docs should explicitly describe that this is a >> >> > special >> >> > >> setup for development purposes that works only w/ Jetty (or at >> least >> >> > clearly >> >> > >> state that it doesn't work w Tomcat, Glassfish, Jboss, etc)? I >> >> > understand >> >> > >> that it is abit unfair to T5 as it was intentionally designed to >> >> support >> >> > >> LCR; however the docs are most useful when they describe things >> >> > accurately . >> >> > >> >> >> > >> What does everyone think? Should I file a jira issue for this? >> >> > >> >> >> > >> cheers, >> >> > >> >> >> > >> Alex Kotchnev >> >> > >> >> >> > >> - original message - >> >> > >> Subject: Re: Live class reloading problems >> >> > >> From: "Thiago H. de Paula Figueiredo" <[EMAIL PROTECTED]> >> >> > >> Date: 11/20/2008 10:50 >> >> > >> >> >> > >> Em Thu, 20 Nov 2008 01:27:18 -0300, akochnev <[EMAIL PROTECTED]> >> >> > >> escreveu: >> >> > >> >> >> > >> > I'm running into some trouble w/ the live class reloading feature >> >> (the >> >> > >> > template reloading works fine), tested both on Tomcat 6 , >> Glassfish >> >> 3 >> >> > >> > Prelude, and Glassfish V2 (all three servers support exploded war >> >> > >> > deployment). >> >> > >> >> >> > >> As far as I know, Tapestry's live class reloading never really >> worked >> >> in >> >> > >> Tomcat (because of it, not because of Tapestry), but I haven't >> tested >> >> it >> >> > >> for a while. I don't know about Glassfish. >> >> > >> >> >> > >> -- >> >> > >> Thiago H. de Paula Figueiredo >> >> > >> Independent Java consultant, developer, and instructor >> >> > >> http://www.arsmachina.com.br/thiago >> >> > >> >> >> > >> >> --------------------------------------------------------------------- >> >> > >> 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] >> >> > >> >> >> > >> >> >> > > >> >> > > >> --------------------------------------------------------------------- >> >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > Howard M. Lewis Ship >> >> > >> >> > Creator Apache Tapestry and Apache HiveMind >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> > >> >> >> >> -- >> Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr >> Tapestry / Tacos developer >> Open Source / JEE Consulting >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
