Created attachment 21491 [details]
two projects

Procedure: 

1) extract the zip file
2) open NB, and open the two projects inside cross-test
3) build the librsys library.
4) open shell project, go into TrapInfo class
5) do a "Fix Import", and see that it does not work.
    => BUG 1
6) restart NB, go into TrapInfo class, do a "Fix Import" and now it works.
7) move cursor on "Signal" class, do a "Go To Source" and it does not work.
    => BUG 2
8) Go to Signal Class, do a "Find Usages" and it does not work.
    => BUG 3

(hmm, actually, it seem totally broken this time. more after lunch)

8) Go to Signal Class, do a "Find Usages" and it does not work.
    => BUG 3

It looks like, that (from API point of view) P1 (library project) is not
Subproject of P2(main program). This is reason why Find Usages does not show
occurences f Signal in P2 project.

Editor guys, can you evaluate. Why Go To Class does not work?

I think it is a problem with "project linking". The librsys project doesn't know
about project shell. 
The shell project is connected to the library by its jar file. The jar can
belong to any project or not. The IDE doesn't know where are the sources of the
jar file. You can connect the library's sources by adding librsys/src to Java
Sources Classpath in shell project properties. 
But if you try to Find usages of Signal you still cannot get usages in shell
project because librsys doesn't know about the project.
I think that the best way is to create nb projects for them. If you need don't
have sources in the project folder you can add 'src' folder by nb project
properties - node Sources, Add Folder action.

This certainly look like a a problem with "project linking".

> The jar can belong to any project or not.
> The IDE doesn't know where are the sources of the jar file.

This is incorrect.
The jar is declared in librsys->Project->Output, so NB knows
where the sources are. (this is the whole point of Output
properties)

> But if you try to Find usages of Signal you still cannot get
> usages in shell project because librsys doesn't know about
> the project.

NB knows that "shell" uses "librsys", so it has all the info
it needs to track librsys usages.

The bug is in SourceForBinaryQuery
url = "jar:file:/D:/temp/aaa/cross-test/dist/lib/librsys.jar!/"
SourceForBinaryQuery.findSourceRoots (url).getRoots() returned empty array
but should return source root of librsys project.

Reassigning to freeform. Please reassign if I'm wrong.

Seems strange, the SFBQ works fine in freeform. I am going to look at it under
debugger.

I had a breakpoint at FilterClassPathImplementation:115

Attached projects are a litle bit strange, they have source roots under src/java
(not directly under src). But I don't know if it does matter. librsys.jar is
built outside project structure.

The project has unsupported layout.
The outpt of project must be under the project folder.
Your layout is:
cross-test
  libsys     <-- project
  shell      <-- project

But the output of the libsys project is put into
cross-test/dist/lib/librsys.jar
This is not under the project folder, so the project
system is not able to find out the project.
You should change the layout of the project to build
the output under the project folder.
In your case:
cross-test
  libsys     <-- project
    dist
       librsys.jar

  shell      <-- project
    dist

Yes, 
 
  "the output is outside the project."

But I don't see any technical reason why

  "the project system is not able to find out the project."

The problem is that if I do not put the resulting
jars of ALL project in the same directory, then
JAR Class-Path does not work.

Created attachment 21534 [details]
new shell project.cxl

Ok. if "FreeForm" project are really Free Form, then I think the
author should have the freedom to put its jars wherever it whishes,
so I still think it's a bug, and I don't think it's hard to fix
anyway.

Nevertheless, I've changed my project, and this time shell does not
point to the librsys project through the JAR file, but directly by
pointing to librsys source directory. (see attachment above)

Now, "GoTo Sources" works better.

BUT: "Find Usages" and "Refactoring" are still Broken.

Also, there has been independent reports of the same problem
with "Find Usages" and "Refactoring" on netcat mailing lists,
and I doubt these PPL had "strange layout" too.

I'm therefore reopening this bug.

PS: I hate it when I spend time report a bug, make a test case,
and then see the bug closed without giving the reported a chance
to comment.

The reason is that after clean the dist folder does not exist. It cannot be
registered as external reference, There is already an issue for API change to
allow register extenral references to nonexisting folders.

> The reason is that after clean the dist folder does not exist. 

Ok. This I can understand. But IMHO this has nothing to do with
the fact that dist is outside the project, there would be the
same problem if I put my jar in shell/dist/shell.jar (inside
project) and clean remove shell/dist.

I can change my project to make sure that dist folder always
exists, no problem.

But that explains only "bug 1", not all the other problems...

The freeform project has some known limitations given by the underlaying APIs.

The output should not point to the sources but the jar file or build folder, eg.
(build/classes/src in your case)
If you change it in this way it should work. I will attach the changed project
file. But I've got to the same problems as you describe (code completion works
fine, go to source works fine, error marking works fine but the refactoring does
not). This seems a problem in the java/javacore module.

BTW: Even when the issue is closed, the owner and people on the cc list see your
comments.

Created attachment 21537 [details]
Lybrsys project file

Created attachment 21538 [details]
shell project file

Ok, thanks, I will review your two files.

About refactoring, I think I've some info: I was able to make it
work by manually editing shell/nbproject/project.xml and adding
the following

            <subprojects>
                <project>../librsys</project>
            </subprojects>

At the end of the general-data section.
I've no idea how to set that from within IDE, or why it's not setup
manually.

The project layout is WANTFIX as I've described above. It is given by the API
limitation. But after the project is changed to fulfil these limits the find
usages does not work either. The code completion, error marking, goto source
works. The find usages should work too. It is some bug in javacore or refactoring.

Sorry but I don't know much about refactoring module, I've redirected this issue
back to this module. People from refactoring should explain you what does the
<subprojects> mean. But I doubt that there is a way how to set it from the
customizer. There are big areas of freeform customization which cannot be done
from the customizer and has to be done in the xml file (eg. properties).

Ok for the refactoring stuff.

A little off-topic but:

About your two files, I of course cannot use them unmodified
because there is absolute URLs in there, and my windows box doesn
not have a /tmp/00/ folder :)

I always find myself fixing theses reference by hands because
NB customizer always wants to put absolute pathnames in the
xml configuration file, and I think that is totally retarded,
because resulting files cannot be used by multiple ppl.

Do you know if there is already a bug for that, or should I enter
a new one?

Sorry for the absolute paths.
Yes, there is already a issue for this. User can define properties using
<properties> element in the project.xml file and use these properties in the
path definition, but not yet in the UI. The issue addressing the UI editing is
http://www.netbeans.org/issues/show_bug.cgi?id=53390.

