geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Woldrich (JIRA)" <j...@apache.org>
Subject [jira] Created: (GERONIMODEVTOOLS-645) Deploy JEE artifacts in-place to developer support tools like JRebel
Date Sat, 12 Jun 2010 08:24:12 GMT
Deploy JEE artifacts in-place to developer support tools like JRebel
--------------------------------------------------------------------

                 Key: GERONIMODEVTOOLS-645
                 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-645
             Project: Geronimo-Devtools
          Issue Type: Improvement
          Components: eclipse-plugin
    Affects Versions: 2.1.5
         Environment: Windows XP SP4, Eclipse Galileo, ZeroTurnaround JRebel 3.1
            Reporter: Dave Woldrich
            Assignee: Delos Dai


I have been working with ZeroTurnaround tech support to get Geronimo support for their JRebel
java redeployment tool.  I'm starting to realize though, for JRebel to work, Geronimo eclipse-plugin
must use in-place deployments to Geronimo for me to benefit from JRebel's auto-redeployment
of my program's assets.  As I understand it, Geronimo's Eclipse Plugin does deployments by
building a temp .WAR/.EAR zip and deploying that.  JRebel never sees a redeployment opportunity
as a result, and I do not gain the benefits of not having to constantly redeploy in order
to test small changes to my JEE apps.

JRebel hooks the runtime environment in Geronimo's JVM at various classloader and API levels
to observe changes to Java classes, JEE deployment descriptors, and many 3rd party API config
files - and then triggers the correct API or Java VM internals operations to asynchronously
trigger reloads when changes are detected on those files.  

For eclipse-plugin to perform a true in-place deployment from Eclipse projects, it would have
to map output artifact folders to the correct place in the JEE deployment unit formats.  I'm
not sure the inplace deployer that the Geronimo team provides is that sophisticated.  I suspect
Java project dependencies destined for WEB-INF/lib in War projects would be especially tricky
to map properly.  There might need to be some collaboration with the Geronimo team to make
something like this happen.

A secondary, but completely valid way for the plugin to exploit JRebel would be to build a
temp copy of the .war or .ear assets and then constantly copy changed files from the eclipse
workspace project folders to the correct destination in the deployment temp folders.

I have partially succeeded at doing an inplace deployment using an ant script and seen JRebel
running with Geronimo react to changes I made to files within Eclipse, so I know JRebel could
be a valuable tool to run with Geronimo to speed build-deploy-test cycle times.

Thanks,
Dave W

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message