Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tycho-user] Tycho and Concurrent Builds: error in opening zip file?

Hello,
 
I’m facing an interesting problem when building with Tycho (v0.18.0) in a continuous integration environment. I have a multi-component system, where each component is a Tycho-based project (i.e. each component has its own plugins, features, and repository), and the inter-component dependencies follow the standard tree-based hierarchy. For instance, I have a component A which provides “core” plugins/features that other downstream components (let’s call them component B, and component C) need to consume. The .target for each of these “downstream” components, would include the necessary dependencies from component A’s p2 repository. Components B and C have no dependencies on each other, so our dependency graph becomes:
 
  B <- - - - A - - - -> C
 
In theory, when I build these 3 components in a continuous integration environment (I’m using Hudson), I would like to take advantage of Hudson’s parallelization/concurrent build support by having a build job for A, which upon successful completion, triggers a build of both components B and C (i.e. each components has its own corresponding Hudson job configuration). Unfortunately, in practice I keep getting the following build failure stack (e.g.  Component C build log):
 
[INFO] Resolving class path of MavenProject: com.acme.componentC:com.acme.componentC:1.0.0-SNAPSHOT @ C:\Builds\workspace\ComponentC-trunk-NIGHTLY\com.acme.componentC\pom.xml
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.core.osgitools.OsgiManifestParserException: Exception parsing OSGi MANIFEST C:\Users\build\.m2\repository\p2\osgi\bundle\com.acme.componentA.foo\4.0.0.v050000_201311141629_86\com.acme.componentA.foo-4.0.0.v050000_201311141629_86.jar: error in opening zip file
[DEBUG] Closing connection to remote
[ERROR] Internal error: org.eclipse.tycho.core.osgitools.OsgiManifestParserException: Exception parsing OSGi MANIFEST C:\Users\build\.m2\repository\p2\osgi\bundle\com.acme.componentA.foo\4.0.0.v050000_201311141629_86\com.acme.componentA.foo-4.0.0.v050000_201311141629_86.jar: error in opening zip file -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.core.osgitools.OsgiManifestParserException: Exception parsing OSGi MANIFEST C:\Users\build\.m2\repository\p2\osgi\bundle\com.acme.componentA.foo\4.0.0.v050000_201311141629_86\com.acme.componentA.foo-4.0.0.v050000_201311141629_86.jar: error in opening zip file
         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
         at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
         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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
         at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
         at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
         at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
  Caused by: org.eclipse.tycho.core.osgitools.OsgiManifestParserException: Exception parsing OSGi MANIFEST C:\Users\build\.m2\repository\p2\osgi\bundle\com.acme.componentA.foo\4.0.0.v050000_201311141629_86\com.acme.componentA.foo-4.0.0.v050000_201311141629_86.jar: error in opening zip file
         at org.eclipse.tycho.core.osgitools.DefaultBundleReader.doLoadManifest(DefaultBundleReader.java:69)
         at org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifest(DefaultBundleReader.java:51)
         at org.eclipse.tycho.core.osgitools.EquinoxResolver.loadManifest(EquinoxResolver.java:247)
         at org.eclipse.tycho.core.osgitools.EquinoxResolver.newState(EquinoxResolver.java:156)
         at org.eclipse.tycho.core.osgitools.EquinoxResolver.newResolvedState(EquinoxResolver.java:64)
         at org.eclipse.tycho.core.osgitools.OsgiBundleProject.getResolverState(OsgiBundleProject.java:250)
         at org.eclipse.tycho.core.osgitools.OsgiBundleProject.resolveClassPath(OsgiBundleProject.java:158)
         at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:122)
         at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:82)
         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273)
         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
         ... 11 more
  Caused by: java.util.zip.ZipException: error in opening zip file
         at java.util.zip.ZipFile.open(Native Method)
         at java.util.zip.ZipFile.<init>(ZipFile.java:127)
         at org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifestFromFile(DefaultBundleReader.java:79)
         at org.eclipse.tycho.core.osgitools.DefaultBundleReader.doLoadManifest(DefaultBundleReader.java:62)
         ... 21 more
 
There is no issue with the jar file itself (i.e. it is not corrupt, etc.). If I flatten the build pipeline, say A - - - > B - - - > C, then everything builds fine. But this is not an optimized build pipeline. I can’t say for sure, but perhaps the issue may be related to the fact that upon downloading of the dependant jar (from Component’s A repository), perhaps triggered by the Hudson build for Component B, Component C’s build is trying to open the jar, but the jar may not have been fully downloaded yet (i.e. these builds are executed concurrently, and configured to use the same local Maven repository, and hence the same p2\osgi\bundle location).
 
Is my observation correct, or could there be another reason? 
 
Perhaps, I could try to configure the build jobs for B and C to use their own “private” maven repository to avoid the contention; however, this will drastically increase disk space usage on the build machine which can be problematic in a constrained environment (especially when the component hierarchy extends to deeper levels)…
 
Thanks,
Johnny 
 
Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

Back to the top