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.
Summary: | Navigation broken in freeform projects in certain cases | ||
---|---|---|---|
Product: | java | Reporter: | chrispcampbell <chrispcampbell> |
Component: | Freeform | Assignee: | Tomas Zezula <tzezula> |
Status: | NEW --- | ||
Severity: | blocker | CC: | trembovetski |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | Zip containing two sets of freeform projects |
Description
chrispcampbell
2009-09-25 01:46:24 UTC
Created attachment 88323 [details]
Zip containing two sets of freeform projects
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. 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...) Changing the default component owner to tzezula. |