If the refactoring works fine, can you close this issue?

The refactoring needs the <subprojects> section to be able to build the project
dependency tree. Currently there is no UI for defining it, I've filled new
enhancement for it: http://www.netbeans.org/issues/show_bug.cgi?id=57733. The
rest of the issue is wantfix - the project layout. The issue with using relative
(property based paths is filled).

Ok, Thanks!

See my comments in issue #57733; I think comments here were incorrect.

Also, is <build-folder> generated by the GUI yet? If not, should it be?

About <build folder>:

I've no idea what that is for, and apparently it is not used.

Is this file format documented somewhere?
This is all very confusing to me.

I created issue 57757 requesting project.xml file format documentation.

I believe the <subprojects> bit is somewhat of a workaround.  If the subprojects
are open in the IDE, then the IDE should note the correspondence between output
of some projects and dependencies of the others -- and examine multiple
projects' data accordingly.

I will agree, however, that <subprojects> is the only reasonable means for
downstream products to be noticed when they're not all already open in the IDE.

Also, not everyone can place their output jars inside their project -- in
particular for free-form projects!  Shouldn't one at least be able to explicitly
tell the project about the sources -- or just the projects it depends on wherein
it can find the sources?  I wouldn't mind reminding the IDE so much, but
currently there is no way for Go-To-Source to work with multiple "real world"
free-form projects!

The whole reason for a free-form project is to work with existing Ant scripts
which may well put their output *anywhere* and get their dependencies from
*anywhere*.  Given that the project does denote *where* the output is going, I
do not believe it is acceptable to say "you must put output jars in the project
directory" when all the necessary information as to where the library resides
has been provided!

P.S.  Having a <dependsonprojects> bit in project.xml would at least provide a
workaround to the go-to-sources issue.  By <dependsonprojects>, I mean an
ability to declare *projects* the free-form project depends upon wherein
go-to-source, etc, can know to look.

Right now you lose way too much functionality if you cannot follow all of
NetBeans' rules (which are quite arbitrary from a user perspective).

I guess there is *a* way to make go-to-source work -- but it seems weird.

By placing the base project's output jar and sources in the library manager,
"go-to-source" suddenly works from the other projects!

This is not a workable workaround when one has many projects.  It does, however,
prove that it is quite possible for "go-to-source" to work just fine with
projects whose output resides outside their own directory -- *at least* when the
project in question is open in the IDE (which is the only case I really expected
to work).

The first part regarding finding usages and <subprojects> tag is covered by
issue 57747.
The second part (go to source) seems to be a request for enhancement of freeform
project. Reassigning.

I suppose one might term a working multi-project "go-to-source" behavior an
enhancment :-)

I'd term the lack of one (when one's output jar does not happen to reside within
a project's directory) a bug, though.

Also, does this extend beyond freeform projects?  One can edit a standard
project's properties to send the output jar outside the project's directory
structure...

Hmmm...  The <subprojects> workaround to the refactoring issue does not seem to
be working for me.

Is this *also* broken by having my project output outside the project directory?

P.S.  If reasonable multi-project "go-to-source" behavior is not currently
possible due to a lower-level API restriction (as some previous comments seem to
imply), then that does not mean this is not a bug.  Rather it means this bug
remains open (with cause) until a lower-level API improvement is made.

Seems that projects are not able to identify the project associated with the
output if the output is not in the project directory. That's just my guess. If
the SourceForBinaryQuery would work correctly, then go to source should work as
this and the GlobalPathRegistry is the only thing it relies on AFAIK. I'll leave
this up to project experts to evaluate.

Scratch the "subprojects don't work" comment.  I messed up a detail.

I mean classpath for a given file and source for binary query (not global path
registry) - sorry...

I'll use the Library Manager workaround to the Go-To-Source issue for now, but I
believe this issue ought to be fixed in a 4.1 auto-update -- not wait for 4.2!

Given that jglick claims in issue 57747 that having output out of the project
directory should work as long as you have the project open, the thing with the
go-to-source really looks like a defect. It seems that the SourceForBinaryQuery
does not work unless you define a library. ENHANCEMENT->DEFECT (P2 since there
is a workaround)

I must have missed a lot of background here, since the thread in this issue is
too long and rambling to really follow what the bug is. At a minimum the issue
summary line must be cleaned up to succintly describe what, if anything, is
wrong. Jan, as you are the owner of this issue, you need to clean it up -
figuring out which issues are reproducible, analyzing causes, possibly filing
separate issue reports for separate items, and adjusting issue priorities to
reflect existence of workarounds etc.

1. <build-folder> is used in the project.xml of freeform projects to declare
external build output directories and register them in FileOwnerQuery. If the
GUI does not produce this element, there is a bug in the GUI project.xml writing
code. This is one possible bug.

2. Externally owned locations (such as from <build-folder>) are currently
register when a project is loaded, but this probably should be changed to be
registered when the project is opened, already filed elsewhere. If there is a
need for external locations to be registered semipermanently, without needing to
first open the subproject, then we may introduce a new algorithm to
FileOwnerQuery, as is also already filed elsewhere.

3. <subprojects> has one and only one meaning - it determines behavior of
SubprojectProvider. This API in turn has only one meaning - it determines what
the "Required Projects" should be that are used in the GUI in (a) the Open
Project dialog, (b) the Open Required Projects context menu item on project root
nodes in the Projects tab. It may not be used for any other purpose.

Re. mmatula's comments:

"Seems that projects are not able to identify the project associated with the
output if the output is not in the project directory." - this is not true. See
API of FileOwnerQuery.

"It seems that the SourceForBinaryQuery does not work unless you define a
library." - this is also not true. If the binary is owned by a project, the
project should associate sources with it.

I think it would be good to keep that bug open until the project layout
given in the first attachment:
http://www.netbeans.org/nonav/issues/showattachment.cgi/21491/cross-test.zip
can be made to work out-of-the-box.

BTW: I still have no idea what <build-folder> is supposed to mean.
for example, in the attached project, the classes are build in a
folder (A) but the final jar-file is built in a totally unrelated folder (B).
what should build-folder point to? where classes are compiled, or where the 
final jar is put? there can be N "build-folder" in a free-form project.

For me, I don't understand the concept of a build folder at all. All that
NB should need to know is the location of the final classes, in my case
the jarfile. whether the jar is build on earth or in the moon shouldn't
matter for debugging.

