Hi Andrey / Everyone,
I pushed to the cbi repos modifications to the MANIFEST.MF files to
add "Eclipse-BundleShape: dir" for the 5 plugins listed that were
being deployed as jars instead of as a directory. I checked and they
seem to be deploying as directories now.
These changes were pushed to both the R3 and R4 repos.
Let me know if I missed anything,
Thanh
On 07/06/2012 10:09 AM, Andrey Loskutov wrote:
Hi all,
I was happy today to build eclipse 3.8 from scratch, including
native libraries. Thanks you all for your effort!
Unfortunately there are few glitches in the generated artifacts.
There are few plugins deployed as directories in the "eclipse.org"
build which were now deployed as jars:
"3.8 from eclipse.org":
org.eclipse.core.runtime.compatibility.registry_3.5.100.v20120521-2346
org.eclipse.platform_3.8.0.v201206081200
org.eclipse.sdk_3.8.0.v201206081200
org.eclipse.ui.intro.universal_3.2.600.v20120521-2344
org.eclipse.ui.workbench.compatibility_3.2.101.v20120523-1956
"3.8 custom":
org.eclipse.core.runtime.compatibility_3.2.200.201207061258.jar
org.eclipse.platform_3.8.0.201207061258.jar
org.eclipse.sdk_3.8.0.201207061258.jar
org.eclipse.ui.intro.universal_3.2.600.201207061258.jar
org.eclipse.ui.workbench.compatibility_3.2.101.201207061258.jar
This breaks some plugins (results in such errors at runtime):
java.lang.NoClassDefFoundError:
org/eclipse/core/runtime/IPluginDescriptor
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
at java.lang.Class.getDeclaredMethod(Class.java:1952)
at
org.eclipse.ui.internal.EarlyStartupRunnable.getPluginForCompatibility(EarlyStartupRunnable.java:138)
at
org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:73)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.ui.internal.Workbench$63.run(Workbench.java:2470)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.core.runtime.IPluginDescriptor
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 8 more
Second, it looks like SWT build is not optimal yet: AFAIK SWT
maintains their own very special build and version schema, and so
the generated jar has wrong version/content (see attached
picture):
"3.8 from eclipse.org":
org.eclipse.swt_3.8.0.v3833.jar 18 KB
"3.8 custom":
org.eclipse.swt_3.8.0.201207061258.jar 7.2 MB
However this seems not break the UI (after quick smoke test).
And last one: even if I specified to re-build swt native binaries
on Linux 64 gtk, they still contain parts built on eclipse.org:
libcairo-swt.so
libswt-mozilla-gtk-3833.so
libswt-xpcominit-gtk-3833.so
libswt-xulrunner-fix.so
libswt-xulrunner-gtk-3833.so
I guess there are some preconditions for the build (like
xulrunner/mozilla SDK installed) which are not considered by the
maven build. I wonder if this can/should be manual step before the
build, or can be done by maven downloading those SDK's to the
build area.
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
|
