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 173068 - Navigation broken in freeform projects in certain cases
Summary: Navigation broken in freeform projects in certain cases
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Freeform (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-25 01:46 UTC by chrispcampbell
Modified: 2010-01-11 04:29 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Zip containing two sets of freeform projects (15.66 KB, application/octet-stream)
2009-09-25 01:48 UTC, chrispcampbell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description chrispcampbell 2009-09-25 01:46:24 UTC
The JavaFX runtime team at Sun uses freeform projects (40+ of them) to develop the UI runtime.  The layout looks like this:

runtime/
    build.xml
    build/
        deps/
    project-1/
    project-2/
    project-3/
    ...

These projects get built in a certain order, and each project puts its output jar into the runtime/build/deps directory.  For example, project-1 generates 
runtime/build/deps/project-1.jar and project-2 generates runtime/build/deps/project-2.jar, and so on.  Suppose project-2 depends on project-1... In 
this case, project-2 will have ../build/deps/project-1.jar on its classpath, and so on.  (This layout is somewhat unusual in that each subproject does not 
have its own dist directory, but there are a number of good reasons why we lay things out this way.)

The only problem with this approach is that ctrl+click navigation and "Find Usages" don't work!  I'm attaching two sets of freeform projects:

FreeformGood: In these two projects, the output jars go into ProjectA/dist and ProjectB/dist respectively.  Navigation and "Find Usages" work as expected.

FreeformBug: Same project layout, except that the output jars go into a single build/deps directory.  Navigation and "Find Usages" do not work with this 
scenario.

All the information is correctly specified in the nbproject/project.xml files, everything that NB needs to associate the sources and output jar of each 
project.  So why does it work in one case, but not the other?
Comment 1 chrispcampbell 2009-09-25 01:48:36 UTC
Created attachment 88323 [details]
Zip containing two sets of freeform projects
Comment 2 Milan Kubec 2009-09-25 08:57:45 UTC
I'm sorry but freeform project support hasn't been designed for this particular use case, specifically that more
freeform projects cannot have one identical output folder. In such case the framework is not able to assign output file
to particular project. Changing the issue to Enhancement as we might consider to redesign the project support in this
regard in future.
Comment 3 chrispcampbell 2009-09-25 18:27:14 UTC
I see... Perhaps my expectation of how NB works is different than the way it currently works...

Each project explicitly specifies the output jar file in its project.xml file:

            <export>
                <type>jar</type>
                <location>../somedir/ProjectB.jar</location>
                <build-target>jar</build-target>
            </export>

And:
                <built-to>../somedir/ProjectB.jar</built-to>

So why should the output directory have anything to do with the way NB resolves the classpaths of other projects?  My expectation was that NB would scan 
the project.xml files for open projects to figure out how the output of ProjectA maps to the classpath of ProjectB.

(But now I can see that this approach would only work for projects that are already open, i.e., projects that NB knows about, otherwise NB wouldn't know 
where to look for the project.xml files with which to figure out the dependencies... I can see how this would be tricky to solve in the general case, without 
adding more metadata to the project.xml file.  So I guess we'll have to find a workaround in the meantime...)
Comment 4 Antonin Nebuzelsky 2010-01-11 04:29:26 UTC
Changing the default component owner to tzezula.