Bug 49637

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.

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?

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.

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?

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.

Cf. issue #58356 for freeform.

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

Tentative plan.

Would you say this is now implemented for 6.1M2?

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..