This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 227634 - org.netbeans.modules.parsing.spi.ParseException: The file org/erasmusmc/ontology/Ontology.class in /home/reinout/.m2/repository/org/erasmusmc/ontology/0.0.1/ontology-0.0.1.jar is not owned by provided
Summary: org.netbeans.modules.parsing.spi.ParseException: The file org/erasmusmc/ontol...
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.3
Hardware: All All
: P3 normal (vote)
Assignee: Milos Kleint
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-18 15:48 UTC by reinouts
Modified: 2014-01-17 11:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 194292

Attachments
stacktrace (3.47 KB, text/plain)
2013-03-18 15:49 UTC, reinouts 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description reinouts 2013-03-18 15:48:58 UTC 
This issue was reported manually by reinouts.
It already has 4 duplicates 


Build: NetBeans IDE 7.3 (Build 201302132200)
VM: OpenJDK 64-Bit Server VM, 23.7-b01, OpenJDK Runtime Environment, 1.7.0_09-icedtea-mockbuild_2013_03_05_06_18-b00
OS: Linux

User Comments:
reinouts: Executed 'Find Usages' on a class member.




Stacktrace: 
org.netbeans.modules.parsing.spi.ParseException: The file org/erasmusmc/ontology/Ontology.class in /home/reinout/.m2/repository/org/erasmusmc/ontology/0.0.1/ontology-0.0.1.jar is not owned by provided classpaths, boot: /usr/java/jdk1.6.0_22/jre/lib/resources.jar:/usr/java/jdk1.6.0_22/jre/lib/rt.jar:/usr/java/jdk1.6.0_22/jre/lib/sunrsasign.jar:/usr/java/jdk1.6.0_22/jre/lib/jsse.jar:/usr/java/jdk1.6.0_22/jre/lib/jce.jar:/usr/java/jdk1.6.0_22/jre/lib/charsets.jar:/usr/java/jdk1.6.0_22/jre/classes:/usr/java/jdk1.6.0_22/jre/lib/ext/sunpkcs11.jar:/usr/java/jdk1.6.0_22/jre/lib/ext/localedata.jar:/usr/java/jdk1.6.0_22/jre/lib/ext/dnsns.jar:/usr/java/jdk1.6.0_22/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/jce.jar:/u
   at org.netbeans.modules.java.source.parsing.ClassParser.parse(ClassParser.java:137)
   at org.netbeans.modules.parsing.impl.TaskProcessor.callParse(TaskProcessor.java:596)
   at org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.java:236)
   at org.netbeans.modules.parsing.api.ResultIterator.getParserResult(ResultIterator.java:138)
   at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:480)
   at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:584)
Comment 1 reinouts 2013-03-18 15:49:00 UTC 
Created attachment 132765 [details]
stacktrace
Comment 2 Milos Kleint 2013-03-18 17:34:38 UTC 
tzezula: any hint what this error means? there's nothing apparently maven in the stacktraces only the classpaths provider appear to come from maven projects. I'm a bit clueless in terms how to track the problem (and what the problem actually is) thanks.
Comment 3 Tomas Zezula 2013-03-18 17:43:20 UTC 
Sorry: The exception means that while parsing the file org/erasmusmc/ontology/Ontology.class in the root  /home/reinout/.m2/repository/org/erasmusmc/ontology/0.0.1/ontology-0.0.1.jar the wrong classpath was reported for it. The classpath for given jar does not contain the jar itself.
Comment 4 Milos Kleint 2013-03-20 10:18:32 UTC 
(In reply to comment #3)
> Sorry: The exception means that while parsing the file
> org/erasmusmc/ontology/Ontology.class in the root 
> /home/reinout/.m2/repository/org/erasmusmc/ontology/0.0.1/ontology-0.0.1.jar
> the wrong classpath was reported for it. The classpath for given jar does not
> contain the jar itself.

I'm still not entirely clear about the requirements here.

1. the jar in repository is possibly owned by a project. project's CPP doesn't return the resulting jar file on any of the class paths AFAIK and never did. (ClassPathProviderImpl)

2. we don't directly provide CP for artifacts in local repository, but we do for source jars. These however always get the binary on CP. (RepositoryMavenCPProvider)
Comment 5 Tomas Zezula 2013-03-20 10:44:28 UTC 
The requirement is that the ClassPath reported for the root has to contain the root, otherwise the ClassPath is invalid for given root. It's OK to report the Project classpath for file:///Projects/Karel/onlology.jar but it's not OK to report it for jar:file:///Projects/Karel/onlology.jar!/.
Comment 6 Milos Kleint 2013-03-20 12:04:48 UTC 
(In reply to comment #5)
> The requirement is that the ClassPath reported for the root has to contain the
> root, otherwise the ClassPath is invalid for given root. It's OK to report the
> Project classpath for file:///Projects/Karel/onlology.jar but it's not OK to
> report it for jar:file:///Projects/Karel/onlology.jar!/.

hmm.. the global RepositoryMavenCPProvider appears to be always asked about jar:file:///Projects/Karel/onlology.jar!/org/me.java files only. Or about the jar root - jar:file:///Projects/Karel/onlology.jar!/ Never about the actual jar file.
Currently we return CP for both cases, should we change it somehow?
Comment 7 Milos Kleint 2013-07-25 11:32:44 UTC 
actually we only return (in RepositoryMavenCPProvider) classpath for jar:file urls, never for file:/

FileObject archive = FileUtil.getArchiveFile(file);
if (archive != null && archive.getNameExt().endsWith("-sources.jar"))

and we also do so for jars with sources.


source Cp contains just the source jar itself, compile and runtime cp are based on the resolved maven model. but they both always include the binary itself. maybe if it didn't exist we could be in trouble.
Comment 8 Milos Kleint 2014-01-17 11:17:38 UTC 
last reported in 7.3, the code was reviewed and appears to be working correctly, without steps to reproduce, it's hard to evaluate more. closing as worksforme, please reopen with any additional details about the problem.