Re. cberger's last comments: agreed with first paragraph; up to Jan to evaluate
it detail.

Re. <build-folder>: if you don't understand what it means, that's because (a) it
isn't documented yet (my issue #57757), (b) it may not be being correctly
generated by the GUI yet (cf. my previous comment) - most users should not need
to know about it, assuming they are using the GUI to configure the project.
<build-folder> is used to indicate to the IDE that an externally located
directory is somehow "owned" by the project, as per FileOwnerQuery (this is
*not* the same as <built-to>), meaning that other IDE components looking for the
owner of a JAR etc. can find it - such as ProjectSourceForBinaryQuery in
java/project (which also will use <built-to> for the details).

Another note: currently FileOwnerQuery only permits registration of external
*directories*, not individual files within a directory. If this needs to be
changed, that is fine but it should be filed as a separate issue (projects/code
- not freeform-specific) and go thru apireviews as usual. May be beneficial for
the following reasons: (1) may make freeform project.xml writing code simpler;
(2) would permit use cases where several projects all build JARs to a single
dir; (3) may be helpful for apisupport/project, to permit the IDE to associate
each individual module build product in ${netbeans.dest.dir} with the
appropriate project.

About your point (2) above: my project posted in the first attachment
does indead put all output jar files in the same output directory (to
make jar class-path mechanism work during debug), so this has to be
solved for that stuff to work.

Now, some general comments: I see _four_ mechanisms used by NB
to express relationship between projects:

1) libraries set the "Output" jar/classpath for each source dir
   (Project Properties->Output) and project that uses these
   libraries have specify in  "Source Classpath" which jar they use
   (Project Properties->Java Source Classpath).
   This info is stored in <compilation-unit> in project.xml.

2) through the undocumented (and flawed because of shared dir)
   <build-folder> mechanism.

3) through the <subprojects> mechanism.

4) oh, I just saw a <export> tag in my library's project.xml, is
   that a fourth redundant way to express the same thing?

The issue is that some part of netbeans use one mechanism, and
some other part use another mechanism. Refactoring use 3), while
apparently goto-source use 1). Don't know who uses 2) and 4)

Having redundant way of saying the same thing in a config file is
bound to bring trouble, because sooner or later things gets out of
sync and the users are totally puzzled when only half of the features
works. This is a design bug IMHO.

So I would suggest that NB folks look at that project.xml file,
and remove everything in it that is redundant and can be deduced
automatically. Since there is already a GUI to setup the 
<compilation-unit> stuff, then I think that only that info should
be kept in the file, and 2), 3) and 4) should be killed because
they bring no additional information when 1) is setup correctly. 
And will less stuff, it will be easier to document :)

As a final note, I think mechanism 1) should work even if the given
jarfile or enclosing directory tree has not yet been built: just
canonicalize the file (resolving /../ and /./) and treat the result
has an identifier (URI) to find project's relationships.

Yes, I will evaluate this issue, I only did not manage to get through the
comments yet, sorry.

In my opinion the issues is about missing API to register non existing external
file/folder in the SourceForBinaryQuery, which is already filled issue.

Well, to provide a summary of issues discussed here:
1. Go To Source (and other features) does not work when the output jar is
outside of the project's directory.
2. Refactoring uses subprojects to find out dependencies between projects -
issue #57747 (see also #57733).
3. Absolute paths generated by the customizer - issue #53390
4. project.xml format documentation - issue #57757

So, it seems to me that this bug should cover only the first point (others are
described in another issues).

Please, if I have missed something, file a new issue to cover the missing part.

I agree that the freeform project should be able to handle situations where the
output jar is outside the project's directory, but currently the API does not
allow it. I have filled a new issue #58313 for the API change (please duplicate
it if you find the original issue with this request).

I agree with your synopsis, jlahoda.

Well, I don't know that the "API does not allow it".  I've not tried to fix the
bug myself :-)

I do know that creating a library for the base jar and mapping the base
project's source to it fixes the issue -- and thus it seems to me getting a
project itself to behave similarly should be quite doable.

I have a prototype implementation that works with the cberger's projects
out-of-the-box. Moving to ant/freeform, as the freeform project's part should be
solved there.

First, <built-to> *does* work whether the target file exists or not; not sure
what this is about but if you know of a problem, please file it separately, no
need to mention it again in this issue.

Re. redundancy in project.xml - there are *partial* redundancies in project.xml
but no elements that are completely and reliably derivable from anything else.
Rather than make the interpretation of project.xml too magical - i.e. guessing
how to interpret a given XML element in different contexts, thus overloading its
meaning - we decided to make the format quite concrete, directly mapping to what
other parts of the IDE really need to know, and putting the guesswork into the
GUI project.xml writing code. This leaves the user with the option of overriding
bad guesses. For example, <export> controls what another project (such as a
j2seproject) will see as the "build outputs" from this freeform project -
typically one JAR, but could be more or less. The GUI guesses that you want one
<export> per declared output JAR and that the Ant target bound to "build" is the
right target to create it. This is a good guess most of the time, but you might
need to override it for various reasons (without affecting any other semantics
of the project); if so, you can just edit project.xml to state what you mean.
And yes, I still know that the project.xml format is undocumented.

Created attachment 22332 [details]
Prototype fix.

I have attached prototype fix for this issue, see Jesse's comments to this patch
in issue #58313.

Sorry, but the fix seems to be quite complex and dangerous (changing the
freeform's schema, as written in issue #58313), and also this is probably not a
very common scenario, so I do not think this should go to 5.0.

The workaround should be to create a library binding the jar file(s) and the
project sources.

I agree that creating a library is a workaround.

I must disagree that this is so rare, though -- this affects most of the
freeform projects I have.  The intent of freeform projects is to use existing
Ant scripts after all -- and thus not to dictate the layout of the project.

It would be helpful if the full impact of creating a library (i.e. the fact that
you're creating a mapping between various jars, sources, and Javadoc that is
used by all facets of the IDE) were a little clearer up front.  I've had to
create separate training material surrounding NetBeans mostly for other reasons,
but I had to give special mention to the full impact of the library manager --
and even so users seem to miss this initially.

Is this *still* not fixed in NetBeans 5.5?

I am on nearing rollout of an automated free-form project creation script to a
development organization.

The existing Ant scripts *all* build their results to a common directory outside
of *all* of the projects' directory trees (it couldn't very well be commmon
otherwise...).  This allows all projects to easily use one outputs from other
projects without knowing the other project's locations or even loading their
source trees (the source trees in question are massive).

