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