[jira] Commented: (GERONIMODEVTOOLS-645) Deploy JEE artifacts in-place to developer support tools like JRebel

["Dave Woldrich (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878233#action_12878233 ] 

Dave Woldrich commented on GERONIMODEVTOOLS-645:
------------------------------------------------

Link to JRebel site:  http://www.zeroturnaround.com/jrebel/

> 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.