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.
Dev build. I open https://sezpoz.dev.java.net/svn/sezpoz/trunk/sezpoz and make a Maven Java app with a dep on it: <dependencies> <dependency> <groupId>net.java.sezpoz</groupId> <artifactId>sezpoz</artifactId> <version>1.9-SNAPSHOT</version> </dependency> </dependencies> <repositories> <repository> <id>java.net</id> <name>java.net</name> <url>http://download.java.net/maven/2/</url> </repository> </repositories> I create a class using it: import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import net.java.sezpoz.Indexable; @Indexable @Target(ElementType.TYPE) @Retention(RetentionPolicy.SOURCE) public @interface Stuff {} Now Ctrl-B on @Indexable opens the project source file as expected, and from there Find Usages jumps back to Stuff as expected. Now edit the dependency to be on version 1.8. Download "Declared Dependencies" and "Sources". Now Ctrl-B on @Indexable jumps to an entry in sezpoz-1.8-sources.jar as expected. But Find Usages shows entries in the 1.9-SNAPSHOT source project - technically incorrect - and no entry for Stuff - definitely incorrect. Might be a problem with how the maven module reports ClassPath items for the sources JAR, but I am not quite sure what it is supposed to report. (AFAIK the details of what java.source expects ClassPath to report for non-project inputs are not documented anywhere. Probably not so much of an issue for Ant projects because there is no real structure to Ant libraries anyway, i.e. it could not be made to work properly, whereas for Maven repository JARs we can know everything of interest.)
Hm. I do probably something wrong, but if I change dependency from <version>1.9-SNAPSHOT</version> to <version>1.8-SNAPSHOT</version> I cannot build the project. Download dependencies/sources/javadoc does nothing. No error, no feedback, nothing. Anyway refactoring/find usages works on files, which are defined on source class path of open projects. I guess, that maven projects do not provide correct class path.
(In reply to comment #1) > if I change dependency from > <version>1.9-SNAPSHOT</version> > to > <version>1.8-SNAPSHOT</version> > I cannot build the project. To be expected, unless you happen to have built the lib from 1.8-SNAPSHOT sources. Don't do that. I am talking about 1.8 (release) vs. 1.9-SNAPSHOT.
*-sources.jar is not on any source path. As I mentioned before - FU works only on things on source path.
(In reply to comment #3) > FU works only on things on source path. Then the action must be disabled when invoked on a source file which is not in your source path, or an error dialog must be shown explaining this. Is there no way to find usages of something on the compile classpath of open projects? If so, this is a serious gap. (Ideally I would want to see usages from other parts of the classpath, but at least seeing usages among open projects would be helpful.)
To make things clear. FU works with items defined on compile classpath and search is performed on sources defined on source class path. Back to your report: > Find Usages shows entries in the 1.9-SNAPSHOT source project - technically incorrect Yes. But it is what I would expect to see. > and no entry for Stuff - definitely incorrect. It works for me. But maybe it started to work after restart of the IDE. Can you verify that?
(In reply to comment #5) >> and no entry for Stuff - definitely incorrect. > > It works for me. But maybe it started to work after restart of the IDE. Can you > verify that? Just rechecked and FU on "@interface Indexable" from net/java/sezpoz/Indexable.java in ~/.m2/repository/net/java/sezpoz/sezpoz/1.8/sezpoz-1.8-sources.jar (read-only) shows only hits in "SezPoz Library" and none in the demo project, despite a dep on <version>1.8</version> and after an IDE restart. Checked also in a fresh userdir (opening both source projects as CLI args) in case there was some issue with persistently stale parser caches.
Regarding the missing "Stuff" entry, this is what I think is the problem: -the refactoring first determines what should be FUed: class Indexable that is resolvable from classpath in sezpoz-1.8-sources.jar -then it tries to find the source file for the Indexable class on the compile classpath of the Java file in sezpoz-1.8-sources.jar (filtered through SourceForBinaryQuery). But there is no specific ClassPathProvider for it, so the DefaultCPP returns all binaries. So the first source file that matches Indexable is used, which happens to be in the opened (Maven) project -the FU then correctly finds usages of the incorrect class Best solution, IMO, would be if proper classpaths could be returned for the sezpoz-1.8-sources.jar (including source CP). After this, the result should contain the "Stuff" entry (I tested this by doing FU on Indexable reference in Stuff.java). Another problem is that the result with the above change will likely contain all references to Indexable, even the "technically incorrect" ones. This is because: a) refactoring.java's RetoucheUtils.getClasspathInfoFor:621 uses of all source paths known to the IDE as relevant for non-project sources b) SourceUtils.getDependentRoots cannot currently find roots depending on binary roots (after mapping sezpoz-1.8-sources.jar to sezpoz-1.8.jar) I can try to eliminate these restrictions tomorrow, unless there are objects.
(In reply to comment #7) > Best solution, IMO, would be if proper classpaths could be returned for the > sezpoz-1.8-sources.jar (including source CP). After this, the result should > contain the "Stuff" entry OK, if it would suffice for the maven module to do this then I will try it. So for release deps there would be: demoprj/src/main/java (pom.xml dep on ...:sezpoz:1.8) COMPILE -> sezpoz-1.8.jar etc. sezpoz-1.8.jar (in local repo) SFBQ -> sezpoz-1.8-sources.jar JFBQ -> sezpoz-1.8-javadoc.jar BOOT -> default JDK? (*) SOURCE -> ???? COMPILE -> (any binary deps in repo) EXECUTE -> COMPILE + sezpoz-1.8.jar? sezpoz-1.8-sources.jar (in local repo) SourceLevelQuery -> 1.5 (from sezpoz-1.8.pom in local repo) FileEncodingQuery -> UTF-8 (from POM) BOOT -> default JDK? (*) SOURCE -> sezpoz-1.8-sources.jar COMPILE -> (same as for sezpoz-1.8.jar) EXECUTE -> (same as for sezpoz-1.8.jar) Anything to add/change? Should any of the classpaths from the repo JARs be in GlobalPathRegistry - I guess not? Is there a good place to document what the Java infrastructure expects for all of this? (*) Could check for animal-sniffer-maven-plugin in POM to see what Java platform level is expected, but this will only work in case you use the default config with no annotations, i.e. all code must link against specified JRE without exception. Some projects let parts of the code use newer JRE features but control these parts with runtime checks, so the IDE would have to parse against the newer JRE. There is also a "toolchain" system in Maven which I can look into, but I don't think it is widely used yet. Anyway for uneditable source JARs it is probably enough to parse against default JRE; the source level can be determined accurately I think. > Another problem is that the result with the above change will likely contain > all references to Indexable, even the "technically incorrect" ones. This is > because I probably don't understand this part well enough to comment on it.
Re ClassPath for sezpoz*.jar: -for sezpoz-1.8.jar, no ClassPath is needed AFAIK, but SFBQ and JFBQ should return valid results (sezpoz-1.8-sources.jar and sezpoz-1.8-javadoc.jar, respectivelly). This works OK even now, right? -for sezpoz-1.8-sources.jar, the proposed CPs seem good, except CP.COMPILE, which I would extend with sezpoz-1.8.jar: the sources are not scanned, so no classfiles exist for them and so the built jar on CP.COMPILE should hopefully ensure that the classfiles from the sezpoz-1.8.jar will be used instead of parsing everything from sources. -no registration to GPR needed, AFAIK (would be actually harmfull, I think) Re the second part: with the above changes, the FU on Indexable from sezpoz-1.8-sources.jar will also return usages of Indexable from the sezpoz project, which is not correct. I am attaching patch that: -changes SourceUtils.getDependentRoots to accept also source root corresponding to library sources (accepts only project sources in the current trunk) -changes RetoucheUtils in refactoring.java to: --use SourceUtils.getDR on all source roots that have source CP, not only on project sources --not to use Project.getSources().getSourceGroups(), but rather use the roots from the source CP (not strictly necessary to fix this bug, I guess, but I think this is more correct than use getSourceGroups()) Honza, maybe we can discuss the changes to RetoucheUtils next week? Thanks.
Created attachment 103331 [details] Changes to SourceUtils.getDependentRoots and RetoucheUtils
thanks, Honzo. We can discuss it next week
I have integrated the java/refactoring part: http://hg.netbeans.org/main-silver?cmd=changeset;node=8035024becd1 Should hopefully work OK after #192647 is resolved. Please reopen if it does not. Thanks.
Integrated into 'main-golden', will be available in build *201012030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8035024becd1 User: Jan Lahoda <jlahoda@netbeans.org> Log: #192214: SourceUtils.getDependentRoots should work also for roots from libraries, adjusting refactoring.java's RetoucheUtils to take advantage of this feature.