Sorry, i misunderstood ur question.
Yep, i've never had that problem but i can't think of any other way of
doing it if i did.
Andreas Andreou wrote:
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]
