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:||GUI to make properties/file refs shared vs. private|
|Product:||java||Reporter:||Jesse Glick <jglick>|
|Component:||Project||Assignee:||Milos Kleint <mkleint>|
|Severity:||blocker||CC:||dbyoung, dkonecny, dmartin01, jonrichards, jrojcek, pjiricka, praveensavur, pzajac|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:|
|Bug Blocks:||41537, 49648, 89629|
Description Jesse Glick 2004-09-28 16:35:14 UTC
Should be able to specify in the GUI that a given file path is shared (relative, project.properties) or private (absolute, private.properties), since the IDE can only make a rough guess as to which is right, and sometimes the user needs to correct it. May also want to provide a GUI to let various other non-file properties be moved between project.properties and private.properties.
Comment 1 jonrichards 2004-12-21 19:13:38 UTC
I totally agree with this. Sharing a project over a group of engineers is currently not at all easy without hand editing the property files. Futhermore some options are read from the users profile directory (such as default Java source version). If private.properties isn't configured then if you get a clean build into a clean directory, and then try to build using stand alone ant, then it won't build. Only when an engineer loads the project into the IDE is the private.properties generated allowing the project to build.
Comment 2 dmartin01 2004-12-21 19:37:55 UTC
Perhaps I don't understand. Anything that is part of any Netbeans project is referred to with a relative path in project.properties. Anything that is not is referred to absolutely in private.properties. In this latter case, when someone without that private.properties opens the file, the IDE notifies the user very prominently that he/she needs to resolve references. The user right clicks on the project and choose Resolve References, and follows a simple wizard to resolve these references. Why is this a bug? Isn't it safe to assume that a resource reference that is not part of any Netbeans project is likely going to be in a different location on every different computer?
Comment 3 dbyoung 2004-12-21 19:43:13 UTC
I also agree with the above comments. I've resorted to breaking convention and committing my hand-edited private.properties (without machine or user specific code). One of the beautiful points of the Ant based projects is the ability to execute from the command line or from another IDE. This wouldn't be possible from a fresh checkout if I didn't commit private.properties.
Comment 4 jonrichards 2004-12-21 20:06:03 UTC
You are right (dmartin01), however the IDE seems inconsistant. With some projects I have created the paths have come out relative, and with other almost identical projects they have come out absolute. Do you know of a tip to persuade the IDE to place paths relative rather than absolute?
Comment 5 Jesse Glick 2004-12-22 16:36:20 UTC
Anyone adding comments please remember that you will not be notified of replies unless you are on CC. You can add or remove yourself as needed. Re. Java source level - this is handled better in 4.1, I think. The main issue is that in a well-maintained project setup, everything important should be in project.properties and using relative paths; however sometimes people choose to not keep some needed libs under version control for various reasons, in which case you need a private.properties. It is already possible to move properties between the two, but only by hand, which is cumbersome and hard to learn. To dbyoung: if you think you need to commit private.properties, you are probably doing something wrong, but I don't know what you are trying to accomplish by it. If you do have some libraries or Java platforms or whatever which are not in your version-control system (or whatever mechanism you use to share projects), of course you will need to do *something* to a fresh checkout to make it build; the IDE already has a GUI to help you do this if you open the project in the IDE (the Resolve References dialog). Re. how the IDE guesses which to use: if a path is inside the referring project's project directory, it should always be relative and shared. Or if the referring project and the referred-to path are both in the same VCS working directory (acc. to Versioning Manager in the IDE), it will also be relative and shared. Otherwise it will default to being absolute and private.
Comment 6 Jesse Glick 2005-04-27 17:07:52 UTC
Cf. issue #58356 for freeform.
Comment 7 Jesse Glick 2005-05-04 19:11:48 UTC
*** Issue 58590 has been marked as a duplicate of this issue. ***
Comment 8 Jesse Glick 2007-04-11 21:58:10 UTC
Comment 9 Jesse Glick 2008-02-25 17:48:25 UTC
Would you say this is now implemented for 6.1M2?
Comment 10 Milos Kleint 2008-02-25 19:05:18 UTC
yes, it's most probably implemented. However we've abandoned the notion of public vs private properties. We now distinguish sharable and non sharable projects. In a non-sharable project, the relative/absolute path doesn't matter, in sharable one, the IDE will attempt to resolve all paths correctly, eventually copying jars to better locations and ask the user..