Its unclear now what you are trying to fix. Your first post stated you
wanted to cut down on the "deploy" part (I pointed out the features we
currently get that we'd loose with your approach; also that deploy is
necessary to flush out the old version of the code in the JVM) and this
last post I get the impression you want to cut down on the "build and
copy JAR to WEB-INF/lib" step.
I think I understand your situation as I have been there too but lets
work through your points.
Glen Marchesani wrote:
The IDE features you mention sound cool which one is it?
I don't want to get into any religious IDE war but Eclipse 3 with WTP 1.0.
Any pointers/links
to how you got that setup?
See below for the outline.
Unfortunately for the environment I am working
in an IDE specific solution would be incomplete. We have a broad range of
use cases (IDEs, OSes) as well as users where we need people to be able to
checkout a project and be productive with it in a minimal amount of time.
So doing IDE specific tweaks won't cut it. Our solution has worked
extremely well with other app containers for example WebSphere, Resin and
Jetty (all three that we use) come with support for something like this out
of the box.
I understand what you are saying, from your commercial standpoint you
see the lack of this feature as causing a headache in supporting your
customer base container diversity.
My point from a technical standpoint your feature is already obsolete
since at least one popular IDE already has a working solution which
probably works for all containers the IDE supports (I've never tested on
anything but TC) which includes the ones you list above. It is just
matter of time before the other popular IDEs play catch up.
The IDE we use really depends on the customer, project and environment. So
could be any of the following ant+text editors, eclipse, WSDC, and/or
netbeans... We can seemlessly switch between any of these using this
technique by just adding the extendedClasspath line to the context and
dropping a jar in server/lib/ all of which is handled by our ant scripts.
I am all for continuing this tangential discussion of webapp development
techniques but it really is tangential to the intent of the original post..
I'm not against your feature per say just the reasons you cite the need
for it.
Hot-code replace works fine in this scenario, I get the impression that you
think it doesn't. As for your comments about future proofing. I am very
confident that IDE's will from now on into the future will compile my .java
files to some directory on the disk and that this option will be
configurable and use some consistent default. So this solution is
completely future-proof.
In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's
you
need to manually kick off that process so it is adding a step to the
edit-compile process.
Are you really sure hot code replace work fine in this scenario, I
thought the IDE had to be able to understand from its internal
dependency graph that the compiled .class file is running on the JVM to
be able to push an update to that JVM.
The situation you present sounds like you have a web-app running under
TC under the IDE and another standalone java project in the IDE. If you
edit this standalone project sure you get a compiled .class file out of
it, but why would the IDE then offer it up to the TC JVM ? For all
intents and purposes the standalone project is disconnected from the
running web-app.
Since Eclipse WTP 1.0 you can create a J2EE Utility Project which can
contribute a JAR into the WEB-INF/lib of J2EE Dynamic Web Project
(create those 2 project types, goto the Project Properties page J2EE
Module Dependancy of the DWP and tick the box). You can have both
projects open and develop them at the same time with the IDE
automatically propagating the new compiled code.
This feature is still not perfect since TC will auto-redeploy when a JAR
changes, the WTP feature would be better if it had a toggle to allow the
J2EE Utility Project exported as individual .class files into the
WEB-INF/classes tree this would allow Eclipse to attempt a Hot-code
replace and thwart some unnecessary TC reloading.
In any case if you alter the fields of a class which has one or more
active instances Sun's JVM doesn't allow that class to be
hot-code-replaced you get an error and Eclipse offers to
continue/restart/shutdown the JVM. But there are many common cases
where it works well, like adding/changing methods.
Eclipse's solution is nearer my vision of the future and generic this
makes it future proof to me. What you are proposing as a solution to
this problem is a band aid, a dead end; that prohibits the next step to
be taken by the IDE towards the ultimate seamless developer experience.
Geez I should try marketing.
Effectively adding a deploy step so you have
edit-compile-deploy. Which is exactly what I am trying to avoid albeit if
it is properly contained in the IDE it is less of a headache.
This is back to my opening question. Which bit is the tedious task for
you at this time ? The "having to click a button", the "compile, build
JAR, copy JAR to web-app" or the "waiting for the reploy to complete" ?
These were (before WTP 1.0) the only productivity killers for me.
The first and second problem have been solved.
The third problem has room for improvement (by reducing the cases where
a redeploy is necessary) but at this time serves a useful purpose of
flushing out the old version of code from the container, causing the
container to re-read tag descriptors, causing the container to flush all
tag-pools, causing the web-app to re-read config files, blah blah, so
there are still many changes where a redeploy just can't be avoided.
I enjoy the discussion of good practices (I don't think there is a one size
fits all best practice here) for having a smooth development process so
keep
it coming ;-)
There are a number of little gems of info that maybe useful, like making
sure you setup a META-INF/context.xml and use a <Context ... debug="1"
reloadable="false"> then sit back and let Eclipse do the right thing.
Eclipse itself has room for improvement, like it shouldn't update the
timestamp on files which have not changed. The container correctly
thinks it is a new file version when infact no net change occured but
the lame building tools updated the target anyway. There are some
really lame components which truncate files to rebuild them, rather than
write to a .tmp file, do an overwrite-if-modified check. These things
all contribute to unnecessary web-app redeploys which impedes productivity.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