Thus there are *very* good reasons for the projects' output to reside outside
the projects' folders that will not be changing.  Given that there will be
dozens upon dozens of projects, creating a library for each one is ludicrous. 
Worse, I've managed to make the projects themselves use relative paths for
everything so that developers across platforms can share the same projects "as
is".  I cannot do this for libraries since these involve global file paths.

This is a *major* blocker for us that will cripple what would otherwise be a
very compelling NetBeans story here.  [We have an ardent Eclipse user base as
well and as a company are IDE agnostic, but NetBeans free-form projects have
been a real win in terms of integrating well and properly with our complex Ant
build system.]

We need a fix ASAP in NetBeans 5.5.  Having all open projects (at least
free-form projects) treated as libraries is conceptually quite simple -- they
contain all the right information very clearly laid out in their project.xml. 
I'd try to fix this myself in NetBeans' code, but I have *no* familiarity with
the internals and no time for this.

I would be quite willing to test a patch against NetBeans 5.5...

Did someone just forget to mark this as fixed?  In some quick testing I am not
seeing the problem in 5.5.  I'll do more testing...

See

http://qa.netbeans.org/bugzilla/bug_priority_guidelines.html

for bug priorities. It is unlikely this is a P1. Note that NB 5.5 has already
been released. I do not know if there is an update planned or if so what
criteria there are for fixes in it.

The history of this issue is too long to have a clear picture of what exactly
the problem is. A *minimal*, self-contained test case is needed together with
explanation: what you want to accomplish; what concrete steps should be taken in
a freshly installed NB build to follow the test case; what you expect to see
happen; what you do see happen, in NB 5.5. Will also need a description of what
happens in a current NB 6.0 dev build (a nightly build, *not* M4), since the
Java and refactoring infrastructure has been rewritten since 5.5 and may well
behave differently.

Okay P1 may be overstating things, but it will be a definite P2 for our usage.

I understand NetBeans 5.5 has released, but that should not rule out fixing bugs
in it!  [Not all of us can afford to tread the bleeding edge by using NB6 -- I
certainly can't suggest that as the solution for our entire development
organization!]

The problem here is quite simple:
  1) Create free-form project A in directory /somePath/A that outputs
     to /someOtherPath/lib/A.jar (and denotes this properly in project.xml).
  2) Create some other project B that uses A.jar in its classpath
     (and again properly denotes this in project.xml).
  3) Use a class from A.jar in a source file in B.
  4) Try to do the following (with both projects open)
      a) Ctrl-click on this usage in B to navigate to the source file in A.
      b) Right-mouse "Find Usages" on the class in A.
      c) Try to refactor (e.g. rename) the class in A.

In the past, 4a failed to find the source file and 4b and 4c failed to find the
usage(s) of A's class in B.  This was quite galling in that all the necessary
information is clearly present in the projects' project.xml files.

I'll do more testing in NetBeans 5.5 as 4a and 4b actually seemed to work for me
in a quick test.  If they continue to do so (and 4c does as well), then this bug
should simply be closed outright if 4a-c work when the other project is closed
and greatly reduced in priority and scope if these work but only when both
projects are open.

After further testing with NetBeans 5.5 it is clear that 4a-c fail in many, but
not all cases!

This is a serious mess.

I'll try to find time to isolate a small test case, but I may not find such time
for a while.

The usecase described by jessholle seems to reproduce the problem. I'm attaching two simple freeform projects for
reproducing the problem. It's probably reproducible only when projects were created, in such case delete nbproject
folder and create freeform projects from scratch.

Created attachment 44254 [details]
projects to reproduce the problem

This does continue to plague me in NetBeans 5.5.

I have an automated script to create a whole slew of free-form projects and the script automatically creates a slew of
libraries.  I've seen cases where code scanning of some form causes exorbitant memory usage, so I've toned back the
completeness of these libraries -- with the side-effect that I often have this issue even with the libraries.

I've not spent much time/effort on NB 6 since it seems somewhat doubtful this has been addressed there and NB 6 M9 gives
a host of errors about free-form project project.xml's that are non-sensical (trying to correct them results in invalid
project.xml as far as both 5.5 and 6 are concerned) -- though the projects still work.  Also it marks most of my
projects with a big red "X" since we have non-Java sources in our projects that produce class files used by other
sources in our projects -- thereby causing NB 6 to red X most everything.  [NB 5.5 red-lined the source lines in
question at first and then corrected itself later.]

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

It seems that the problem might be on refactoring side somewhere. I've debugged the freeform code I found that
classpaths are updated correctly after project.xml changed, events are fired and
GlobaPathRegistry.getDefault().getPaths() returns paths correctly.

Checking in org/netbeans/modules/java/source/usages/RepositoryUpdater.java;
/cvs/java/source/src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java,v  <--  RepositoryUpdater.java
new revision: 1.71; previous revision: 1.70
done

Is it believed that this fix completely addresses the problem?

Which versions does the fix address?  5.5?  5.5.1?  6.0?

Given that 6.0 is still some time off (and current milestones have other issues), I'd really like to see this fixed in
5.5 and/or 5.5.1!

Is it believed that this fix completely addresses the problem?

Which versions does the fix address?  5.5?  5.5.1?  6.0?

Given that 6.0 is still some time off (and current milestones have other issues), I'd really like to see this fixed in
5.5 and/or 5.5.1, i.e. via a hot fix from the update center.

The fix for 5,x is nearly impossible or too expensive. The fix consist of several other fixes, which were already
resolved in the NB 6.0. The today's commit was the last problem solved - refactoring doesn't work when you add new
freeform to classpath.

As the original submitter: thanks for fixing that issue!
I guess I'll be motivated in participating for another NetCat program now :)

As noted in issue #115872, this issue appears not to be fixed in NetBeans 6 beta 1.  While "go-to-type" works fine,
contextual "go-to-declaration" in the editor utterly fails between such projects.

I'm reopening this bug -- especially since thanks to issue #115872 the workaround to this bug, extraneous libraries to
map from various projects' sources to their output jars, breaks most all code completion and navigation functionalities!

To be clear the combination issue #57656 and issue #115872 make NetBeans 6 useless to me until one -- or hopefully both
-- of these issues are addressed.

Sorry, but issue #115872/#115654 can (IMO) clutter any fix that was done in this issue. So please verify fix for this
issue on a build that contains fix for issue #115654, and reopen only if you are able to reproduce there. Thanks.

