]
Nick Boldt commented on JBIDE-17025:
------------------------------------
If it helps to ease the migration effort, you can use OUR target platforms for Kepler [1]
and Luna [2], and compare their contents using the p2diff [3] and p2browser [4] tools.
[1]
I also recommend a visual diff tool like Beyond Compare [5] if you want to see what files
appear in two target platform folders on disk.
[5]
And, if you want some tooling to create & validate a target platform you're
building for your RCP app, have a look at this stuff [6], [7]:
[6]
Patching EAP 6.2 breaks classpath jar files
-------------------------------------------
Key: JBIDE-17025
URL:
https://issues.jboss.org/browse/JBIDE-17025
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: server
Affects Versions: 4.1.2.Final
Environment: Windows 7, Kepler SR2
Reporter: Jesper Skov
Assignee: Rob Stryker
Priority: Blocker
Fix For: 4.2.0.Beta2
Using the JBoss CLI command 'patch apply .../eap-6.2.2.zip' breaks some of the
module jars (the files become invalid ZIP-archives).
This is apparently done as a way to mark the modules off-limits for the container, while
still allowing roll-back if necessary.
See
https://access.redhat.com/site/discussions/726623
Unfortunately, Eclipse includes these jars in the JBossTools-defined classpath. When
scanned, these will be found corrupt, and the project classpath marked as broken.
On my installation, the first few files to trigger this problem are:
*
modules/system/layers/base/javax/el/api/main/jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar
*
modules/system/layers/base/javax/el/api/main/jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar
I guess it might be possible to adjust the server definition's Default Classpath
Entries in Eclipse preferences. But I decided to just copy the original EAP 6.2 files on
top of the runtime and get on with work...