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 49637 - GUI to make properties/file refs shared vs. private
Summary: GUI to make properties/file refs shared vs. private
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker with 4 votes (vote)
Assignee: Milos Kleint
: 58590 (view as bug list)
Depends on:
Blocks: 41537 49648 89629
  Show dependency tree
Reported: 2004-09-28 16:35 UTC by Jesse Glick
Modified: 2008-02-25 19:05 UTC (History)
8 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
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,
or private (absolute,, 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 and
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 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 generated allowing the project to 
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  
Anything that is not is referred to absolutely in  In this latter case, when someone without that 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 (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
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 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 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, 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
Tentative plan.
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..