Community
Participate
Working Groups
During last releng activities some zips packaging have been disabled due to unknown errors. Investigate what to do to enable them again.
Originally this problem manifested with the Tools build. Recently, this has also manifested with the Core build. Working in the Core build, firstly.
Well, After successfully trying to reproduce the issue in local, I think that I've discovered the problem in the . To summarize and try to avoid confusing explanations: - The problem arose when solving the UML Plugin tests (Bug 358801) in which I managed to make the the org.eclipse.uml2.uml plugin available in the workspace rather than in the target.platform. - This plugin was needed to be in the TP to make the zips packaging ant scripts work. Since it's not there any more the scripts fail. I've already do some hacks to make the UML Plugin tests pass (uml.tests plugin launch config, ocl-core.rmap file). I could try some "hacks" in the building (packaging step) phase. However I'm wondering if this is a more pragmatical way instead of a coherent one. In my opinion I'd deactivate the UML plugin tests (standalone works fine) and wait for a proper solution for Bug 358801 and/or Bug 358759. P.S: I had a comment for the Bug 358801 in local, which I hadn't submitted... submitting in a little bit.
Well, Since we have not received any complain (yet) about these specific missed packaged zips, I'll deactivate such a packaging until we find a proper solution. Regards, Adolfo.
Once the uml plugins are in the target platform again, the Core build zips packaging is working. Waiting for the Tools one to see what happens with it.
Both Core and Tools builds contain the proper zips. Resolving as fixed.
Tests job fails with this fix. ZIPS packaging have been deactivated again until the job might be debugged and fixed.
I have no use for the ZIPs, but EMF and UML2 are now producing them again so I guess we should too. But perhaps just the traditional Core ZIPs. New users can use P2.
Tools build now fails without comprehensive error when SDK/examples packaging is enabled again [1]. Rather than waiting for the long-running hudson builds, I've tried to track the problem in local. I've spent the afternoon working on it trying to reproduce the failure with very disappointing results. I haven't even been able to to do a local import of sources. By some reason I don't understand, some of the required OCL examples projects are not imported into my local workspace, just some of them... Re-importing, still detects that it requires to be imported, but they are not imported after all. I give up... I'll build OCL Tools RC4 without packaging those specific zips. The zip with the update site containing all features and plugins should be produced as always. [1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-tools-kepler-master/466/ ... INFO: [start org.eclipse.ocl.releng.tools.build:eclipse.feature$1.1.0.qualifier#package.mdt-ocl-SDK] ERROR: org.eclipse.core.runtime.CoreException: /opt/buildhomes/hudsonBuild/workspace/buckminster-mdt-ocl-tools-kepler-master/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.tools.build-feature/packaging.ant:179: Java returned: 13 org.eclipse.core.runtime.CoreException: /opt/buildhomes/hudsonBuild/workspace/buckminster-mdt-ocl-tools-kepler-master/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.tools.build-feature/packaging.ant:179: Java returned: 13 at org.eclipse.buckminster.ant.AntRunner.handleInvocationTargetException(AntRunner.java:167) at org.eclipse.buckminster.ant.AntRunner.run(AntRunner.java:322) at org.eclipse.buckminster.ant.actor.AntActor.internalPerform(AntActor.java:254) at org.eclipse.buckminster.core.actor.AbstractActor.perform(AbstractActor.java:195) at org.eclipse.buckminster.core.internal.actor.PerformManager$DirectActionInvocation.execute(PerformManager.java:143) at org.eclipse.buckminster.core.internal.actor.PerformManager.internalPerform(PerformManager.java:454) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:293) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:305) at org.eclipse.buckminster.core.commands.Perform.internalRun(Perform.java:108) at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:91) at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:200) at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:350) at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:145) at org.eclipse.buckminster.cmdline.Headless.start(Headless.java:165) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Nobody has complained about missing ZIPs. If Luna SR0 goes by without further comment: WONTFIX.
(In reply to Ed Willink from comment #9) > Nobody has complained about missing ZIPs. The QVTd builds extend test classes and so could use the tests ZIP. At present QVTd builds instead use GIT master which can lead to some synchronisation surprises, which are made MUCH worse by a Buckminster/GIT bug whereby autofetch doesn't seem to refresh the GIT repo! I've twice spent time debugging spurious QVTd/OCL build synchronization bugs. Now that the OCL Core/Tools builds are combined, maybe the weird error preventing build of a tests ZIP during a Tools build will not occur. Time for another try.
(In reply to Ed Willink from comment #10) > The QVTd builds extend test classes and so could use the tests ZIP. All that is really needed is for the test plugins to be in the P2 repo, which is easily achieved by including them in the org.eclipse.ocl.releng.build feature.xml. Hopefully this doesn't upset the contribution to the aggregator. > Now that the OCL Core/Tools builds are combined, maybe the weird error > preventing build of a tests ZIP during a Tools build will not occur. Time > for another try. Building a tests ZIP gives a Java 13 for no obvious reason. Probably one step has deleted something that was needed. There is a confusing duplication of a ZIP-like ZIp ...-core and a P2-like ZIP ...CoreSDK that may contribute to the trouble. I can't see the benefit in producing a reduced size P2 repo.
After the usual amount of Hudson/Buckminster pain... Test plugins are now in the P2 repo, with a distinct category. QVTd build is simplified. A tests ZIP is produced as a side effect but not published. Probably just lose it. RESOLVED on so far as test plugins are now available in the P2 repo for extending applications. WONTFIX in so far as old-style tests ZIPs are discontinued. (Our main legacy customer has not commented for years; IBM now distribute unauthorised plugins that extend earlier regimes.)
(In reply to Ed Willink from comment #11) > Hopefully this doesn't upset the contribution to the aggregator. Which uses the named contributed features rather than the potential features so the new tests stuff is just ignored.
CLOSED after more than a year in the RESOLVED state.