This issue is clearly still present in the 9/20/2007 daily build, so I'm reopening this.

Note that issue #115872 and issue #115654 both seem to be fixed in the 9/20/2007 daily build.

Th problems seems to be in building the otput outside the project dir, in my test case when the output is under project
dir it works fine.

Exactly.  This has always been the case.

All of my free-form projects *must* build to a jar in a centralized location, which is where all the other projects use
these jars from.  This is how our build system works.  NetBeans 6 clearly *still* has issues with this for some reason
(though I don't see why it should matter whether the jar is under the project directory tree or not) and thus this bug
should remain open.

I'm still having hard time to reproduce the issue. I will describe my setup and attach those projects, please review it
and let me know where is the difference from your setup:

- I have two freeform projects - freeformA and freeformB.
- freeformA has no dependency and it builds its jar file outside of the project dir, e.g. e:/work/output/freeformA.jar
- freeformA has set e:/work/output/freeformA.jar as its output in Project Properties
- freeformB has dependency on freeformA classes
- freeformB has set e:/work/output/freeformA.jar as its classpath in Project Properties
- freeformB builds its jar to e:/work/output/freeformB.jar (which is not relevant in this case)

When I open class freeform.b.ClassB from freeformB project and try Ctrl+B and Ctrl+Shift+B on ClassAB, both actions work
and open correct class freeform.a.ClassAB from freeformA project.

Please try do describe your problem from scratch, because this issue has really long history and is mixing couple of
related problems and it's hard to get what actually doesn't work. Thanks.

Created attachment 49659 [details]
projects to reproduce issue

I've attached two freeform projects. You need to set property {projectfile} in both build.xml and also correct
{compile.cp} classpath in freeformB project.

I'm on vacation this (whole) week, so I've not had too much time to respond (ironic isn't it).

On issue #116321 I had suggested a modified module with lots of log output rather than chasing reproduction cases
forever.  Perhaps that makes more sense here as well.

Well, some blind logging can be added, but you stated that the problem is reproducible for you, so I assume there must
be something essential in the project setup that makes this issue show up. Please try those projects I've attached if
you can reproduce the problem with them (after the modification) and then try to find what is difference between those
projects and your freeform projects. Thanks.

I'm seeing issues like this as well.  I just downloaded:
Product Version: NetBeans IDE Dev (Build 200709270000) Java: 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-87 System:
Mac OS X version 10.4.10 running on ppc; MacRoman; en_US (nb) Userdir: /Users/br136278/.netbeans/dev
Which is working a bit better than beta 1 was.

Here is an interesting point.  Navigate -> Go to Source fails to navigate to a source file in another project.  The Go
To Type dialog succeeds.  I will try to look at the attachment.

I will remind all on CC that while there is no substitute for a clear, minimal, self-contained test case to reproduce a
given problem (see http://www.catb.org/~esr/faqs/smart-questions.html#asking for example), the module "NetBeans Project
Metadata Inspector" can be used to take a textual snapshot of pretty much all interesting configuration relating to an
open project; you can then compare the output from a problematic project with that from a functional project, to see
what is missing or corrupt. The module is available on devel update centers, or as a direct download from

http://deadlock.netbeans.org/hudson/job/javadoc-nbms/lastSuccessfulBuild/artifact/nbbuild/nbms/extra/org-netbeans-modules-apisupport-projectinspector.nbm

Excellent module, is that URL suitable for posting on the Wiki Freeform FAQ page?

Here is the output for one project.  The Source and JavaDoc paths show up for the project's generated classes in the
classpath/compile entry.  Some other projects, currently open in the IDE, and identified in the classpath/compile: entry
don't list Source and JavaDoc entries tied to the class output directory.  Should the Source and JavaDoc entries be
known by the IDE if the project is opened?  If it is a Freeform project as well what entries in the project.xml file
create this linkage, <java-data xmlns="http://www.netbeans.org/ns/freeform-project-java/2"><compilation-unit> or 
<general-data xmlns="http://www.netbeans.org/ns/freeform-project/1"><export> or
<general-data xmlns="http://www.netbeans.org/ns/freeform-project/2"><export>?

Java source roots:
  "source" (${project.source.dir}): /Users/br136278/Documents/workspace/camplugin/cbem/src/java/bol-impl-iscsi/pkgsrc
    source level: 1.5
    encoding: MacRoman
    binaries: /Users/br136278/Documents/workspace/camplugin/cbem/results-menotti/bol-impl-iscsi/classes
    test roots: /Users/br136278/Documents/workspace/camplugin/cbem/src/java/bol-impl-iscsi/junit
    classpath/source: /Users/br136278/Documents/workspace/camplugin/cbem/src/java/bol-impl-iscsi/pkgsrc
    classpath/compile:
      /Users/br136278/Documents/workspace/camplugin/cbem/results-menotti/bol-impl-iscsi/classes
        sources: /Users/br136278/Documents/workspace/camplugin/cbem/src/java/bol-impl-iscsi/pkgsrc
        Javadoc: file:/Users/br136278/Documents/workspace/camplugin/cbem/results-menotti/bol-impl-iscsi/javadoc/
      /Users/br136278/Documents/workspace/camplugin/cbem/results-menotti/bol/classes
      /Users/br136278/Documents/workspace/camplugin/cbem/results-menotti/bol-impl-common/classes

For Libraries I assume the Library Manager provides the Source and JavaDoc linkages.  

Now if an opened freeform project doesn't provide the IDE with enough context to produce Source and JavaDoc references I
assume you could create a Library reference for that Freeform project, correct?  

Does the IDE Source and Javadoc completion behave differently whether other projects have been opened in the IDE?
     

Good point about FAQs; I created http://wiki.netbeans.org/wiki/view/FaqFreeformDiagnostics therefore.

<java-data> is used for associating sources and output binaries of a project. <export> is only relevant if you want to
make the freeform project a subproject of a standard project - then it specifies what Ant target(s) to run to create
outputs in a subbuild.

cbem/results-menotti/bol/classes (and another one) are missing sources, which is certainly a problem. Perhaps your
freeform projects are missing <built-to> sections in <java-data> (Output section in the Properties dialog). Without
that, many critical IDE functions cannot work.

Library Manager can be used to provide source associations for bare JARs without projects. (Should not be used for
project sources.) The existence of such a library with a matching JAR path is enough - the freeform project cannot refer
to the library as such anyway, only the JAR path.

AFAIK code completion should be insensitive to the list of open projects. (Unlike e.g. Go to Type and Find Usages, which
need some sort of scope to search in.)

<RANT>
OK, I've downloaded/Installed NB 6 beta 
   -> Cross-project refactoring, go to source, bla  bla don't work.

OK, So I see I install org-netbeans-modules-apisupport-projectinspector.nbm. 
  -> Result: it generated 3 pages of garbage, starting with:
      Project: "jtkhtml" (jtkhtml)  
      Location: /Users/cedric/Work/svn-www/head/jtkhtml
      Implementation class: org.netbeans.modules.ant.freeform.FreeformProject
      Raw lookup contents:
        org.netbeans.modules.java.freeform.LookupMergerImpl$ClassPathProviderImpl@889869
        org.netbeans.modules.ant.freeform.LookupMergerImpl$ActionProviderImpl@ce3070   
  --> So, am I really supposed to parse/understand that mess?
OK, So I said to myself, I'm sure I've something wrong in my freeform project. So I go to
   NetBeans HELP, then select SEARCH, then type FREEFORM.
 --> Result: 2 HITS about profiling FREEFORM configuration. Nothing about configuration,
     XML file format, and so on.

So far, after 2 hours, the only change from NB 5.5.1 to 6.0 related to Freeform projects
is that I get UGLY icons in the project pane.  (which means BUG to me, not Freeform -
yes, I know an ant is a bug).
Is there some deliberate attempt at NB to make life difficult for freeform users?
Am I missing something here?
</RANT>

Hmm ok, so typing "free-form" instead of "freeform" gives more help....
But I'm still at loss finding one place where there is a simple, step-by-step,
howto exlaining of how to write an XML file for 2 projects, one library and
one application, correctly hooked up together.

The output of the project inspector is low-level and intended for perusal by people who understand NB internal
architecture to diagnose problems, although some parts of it (classpath information) are more accessible and more
relevant here.

There is no real documentation on freeform project configuration included in the IDE's help sets, for whatever reason.
There is a bit of information in the knowledge base, mostly on configuring actions such as debugging. The most detailed
information (which may or may not be useful in this case) is contained in a help set in the Freeform Project Extras
module, available on devel update centers, which describes the project.xml format; this module also includes a sample
library-app project pair which are supposed to be correctly linked.

For purposes of having code completion, refactoring, etc. work, the most common issue is that people neglect to specify
the Output directories/JARs correctly.

It has been said repeatedly that the issue in this case is that external build products (e.g. an output JAR not inside
the project dir) cannot be used to link freeform projects, which is well-known and a direct consequence of
FileOwnerQuery being used by ProjectSourceForBinaryQueryImpl: the external JAR is not considered owned by any project
(unless it happens to be contained inside a specified <build-folder>), so SFBQ does not know where sources for the JAR
are. This is easily reproduced using the "Freeform Anagram" sample project pair mentioned before: create the sample,
then change 'jar' in the lib project to be e.g. /tmp/x.jar, and change 'cp' in the app project to refer to /tmp/x.jar.
You may need to (re-)build the projects and restart the IDE. The app project will be displayed without errors, but CC,
FU, etc. will not work on WordLibrary except in the lib project. If you use /tmp/x/y.jar and add a <build-folder> of
/tmp/x to the lib project.xml, then it works fine, since y.jar is considered part of the lib project. The workaround is
simply to use <build-folder> whenever possible (i.e. whenever a parent folder of the build product(s) can be identified
which is used solely by that project). There is no workaround for project setups in which JARs from several projects are
placed in the same immediate folder. Possible permanent solutions include:

1. Add a <build-file> element to the freeform project.xml schema which would permit an individual file (a JAR) to be
treated as owned by the project.

2. Add a new global SFBQI/JFBQI to java/freeform which would ask open projects about sources/Javadoc for the requested
binary. (Would not enable CC to work correctly on the app project if the lib project were not open, so this is less
desirable. FU is generally done when the containing project is open so that is less of an issue.)

3. Similar to #2 but more generally, modify Project[SJ]FBQI to ask all open projects about the requested binary if there
is no apparent owner project. Again, pretty easy and would cover a lot of cases without any regressions I can think of,
but requires the lib project to be open.

Question, is there any difference in listing class files or jar files as build products?  In some of the examples, both
class directories and jar files are listed under the compilation-unit element in project.xml (built-to elements).

It would be useful for the users to get more detailed information about the project.xml elements.  I think more comments
would be useful added to the xsd's or at least on the Wiki. 

Ideally, all folders and JARs used would be listed in <built-to>. For the purposes of this issue, it is important to
list whichever output is actually used in the classpath of the other project.

Yes, this is the solution, Milan is already trying it. When user sets a jar file as the output of the project only the
jar should be owned by the freeform project not its parent.

Forgot solution #4: in the absence of a <build-file> declaration, treat any <built-to> location (or <export>?) as an
implied <build-file/folder>. Has the advantage of resolving the issue without any format change, but introduces an
inconsistency in usage.

Yes, in my case all project are side by side, and their output is put to ../_dist/

  /some/dir/project1
  /some/dir/project2
  /some/dir/_dist/project1.jar
  /some/dir/_dist/project2.jar

Which is of course nice, because it mirrors the actual deployment setup,
where all the JARs are executed in the same folder... like on the final
server installation... 

I know I sometimes sound like a jerk, complaining loudly, but this setup
(N projects all building resulting jar in a single directory) is what is found
in the original testcase I submitted April 11, 2005.......

I don't know why this issue was ever closed if that setup still cannot work.

Guys, I LOVE NETBEANS. I use it 8h/day for Java programming. 
I use SS12 for C programming.   I recommend it around. 

But that freeform problem... argh.....
Has NB code became so unmaintainable that given the following 2 set of rules:

 /some/dir/project1 GENERATE    ../_dist/project1.jar (/some/dir/_dist/project1.jar)
 /some/dir/project2 USES             ../_dist/project1.jar (/some/dir/_dist/project1.jar)

NB cannot determine that project2 uses project1 ??????????

Why on earth do we need <build-to> <build-file> for that?
What's wrong with just using the OUTPUT and CLASSPATH as URI and compare them!!!!

Sorry for the noise, but please 

One more thing: Each time I use the Project Properties panel to update my classpath,
NB rewrite my nice relative paths with bad absolute paths.... (see first chunk below)
Should I create a new bug for that?

imac:~/Work/svn-www/head cedric$ svn diff wwwproxy/
Index: wwwproxy/nbproject/project.xml
===================================================================
--- wwwproxy/nbproject/project.xml      (revision 420)
+++ wwwproxy/nbproject/project.xml      (working copy)
@@ -23,7 +23,7 @@
                     <location>src/www</location>
                 </source-folder>
                 <build-folder>
-                    <location>../_dist/jar</location>
+                    <location>/Users/cedric/Work/svn-www/head/_dist/jar</location>
                 </build-folder>
             </folders>
             <ide-actions>
@@ -104,7 +104,7 @@
                 <package-root>src/java</package-root>
                 <package-root>src/sql</package-root>
                 <package-root>src/www</package-root>
-                <classpath mode="compile">../_dist/jar/antlr-3.0ea7.jar:../_dist/jar/jtkhttp-0.11_alpha.jar:../_dist/jar/jtkutil-
0.11_alpha.jar:../_dist/jar/jtkhtml-0.11_alpha.jar</classpath>
+                <classpath mode="compile">../_dist/jar/jtkhttp-0.11_alpha.jar:../_dist/jar/jtkutil-0.11_alpha.jar:../_dist/jar/jtkhtml-
0.11_alpha.jar:../_dist/jar/antlr-3.0.1.jar</classpath>
                 <built-to>../_dist/jar/wwwproxy-0.11_alpha.jar</built-to>
                 <source-level>1.5</source-level>
             </compilation-unit>

No; see issue #50409 - you cannot currently mix hand editing and the Properties dialog.

ok

I was on vacation when activity really stirred up on this last week.  

Now that I'm back from vacation I can attach project.xml's, library XML declarations, and Projectinspector ouptut if
that is helpful.

From Jesse Glick's comments, however, it looks like I'm sunk!

All my free-form projects involve source folders that build to:
  1) ./codebase${suffix}
        - a directory of loose class files from which other jars are composed
        - used only within scope of this project
        - suffix is unique to each source folder (src -> "", src_test -> "_test", etc)
  2) ${wt_home}/srclib/${assembly}/${modname}${suffix}.jar
        - wt_home is an overall product installation instance directory
        - assembly is a product-option level directory
        - many projects' jars end up in the same directory
        - this directory is outside any project's directory tree
        - other projects build against this jar
  3) ${src-runtimeJar}${suffix}
        - an aggregate jar composed of many jars of the form from (2)
        - this directory is outside any project's directory tree
        - this jar is used at runtime

