Community
Participate
Working Groups
New JRebel plugin will feature breaking changes, and it will be released in June. With the new JRebel, CFT JRebel support will no longer be possible According to JRebel team: "The changes you should make include org.eclipse.cft.server.core.internal.jrebel.CloudRebelAppHandler class on line 468. https://github.com/eclipse/cft/blob/d89c0976cb983d3aa2bd22487120bbff1a375312/org.eclipse.cft.server.core/src/org/eclipse/cft/server/core/internal/jrebel/CloudRebelAppHandler.java#L468 Platform.getBundle("org.zeroturnaround.eclipse.remoting") should be replaced with Platform.getBundle("org.zeroturnaround.eclipse") If there are more occurrences of above mentioned string constants, then please replace these with the "org.zeroturnaround.eclipse" as well." It seems non-intrusive changes (just changing IDs), so we may consider this for CFT 1.0.RC3
The JRebel plugins are being installed separately. Do we have to consider to support both the old and new versions at the same time to ensure maximum compatibility? Is there any changes other the bundle discovery that we have to do? If the only thing that needs to be changed is the plugin id during the looking, maybe the new code should try to accommodate both the new and old version by doing Platform.getBundle("org.zeroturnaround.eclipse") first, if it returns null, then try the old one by doing Platform.getBundle("org.zeroturnaround.eclipse.remoting"). If we do that, it will work with both old and new version of the JRebel plugin provided that there is no other changes needed.
I was thinking the same, it seems we can accommodate both old and new JRebel plugin with the current code with minimal changes to the class: CloudRebelAppHandler following Elson's suggestion. I can even try to fit this into RC2 if we get PMC approval by tomorrow (Wednesday, May 25). Otherwise, we can do it for RC3. This change seems very localised just to the CloudRebelAppHandler, and very short work, so it seems safe to do even for RC2 with some smoke-testing around JRebel.
+1 from my end. Please try to commit to RC2.
Changes pushed to 1.0.RC2. We still have to do a bit more testing, especially on the JRebel side, but junits and smoketesting using Pivotal Web Services and STS all passed. This change is also now in Neon Simultaneous Release RC2.
Unfortunately there are further issues with the JRebel integration aside from adopting new JRebel plugin with refactored IDs. Some deprecated API to set application URL in JRebel do not work anymore. As Neon development has stopped, and there is a manual workaround for JRebel usage (users can always set application URL manually via JRebel UI), we will postpone fixing this issue until after Neon, or make it available in a separate snapshot that is not part of Neon SimRel and Neon JEE package.
Resolving this as new JRebel support was already added to CFT 1.0.
