Created attachment 27828 [details]
IDE log with option -J-Dorg.netbeans.api.java.queries.JavadocForBinaryQuery=0

Works for me on linux with fresh build. Tomasi are you able to reproduce on
Windows? Thanks.

true, it's reproducible for me in "5.1" 2005121319 on WinXP

Reprodicible also for external modules.
In netbeans-5_0-daily-bin-200512061900-6_Dec_2005_1900.zip  works,
in netbeans-5_0-daily-bin-200512072015-7_Dec_2005_2015.zip  does not. Some
change between must have broken it. 

Did you have associated sources and javadoc when trying it with external
modules? Trying it with fresh build would be helpful. There was a P1 fixed
today. Not sure if it can be a culprit.

Aha, it matter *which* sources i associate with platform. I downloaded ~100MB
sources zip file, and it works. But if I associate the same sources, unzipped to
a dir, it does not works. Martine, any change in NBPM which could break this??

Yes, my steps:
1) fresh userdir
2) associate sources in NBPM
3) create module, set dependency to e.g. Filesystems API
4) create new class, type some class and try ALT+O, ALT+G

As i said, it depends on type of sources which i do associate.

When you check out whole NB cvs tree, open an e.g. mentioned NB_CVS/ant module,
you shouldn't need to associate any sources AFAIK.
We can try it together tomorrow Tomasi on your machine.

Jesse feel free to reassign if you don't have any fast ideas.... I'm working on
that leak (70032) - trying to play with GUI vs. assertGC unsuccessfully so far -
but off topic here, I suppose :)

> Martine, any change in NBPM which could break this??

I'm not aware of any.

Working fine for me in a dev build. Try running with

-J-Dorg.netbeans.api.java.queries.SourceForBinaryQuery=0

if you can still reproduce.

Do you have other stuff checked out, like nbbuild and openide and so on?

Sorry, did not see preceding comments for some reason.

If there is still a bug reproducible in current dev builds, please include
complete steps to reproduce from scratch. And specify on which operating systems
you can reproduce, and include a fresh diagnostic log. The preceding comments
leave it ambiguous what exactly you are talking about and who can reproduce what.

1) using build 5.0 200512132030, on Windows XP, with installation
2) downloaded zip file sources to this build
3) unpacking zip to some folder.
4) clear userdir
5) starting ide, setting sources association in NBPM
6) creating new standalone module, setting it's dependency to e.g. Filesytems api
7) creating new class in that module, typing e.g. "FileObject x;"
8) invoking ALT+G and ALT+O -> does not work

note that if i associate not folder with sources, but zip, it works.

> musilt2 Wed Dec 14 16:20:41

This is rather another issue (not P2 I think). Original reporter complained
about modules in NB cvs tree regression. Should be filed separatelly (assigned
to me), since I'm not sure if anybody checked this before at all.

>This is rather another issue (not P2 I think). Original reporter complained
>about modules in NB cvs tree regression. Should be filed separatelly (assigned
>to me), since I'm not sure if anybody checked this before at all.

nope. this is only another testcase, which reproduces *the same bug*. I am able
to reproduce also the original testcase.


I'll attach log produced after my "steps to reproduce"

Created attachment 27853 [details]
Log file after my testcase

Working fine for me using last instructions from musilt2, on Linux with JDK
5.0u6. Downloaded

netbeans-5_0-daily-bin-200512132030-13_Dec_2005_2030.zip
netbeans-5_0-daily-src-200512132030-ide_sources-13_Dec_2005_2030.zip

Unpacked them so that we have e.g.

-rw-r--r--  1 jglick jglick 422650 Dec 13 22:46
/tmp/70387/netbeans-200512132030/platform6/core/org-openide-filesystems.jar
-rw-r--r--  1 jglick jglick    615 Dec 13 16:17
/tmp/70387/netbeans-src-200512132030/openide/fs/build.xml

Started IDE:

cd /tmp/70387
./netbeans-200512132030/bin/netbeans --userdir testud
-J-Dorg.netbeans.api.java.queries.SourceForBinaryQuery=0
-J-Dorg.netbeans.modules.apisupport.project=0

In NB Plat Mgr, set Sources for Default Platform to
/tmp/70387/netbeans-src-200512132030.

Made new module /tmp/70387/module1, added FS API as a dep, created

import org.openide.filesystems.FileObject;
public class X {
    public X() {
        FileObject x;
    }
}

and code completion and Go To Source both work fine on FileObject.

Perhaps you accidentally configured the source association with the directory
containing netbeans-src, rather than the directory netbeans-src itself? Just a
guess.

Created attachment 27856 [details]
My log file, for purposes of comparison

I just added some diagnostics (-J-Dorg.netbeans.modules.apisupport.project=0)
which would be helpful if this can be reproduced in a future dev build:

committed     Up-To-Date  1.28       
apisupport/project/src/org/netbeans/modules/apisupport/project/universe/NbPlatform.java

As both guys Tomas and Jirka mentioned this problem appears on Win XP. OS of
this issue is set as Win XP. Jesse and Martine why don't you try to reproduce
this issue on reported platform instead of resolving as worksforme? It is
obviously problem of just Windows, not Linux. I am reopening this issue because
it is easily reproducible on Win XP. I hope my comment helps to clarify.

Due to misuse of file separators in patch to SourceForBinaryImpl for issue #69735.

Patch checked that the target JAR file actually had the same suffix including
cluster as the expected one, e.g.

platform6/modules/org-netbeans-modules-whatever.jar

It used PropertyUtils.relativizeFile which always produced a '/'-separated path.
This works on Unix but not Windows.

Have not tested fix. Would have to waste several more hours getting a usable
development environment on my Windows partition. Hopefully someone else would be
able to test quickly. Ought to be able to change

clusterPath = PropertyUtils.relativizeFile(cluster.getParentFile(),
project.getModuleJarLocation());

to

clusterPath = PropertyUtils.relativizeFile(cluster.getParentFile(),
project.getModuleJarLocation()).replace('/', File.separatorChar);

Than it would be strange if all of our SourceForBinaryImplTest pass. Maybe that
just nobody runs them on Windows since that fix. Probably
testFindSourceRootForModuleJar() and testExternalModules() should fail. I'm also
unable to test it right now. To be sure, I'll check it in cca 6 hours with Radek
or Tomas, depending on who will be in the office :)
Thanks to all for investigation.

I tested patch by Jesse in build 200512142030 (release50) and it works
perfectly. I suggest to merge it into release50 branch because it is a big
usability issue and fix is really simple.

Ok, thanks for your help Jirko. I'll integrate it soon (also into release50 branch)

Patch applied.

Checking in queries/SourceForBinaryImpl.java; 1.4 -> 1.5;

*** Issue 70449 has been marked as a duplicate of this issue. ***

Jesse could you review your patch for release50? :)

http://apisupport.netbeans.org/servlets/ReadMsg?list=cvs&msgNo=2990

Forgot to CC reviewer...

Sure, consider it reviewed. :-)

Do you know anything about the unit test status? I tried to look at what
SFBITest was doing but I didn't see anything that would test this specifically.

You can simulate Windows behaviour on linux with s/File.separator/\\/ in your
patch, I believe (OS negation).
Also we tried it here with Tomas on Windows and those two test failed before the
patch was applied. After fix it works.
There should be somebody who runs tests on Windows from time to time I think ;)
I'll commit into release50 tomorrow.

Backported into release50 (the same diff)

verified in 5.0 && trunk