* All of these are annotated in my project.xml via <built-to> elements.
* #2 is also annotated via an <export><location> element.
* ${wt_home}/srclib/${assembly} is annotated via a <build-folder> element.

Furthermore, to work around this issue I've added a library for each free-form project that maps from all of its source
directories to all the output jars from #2 above.

In short, I've done everything I can given that the locations and names of the jars are dictated by an existing Ant
build framework -- which is why I'm using free-form projects in the first place.

In NetBeans 5.5 the library workaround works to a *fair* degree (without this workaround this bug is horrific).  In
NetBeans 6 the workaround seems to work less of the time than in NetBean 5.5.

This needs to be fixed -- at least to the point that using the library workaround produces reliable go-to-declaration
navigation.  It's long past time.  Otherwise, frankly I may have to give in and switch to Eclipse.  Note I'm pretty much
*the* NetBeans integration guy at my employer.  I write and maintain the scripts that produce the free-form projects
that interface to our Ant build framework, produce internal NetBeans training, etc, etc.  Thus if I give up on this I'm
effectively taking dozens of other NetBeans users with me.

I've implemented Jesse's suggestion 1). New element <build-file> was added to store location of produced jar file.
<build-folder> will be used only if user adds folder as build output, currently it was added also when jar file was
added. JAR file is now added as NonSourceRoot to SourcesHelper and JSFBQ then returns correct results.

