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] Commented: (GERONIMODEVTOOLS-645) Deploy JEE artifacts in-place to developer support tools like JRebel
Date Sat, 12 Jun 2010 08:26:13 GMT

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


Mime
View raw message