Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Tycho and Concurrent Builds: error in opening zip file? 
I believe this is a general problem with Maven and per-build local
repository is usually used as a workaround.

I am not sure if this will work for Tycho projects, but for plain Maven
there is multiprocess-safe local repository implementation [1] (requires
maven 3.1.x).

[1] https://github.com/tesla/tesla-concurrent-localrepo

--
Regards,
Igor

On 11/14/2013, 13:07, Mongiat, Johnny wrote:

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.


_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user

Back to the top