Adding API_REVIEW_FAST because of change in project.xml schema.

Jesse and/or Tomasi, please review diffs. Thanks.

Created attachment 49966 [details]
ant/freeform diff

Created attachment 49967 [details]
ant/project diff

Created attachment 49968 [details]
java/freeform diff

The SourcesHelper patch definitely needs an accompanying test. What does it do? And what is the significance of
FileUtil.isArchiveFile here? I hope not that it only works on JARs - that is a facet of Java classpaths which should not
be present in ant/project (fine in JavaProjectGenerator).

Probably adding SH.addNonSourceFile would be better than overloading addNonSourceRoot to accept files, contrary to its
documentation and name.

Don't forget about the copies of schemas in www/www/ns/*/*.xsd.

Are jars that are contributed to by several projects handled at all?

I'd hope that when several projects denote that they build to the same jar (or directory) that the IDE notes them all as
partial contributors and behaves accordingly.

Certainly the *most* important case, however, is just handling any project output jar or directory which is solely
contributed to by the project -- irrespective of location of this jar or directory.

An output dir or JAR can be associated with one project only.

> An output dir or JAR can be associated with one project only.

While not the main issue here, this cardinality restriction seems arbitrary and inappropriate.

We do have multiple projects which build into directory trees and/or jars shared by many projects.  Fortunately in most
all cases as already noted we compile against jars that are specific to individual projects.  There are, however, cases,
primarily JSP compilation, where we compile against the shared directories and/or jars.

These are shared to keep the number of directories and jars manageable -- for runtime classpath manageability, runtime
classloader performance (Java's classloaders gladly re-search all jars in the classpath repeatedly for missing bean
.sers, etc, which leads to undue overhead with too many jars in some algorithms), etc.

NetBeans shouldn't arbitrarily say "won't handle it" when multiple projects contribute to a single codebase or jar.

Again, however, the most important case is for the simple output jar owned by 1 project to be handled -- irrespective of
its placement on the disk.

SourcesHelper was written the way that after adding non source root by calling addNonSourceRoot(location) then in
registerExternalRoots() it registered only *folder* roots. So I have modified it in the way that also archive files can
be registered as external roots. What else than folder and archive file can be root, until now it was restricted to
folders and now it's restricted to folders and archive files. Do you think it's a problem?

Re. SH.addNonSourceFile() it can be added, but it can be a bit misleading, since adding non source file can mean adding
XML or properties file or any other non source file, which is not the case, we are adding archived root. So I would
rather stick with addNonSourceRoot() if it's not against the name and the javadoc.

I will provide also tests.

