- This topic has 6 replies, 3 voices, and was last updated 17 years, 2 months ago by
.
-
Posts
-
Nipun, is there already some further feedback you can give about this issue?
Is there someway for me to trigger a redeployment programmatically? Pending the solution to this bug I may write a small plugin that monitors the directories in question and calls for a redeployment if it detects any changes.
Redeployment cannot be triggered programmatically. I guess the only workaround right now would be to redeploy when you add a jar.
@support-nipun wrote:
Redeployment cannot be triggered programmatically. I guess the only workaround right now would be to redeploy when you add a jar.
There’s another workaround that may or may not be satisfactory; remove the libraries in question from .classpath. Add a simple ant builder (project->properties->builders->new) that calls an ant script, which copies all .jar files recursively to web-inf/lib with the overwrite property set to false. In the “build options” tab for the new ant builder you can specify that the script should trigger only when something in the location where you store your original libraries changes.
Since the copied .jar files count as derived files, you can mark them as such, and keep them out of the version control system.
Depending on your ant skills, you might of course prefer to write the same thing in Java code 😉
Anyway, the key thing is that dropping something in WEB-INF/lib is the signal to MyEclipse to start a hot-deploy, and that’s what your script or code can take advantage of.
The best thing would be of course if MyEclipse after scanning .classpath for the first time remembers what entries are in it, and monitors them (i.e. fixing this bug)
