Community
Participate
Working Groups
Build Identifier: 0.12.0 This bug has been already reported in Sonatype's JIRA: https://issues.sonatype.org/browse/TYCHO-408 Once in a while, Tycho builds start to fail with an error message like this: message : Internal error: java.lang.IllegalArgumentException: Invalid portable string: 3 cause : Invalid portable string: 3 In this case it's 3 but it can be anything, like 0.v20100503 for example. To fix it, I had to modify the file ~/.m2/repository/.meta/p2-artifacts.properties and search for the version name (0.v20100503) until I found the faulty lines: p2.osgi.bundle:org.eclipse.equinox.simpleconfigurator.manipulator.source:2.0 0.v20100503 i.e, the version was in it's own line. Simply deleting this line and rebuilding fixed the issue. Here is the complete stacktrace: org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: Invalid portable string: 0.v20100503 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:128) at hudson.maven.Maven3Builder.call(Maven3Builder.java:75) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.IllegalArgumentException: Invalid portable string: 0.v20100503 at org.eclipse.tycho.p2.repository.GAV.nextColonIndex(GAV.java:103) at org.eclipse.tycho.p2.repository.GAV.parse(GAV.java:81) at org.eclipse.tycho.p2.repository.DefaultTychoRepositoryIndex.read(DefaultTychoRepositoryIndex.java:54) at org.eclipse.tycho.p2.repository.LocalTychoRepositoryIndex.<init>(LocalTychoRepositoryIndex.java:33) at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.setLocalRepositoryLocation(P2ResolverImpl.java:574) at org.eclipse.tycho.p2.facade.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:185) at org.eclipse.tycho.p2.facade.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:150) at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:90) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) ... 19 more Reproducible: Sometimes Steps to Reproduce: No particular sequence to reproduce. It just happens once in a while.
I think this relates to multi-process-safe loal repo. Jason just told me this was fixed in a newer maven version, but I can't find any comments here http://jira.codehaus.org/browse/MNG-2802 Probably we should do something similar in tycho, so Jason can you give us some hints/pointers?
Tycho maintains it's own metadata files in local repository and needs to synchronize access to them regardless of any Maven improvements.
I know. I was just curious how maven solved a similar problem.
looks like java.nio.channels.FileLock is what we need to synchronize access to tycho's local repo metadata files across multiple processes.
I believe the issue is more complicated than that. FileLock maps directly to underlying operating system locking mechanisms and getting consistent/desired high-level locking behaviour for both inter- and intra- process scenarios even on three major operating systems (i.e. win, osx, linux) is rather tricky as far as I know. The locking code Jason mentioned is expected to become opensource in "few weeks" I am told, so may make sense to wait.
IMHO allowing concurrent access to the local repository is a different story. This issue should be fixed independantly, either by 1) improving the error message, and/or 2) ignoring the error cases From the discussion in TYCHO-408 I thought that just adding a line break in the .meta/p2-artifacts.properties is enough to reproduce the problem: (I haven't tried though.) p2.osgi.bundle:org.eclipse.equinox.simpleconfigurator.manipulator.source:2.0<br> 0.v20100503
org.eclipse.core.runtime.internal.adaptor.Locker is another candidate. Corrupted local repository metadata is the root cause of this problem. I don't believe improving error message will help matters much, as the problem will continue to affect users albeit with better/cleaner explanation.
(In reply to comment #7) > Corrupted local repository metadata is the root cause of this problem. I don't > believe improving error message will help matters much, as the problem will > continue to affect users albeit with better/cleaner explanation. The build doesn't need to fail. We could just warn about the corrupt p2-metadata.properties, delete it, and see if the build passes. Then only users who really need the p2-metadata.properties feature would be affected.
Here's another manifestation of this bug: In my tycho build, I came across the exception below. Advice on the tycho mailing list was to delete directory ~/.m2/repository/.meta/, which indeed solved the problem. [INFO] Resolving target platform for project MavenProject: de.upb.dmm:de.gupro.gxl:1.0.0-SNAPSHOT @ C:\Program Files (x86)\Jenkins\workspace\DMM-Tooling\de.gupro.gxl\pom.xml [ERROR] Internal error: java.lang.NullPointerException -> [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException 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: java.lang.NullPointerException at org.eclipse.tycho.p2.repository.RepositoryLayoutHelper.getRelativePath(RepositoryLayoutHelper.java:67) at org.eclipse.tycho.p2.repository.LocalRepositoryReader.getLocalArtifactLocation(LocalRepositoryReader.java:25) at org.eclipse.tycho.p2.maven.repository.AbstractMavenArtifactRepository.loadMaven(AbstractMavenArtifactRepository.java:87) at org.eclipse.tycho.p2.maven.repository.AbstractMavenArtifactRepository.<init>(AbstractMavenArtifactRepository.java:73) at org.eclipse.tycho.p2.maven.repository.LocalArtifactRepository.<init>(LocalArtifactRepository.java:49) at org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.<init>(ResolutionContextImpl.java:147) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:32) at org.eclipse.tycho.p2.impl.resolver.P2ResolverFactoryImpl.createResolutionContext(P2ResolverFactoryImpl.java:1) at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:156) at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) ... 11 more
My build have been plagued by this bug from sometime. I am wondering if there are any plans to fix this bug or any know work arounds. Thanks.
(In reply to comment #10) > My build have been plagued by this bug from sometime. I am wondering if there > are any plans to fix this bug or any know work arounds. > > Thanks. The current workaround is to have each build use a different local repository. This can be done by specifying a different settings file on the command line (-s /some/different/settings.xml) that includes a <localRepository>/some/other/repository/</localrepository> within the <settings> tag.
Jan, you were working on this, right?
(In reply to comment #12) > Jan, you were working on this, right? I will try to get this into 0.14.0 I have a first implementation of file-based locking on the tycho index files running but this part of the code needs some refactoring before I can add the file locking logic.
http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=cf454629d9727797d9b5c1ad684d75ae49825603
We're still getting this error, despite being on 0.15.0. It seems to be very intermittent, though. I've been trying to chase it down, but since the files get corrupted very seldom (about once every 2 weeks) it's been hard. Could it be that we have the .m2 repository on an NFS-mounted disk?
(In reply to comment #15) > We're still getting this error, despite being on 0.15.0. It seems to be very > intermittent, though. > I've been trying to chase it down, but since the files get corrupted very > seldom (about once every 2 weeks) it's been hard. Could it be that we have > the .m2 repository on an NFS-mounted disk? yes NFS is probably the reason. We use java.nio.File locks to protect the index file from concurrent access by several (tycho) processes. There are known bugs with NFS and native file locking [1,2,3]. Consider moving your tycho build to another FS. [1] http://bugs.sun.com/view_bug.do?bug_id=6628575 [2] http://lucene.apache.org/core/old_versioned_docs/versions/3_0_1/api/core/org/apache/lucene/store/NativeFSLockFactory.html [3] https://issues.apache.org/jira/browse/LUCENE-673
Created attachment 223028 [details] Invalid portable string: p2.org.eclipse.update.feature:org.eclipse.wst.common_core I fear that the problem still exists with Tycho 0.15.0. Got: java.lang.IllegalArgumentException: Invalid portable string: p2.org.eclipse.update.feature:org.eclipse.wst.common_core at org.eclipse.tycho.p2.repository.GAV.nextColonIndex(GAV.java:104) at org.eclipse.tycho.p2.repository.GAV.parse(GAV.java:86) ... (see attached trace.txt for full stack trace) Note: Last line of "p2-artifacts.properties" is "p2.org.eclipse.update.feature:org.eclipse.wst.common_core". There is no wrapped version number. (see attached p2-artifacts.properties) Environment: - Ubuntu 9.10 - FS Type: ext4 - JDK 1.6.0_33 64-bit - Tycho 0.15.0 - Maven 3.0.4 - Jenkins job with *private* local Maven repository - Using Eclipse Juno Update Site
Created attachment 223029 [details] p2-artifacts.properties: p2.org.eclipse.update.feature:org.eclipse.wst.common_core
(In reply to comment #18) > Created attachment 223029 [details] > p2-artifacts.properties: > p2.org.eclipse.update.feature:org.eclipse.wst.common_core is the problem reproducible? Note that: - if any pre-tycho 0.14 build accesses this repo, it will still be corrupted - any manual editing/other unrelated processes accessing this file can also cause a corrupt index file
> is the problem reproducible? Note that: Unfortunately no... deleting the corruped file fixed the problem (for now) > - if any pre-tycho 0.14 build accesses this repo, it will still be corrupted Build process was set up with an empty and "private" local repository and was never run with any tycho pre 0.15. We also had succesfull build runs before the problem occured. > - any manual editing/other unrelated processes accessing this file can also > cause a corrupt index file The file wasn't edited manually nor accessed by another build process. Note: The build process has its very own private mave repository (to avoid any side effects).
(In reply to comment #20) another way to potentially corrupt the index file is by killing the build process. I wonder if we could be more lenient here and just warn and ignore invalid lines in the tycho index files while reading. I.e. next time the index file is written, corrupted lines are gone.
Things have definitely been improved with 0.14, so this bug is justified to be closed. If you are still experiencing the same symptoms, please open a new bug.
I just saw this bug on CDT's HIPP machine with exception: java.lang.IllegalArgumentException: Invalid portable string: .v20140827-1444 See below for full exception. I had to edit: ~/.m2/repository/.meta/p2-artifacts.properties and remove the two lines: p2.osgi.bundle:org.eclipse.ecf.filetransfer:null .v20140827-1444 Looks like things are working again after that. Full exception: org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: Invalid portable string: .v20140827-1444 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:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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: java.lang.IllegalArgumentException: Invalid portable string: .v20140827-1444 at org.eclipse.tycho.p2.repository.GAV.nextColonIndex(GAV.java:104) at org.eclipse.tycho.p2.repository.GAV.parse(GAV.java:82) at org.eclipse.tycho.p2.repository.DefaultTychoRepositoryIndex.read(DefaultTychoRepositoryIndex.java:85) at org.eclipse.tycho.repository.local.index.FileBasedTychoRepositoryIndex.<init>(FileBasedTychoRepositoryIndex.java:48) at org.eclipse.tycho.repository.local.index.FileBasedTychoRepositoryIndex.createArtifactsIndex(FileBasedTychoRepositoryIndex.java:118) at org.eclipse.tycho.repository.local.index.LocalRepositoryP2IndicesImpl.checkInitialized(LocalRepositoryP2IndicesImpl.java:56) at org.eclipse.tycho.repository.local.index.LocalRepositoryP2IndicesImpl.getArtifactsIndex(LocalRepositoryP2IndicesImpl.java:62) at org.eclipse.tycho.p2.resolver.PomDependencyProcessor.collectPomDependencies(PomDependencyProcessor.java:48) at org.eclipse.tycho.p2.resolver.P2DependencyResolver.collectPomDependencies(P2DependencyResolver.java:287) at org.eclipse.tycho.p2.resolver.P2DependencyResolver.computePreliminaryTargetPlatform(P2DependencyResolver.java:197) at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:99) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
(In reply to Marc Khouzam from comment #23) > I just saw this bug on CDT's HIPP machine with exception: > > java.lang.IllegalArgumentException: Invalid portable string: .v20140827-1444 BTW, we're using tycho 0.21.0
Either you have a pre-0.14.0 Tycho version using the same local Maven repository, or the underlying file system is unable to do proper file locking. And BTW, discussing on closed bugs is a bad idea. If you can reproduce the problem, please open a new bug.
(In reply to Tobias Oberlies from comment #25) > And BTW, discussing on closed bugs is a bad idea. If you can reproduce the > problem, please open a new bug. I just got the problem again and opened Bug 457249.