The archive file is not a "root" because you are not registering ownership for ZIP entries; you are registering just the
archive file itself as owned by the project. Similarly, there is no reason from SourcesHelper's perspective why the
registered file needs to be in ZIP format; it could be anything. All that SH cares about is that the named file, which
is not a directory and so by definition not a root, should be considered owned by the project. It is true that currently
only freeform projects will make this call, and currently only ZIP files will be registered if you using the IDE's GUI
to make changes, but I don't think this matters. That is why I suggested that addNonSourceFile be added, and that it not
call FU.isArchiveFile but simply accept whatever file it is given.

If I correctly understood jesse's comment I can add, that for CND projects it is normal situation to "Add Existing
Item..." from anywhere on filesystem our of project root and this C/C++ file owned and built by project, so "simply
accept whatever file it is given" has a reason for CND as well.

It seems that cnd/makeproject does indeed use SourcesHelper (surprise to me). In this case actually the external file
_is_ a source, though since SourceGroup is not involved the only practical effect is that it is registered as owned by
the project. Which would suggest a new method name of e.g. SH.addOwnedFile - it is irrelevant to SH whether the file is
a build product or a source file, it simply needs to ask FOQ to register it (and perhaps change registrations later on
if changes in the evaluator cause its location to change).

Created attachment 50258 [details]
patch file

I've attached updated diff file for the fix. Tests are included and new method addOwnedFile(location) was added. Please
review. I'd like to commit the change on the monday 10/08. Thanks.

Looks OK to me, except you forgot to incr spec version in ant/project. Don't forget to update the <date> in
apichanges.xml to match when you actually commit.

Reassigning back.

Fixed. New API method addOwnedFile() was added to allow to register any external file that is supposed to be owned by
the project. To utilize the fix you need to recreate the freeform project.

Checking in ant/project/src/org/netbeans/spi/project/support/ant/SourcesHelper.java;
/cvs/ant/project/src/org/netbeans/spi/project/support/ant/SourcesHelper.java,v  <--  SourcesHelper.java
new revision: 1.23; previous revision: 1.22
done
Checking in ant/project/apichanges.xml;
/cvs/ant/project/apichanges.xml,v  <--  apichanges.xml
new revision: 1.21; previous revision: 1.20
done
Checking in ant/project/manifest.mf;
/cvs/ant/project/manifest.mf,v  <--  manifest.mf
new revision: 1.21; previous revision: 1.20
done
Checking in java/freeform/src/org/netbeans/modules/java/freeform/ui/ProjectModel.java;
/cvs/java/freeform/src/org/netbeans/modules/java/freeform/ui/ProjectModel.java,v  <--  ProjectModel.java
new revision: 1.16; previous revision: 1.15
done
Checking in ant/freeform/src/org/netbeans/modules/ant/freeform/FreeformSources.java;
/cvs/ant/freeform/src/org/netbeans/modules/ant/freeform/FreeformSources.java,v  <--  FreeformSources.java
new revision: 1.13; previous revision: 1.12
done
Checking in ant/project/test/unit/src/org/netbeans/spi/project/support/ant/SourcesHelperTest.java;
/cvs/ant/project/test/unit/src/org/netbeans/spi/project/support/ant/SourcesHelperTest.java,v  <--  SourcesHelperTest.java
new revision: 1.15; previous revision: 1.14
done
Checking in java/freeform/src/org/netbeans/modules/java/freeform/JavaProjectGenerator.java;
/cvs/java/freeform/src/org/netbeans/modules/java/freeform/JavaProjectGenerator.java,v  <--  JavaProjectGenerator.java
new revision: 1.14; previous revision: 1.13
done
Checking in java/freeform/test/unit/src/org/netbeans/modules/java/freeform/JavaProjectGeneratorTest.java;
/cvs/java/freeform/test/unit/src/org/netbeans/modules/java/freeform/JavaProjectGeneratorTest.java,v  <-- 
JavaProjectGeneratorTest.java
new revision: 1.14; previous revision: 1.13
done
Checking in ant/freeform/src/org/netbeans/modules/ant/freeform/resources/freeform-project-general-2.xsd;
/cvs/ant/freeform/src/org/netbeans/modules/ant/freeform/resources/freeform-project-general-2.xsd,v  <-- 
freeform-project-general-2.xsd
new revision: 1.5; previous revision: 1.4
done

Thanks a lot for fixing that.... 
I would like to test it, of course, so I've a couple questions:

1) What will be the next usable NB build with this fix integrated? How do I download it?

2) Could you elaborate " To utilize the fix you need to recreate the freeform project"?

  2.1)  Does that mean that I just need to open the "project properties" dialog and press "OK"?
  2.2)  What about people who wrote the project.xml manually? What exactly needs to be
           removed/changed/added in that case?
  2.3)  Will this stuff (XML freeform schema) be documented somewhere?

Thanks,
cedric

ad 1) Fix should be included in next 6.0 dev build tomorrow. Can be downloaded from
http://bits.netbeans.org/download/6.0/nightly/.

ad 2.1) No it's not enough. You need to fully recreate Output part of the project customizer, it means remove all
elements and then add all jar files again.

ad 2.2) Basically the fix would be to include, something like this:

<build-file>
    <location>../../../output/freeformA.jar</location>
</build-file>

under <folders> element in project.xml for each jar file and remove all <build-folder>s that were there just because of
those jars and not because contained class files. Also the general-data needs to be of version: 

<general-data xmlns="http://www.netbeans.org/ns/freeform-project/2">

ad 2.3) Hopefully yes.

I updated also the schema:

Checking in 2.xsd;
/cvs/www/www/ns/freeform-project/2.xsd,v  <--  2.xsd
new revision: 1.3; previous revision: 1.2
done

I've run basic tests on Win2k and OSX10.4, and it appear to work !!! Thanks !!!

I'm getting a null pointer now that I'm using <build-file>, etc.  See attached log.  I also auto-filed the exception.

There is no attached log file.

Hmmm...  I wonder where I attached that log then :-)

I'll get one attached here and look into this further.

I'd attached the log to issue #116321 instead...

Anyway, here's the log.

Created attachment 50915 [details]
Null pointer exception log

Ah....  I think I see the issue.  I had <build-file>someFilePath</build-file> rather than
<build-file><location>someFilePath</location></build-file>.  I'll change my projects, but some more explicit error than
NullPointerException would be really helpful.

The fix seems to work beautifully (without any exceptions) once I add the <location> tags, so the fix is indeed fine. 
The error checking could be a bit better, but that's the worst of it.

Thanks for verification.