I was not able to reproduce this case in release41 RC build. I created folder
under project structure called lib, put some jar to it and then added the jar on
compilation classpath for the project. The result was that the reference was
created like this:
file.reference.commons-httpclient-2.0.2.jar=lib/commons-httpclient-2.0.2.jar 
in project.properties file and after moving the project to different location
the project had no broken reference.
Please provide build number and possibly more detailed steps to reproduce.

*** This issue has been marked as a duplicate of 44035 ***

This is not a duplicate. Issue #44035 requests a new feature - the ability to
create a library descriptor that can share source and Javadoc locations among
developers on a project. But even without that, even in 4.0, you should be able
to add any JAR or library to a project and have it be referenced using a
relative path in project.properties, meaning at least the classpath info is
shared among all developers, even if they need to manually configure source and
Javadoc info. This bug reports a problem with the binary classpath, which is
quite a different matter.

Might be a result of storing the absolute path in private.properties *in
addition to* the relative path in project.properties - I am not sure exactly
what the purpose of this decision was, but it might have the effect of
mistakenly marking the project as having a broken ref after a manual rename,
*if* private.properties is left intact during the rename. (Someone checking out
a fresh copy should not see any such problem.)

If so, this is a bug, but not I think P2 - you should delete your
nbproject/private/ dir when moving a project, at a minimum. If and when we have
GUI support for moving projects, it will have to do this among other things;
currently anyone moving a project may need to do one of a few steps manually to
clean up old references to the old location, depending on what their project
dependencies look like etc.

Still awaiting actual steps to reproduce, preferably with snapshots of the state
of the project before and after.

Jesse is correct about differentiating this bug from 44035 although the two are
related.

I've attached a zip file containing the project directory and userdir after
adding the library to the project. As you can see, private.properties does not
contain any absolute pathnames to the jar file. When the library is added to the
project, project.properties contains a reference to ${libs.MyLibrary.classpath}.
The only place this property is defined is in userdir/build.properties which
contains the following entry:

libs.MyLibrary.classpath=C:\\tmp\\issue-58080\\JavaApplication1\\lib\\hello.jar

To make this project sharable, library definitions and references:

1. should not reference absolute path names   -and-
2. should not depend on the user directory for pathname resolution

#1 could be resolved by defining the library property as a relative path, for
example:

libs.MyLibrary.classpath=lib\\hello.jar

However, #2 implies that this definition is sharable as well, i.e. contained in
project.properties. The larger issue of sharing library definitions is addressed
by Issue #44035.

BTW, the steps to reproduce are provided in the description.

Created attachment 21813 [details]
Testcase: project dir & user dir

It is certainly a bug somewhere if after adding $proj/lib/x.jar to $proj,
project.properties contains a mention of ${libs.x.classpath} unless it also defines

libs.x.classpath=lib/x.jar

FWIW, I cannot reproduce, so I think the INCOMPLETE marking is still justified.
I made a Java app /tmp/58080, copied JavaHelp to /tmp/58080/lib/jh.jar, defined
a lib based on this JAR, added the lib to my classpath using the GUI, and got in
project.properties

javac.classpath=\
    ${libs.test58080.classpath}
libs.test58080.classpath=lib/jh.jar

which is correct (in contrast to Mark's project.properties, which is not) and
should work for someone else checking out the project.

There is a problem that if you move the project and do not update your lib
definition in the Library Manager, the link will be broken until you do, but
that would apply to *any* project using this lib, whether it physically
contained it or not; the Library Manager does not listen to file moves (nor
could it) - you have to update its classpath if you move something it refers to.
(This I can reproduce - it is marked as having a broken reference - but for the
reason I just described, not for the reason Mark states. If you fix the lib in
the Library Manager, the project is marked as OK.)

Note that you can simply add the JAR *as it is*, not as a library, and then the
project will simply contain

javac.classpath=\
    ${file.reference.jh.jar}
file.reference.jh.jar=lib/jh.jar

which will be fine even if you move the project dir. You can still associate
sources and Javadocs just by defining a lib with the same JAR path, though again
it is up to you to change the lib definition if you move JARs around (for which
see issue #44035).

There was not a consensus about the behavior of shared libraries,
hopefully the shared libraries will be added into the next version.

Hi is there any news whether "shared libraries" will be available in NB6?

I think that it's not yet decided.

I was never able to reproduce the bug as stated, and issue #44035 may anyway
obsolete it.

Hello Jesse, 
Please kindly try to have a look at WSIT project located at wsit.dev.java.net. If you chcekout the project from the CVS
and open it in NB, the subproject WSIT-Tools contains broken library reference that has to be fixed manually. I believe
the behavior is related to this issue.

m_potociar: please see issue #44035 which is more likely what you are thinking of.