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.
Add jar/folder is one of the most annoying things in netbeans. It has recently become worse because it used to default to adding the jar with its relative path. But now, it defaults to using the absolute path, which is pretty much never what I want to do. At the very least, it should remember the previous selection, so that everybody got their taste.
Fixed. http://hg.netbeans.org/core-main/rev/9ab3fe5f474c
Integrated into 'main-golden', will be available in build *200909220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/9ab3fe5f474c User: Milan Kubec <mkubec@netbeans.org> Log: #169967: making user selection static to preserve the state
Afaict, it now defaults to 'relative' *after* your first addition, regardless of what you chose. Before that, every time you start netbeans, it defaults to 'absolute'. IMV this is not correct behaviour. It should *remember* your last selection, and preferably across restarts (otherwise default to 'relative' on restart).
9ab3fe5f474c doesn't make any sense and I reverted it in core-main #010e399af0da. I think Milan saw a variable which checked whether the user had overridden a selection, and misinterpreted it as the selection itself. That would account for the bizarre new behavior seen in 6.8. So going back to the original request: (In reply to comment #0) > it defaults to using the absolute path No, the behavior is rather as follows: 1. If the JAR is considered "collocated" with the project basedir according to some provider of this information (generally a version control system which checks whether file paths are in the same checkout), then Relative is checked by default. (Since it can be assured that someone else checking out the same sources would indeed be able to use the same path.) 2. If the JAR can be referred to using a named variable, that is used. 3. If the context permits the JAR to be copied into ./lib, that is selected. 4. Otherwise, Absolute Path is selected as a fallback. Persisting a user preference for the radio button would clash with this logic. Some sort of hybrid behavior between #1 and #4 involving persistent preferences would be possible but potentially confusing.
I don't have the nerve to reopen this, but my original complaint hasn't been addressed. The behaviour for me is that it does default to absolute paths. Possibly one of the steps in the logic you describe isn't being fulfilled. But the problem is deeper: 1 - I hate mixing my projects with the repository tree (there might even not be a repository tree), so this fails. This is the scheme I try to adhere to in order to be productive: Projects/Project1/devel/Module1/... (src, lib, whatever) Projects/Project1/devel/Module2/... (src, lib, whatever) Projects/Project2/devel/ModuleX/... (src, lib, whatever) Projects/Project3/devel/ModuleY/... (src, lib, whatever) (The above organisation is dictated by my company; below is how I organise my IDE projects) Projects/Netbeans/proj1-mod1/(nbproject, var/build, var/dist...) Projects/Netbeans/proj1-mod2/(nbproject, var/build, var/dist...) Projects/Netbeans/proj2-modx/(nbproject, var/build, var/dist...) Projects/Netbeans/proj3-mody/(nbproject, var/build, var/dist...) 2 - What does this mean? 3 - Usually the jars are in a lib alongside src, but src isn't necessarily ./src (see above). 4 - Why? In fact, why go through all this at all? What purpose does this logic serve? It seems to be trying to divine my intent, but it's failing. If I have to add 1000 jars, I have to tick 'relative' 1000 times. What is 'absolute path' good for? I admit sometimes one may wish to use absolute paths - well, then this looks to me like an area blatantly in need of a persisted user setting. In not user setting, at least per-project setting. The divinatory logic is laudable, but I can't see that it does any good.
(In reply to comment #5) > I hate mixing my projects with the repository tree Not sure what this means exactly. All that is required for #1 is that the JAR and the project dir are in the same VCS checkout, in which case it makes sense to use a relative path. If they aren't, then the relative path between them is not being controlled as part of versioned sources - usually because either the project metadata is unversioned, or the JAR is in some user-specific location. > 2 - What does this mean? You can define variables and refer to them in file paths. > 3 - Usually the jars are in a lib alongside src If you define a local library location in the project, NB will use paths relative to that lib dir. > What is 'absolute path' good for? David introduced this logic so he may be better able to answer. IIRC a lot of people use a common file server and want shared absolute paths such as \\Team\Our Libraries\junit.jar Trying to store e.g. ../../../../../../../../Team/Our Libraries/junit.jar in project.properties is not only pointless, it is harmful (since the number of "../" needed will vary by user). > If I have to add 1000 jars, I have to tick 'relative' 1000 times Certainly for any kind of bulk operation you are better off editing project.properties directly.
Thanks for your reply: >> I hate mixing my projects with the repository tree > > Not sure what this means exactly. I mean that my 'netbeans project' is in a separate tree from the sources/libs/docs/etc which are the IDE-agnostic part of the project: Projects/Project1/devel/Module1/... (src, lib, whatever) Projects/Project1/devel/Module2/... (src, lib, whatever) Projects/Project2/devel/ModuleX/... (src, lib, whatever) Projects/Project3/devel/ModuleY/... (src, lib, whatever) (The above organisation is dictated by my company; below is how I organise my IDE projects) Projects/Netbeans/proj1-mod1/(nbproject, var/build, var/dist...) Projects/Netbeans/proj1-mod2/(nbproject, var/build, var/dist...) Projects/Netbeans/proj2-modx/(nbproject, var/build, var/dist...) Projects/Netbeans/proj3-mody/(nbproject, var/build, var/dist...) 'Projects' is my own folder. Project1, Project2, etc, are independent VCS roots. > All that is required for #1 is that the JAR and the project dir are in the same > VCS checkout, in which case it makes sense to use a relative path. If they > aren't, then the relative path between them is not being controlled as part of > versioned sources - usually because either the project metadata is unversioned, > or the JAR is in some user-specific location. Yes, the project (IDE) metadata is not part of the same tree. We have IDE freedom (otherwise we'd be force-fed Eclipse) and IDE settings are not stored in the repository. I'm trying to get people to use Maven in order to reduce this problem, but it's there and it's hardly our own only. >> 2 - What does this mean? > > You can define variables and refer to them in file paths. In my project.properties I usually find 'references' which seem like ant-usable variables, but they can refer to absolute paths as well, that's why I asked. >> What is 'absolute path' good for? > > David introduced this logic so he may be better able to answer. IIRC a lot of > people use a common file server and want shared absolute paths such as > > \\Team\Our Libraries\junit.jar > > Trying to store e.g. > > ../../../../../../../../Team/Our Libraries/junit.jar > > in project.properties is not only pointless, it is harmful (since the number of > "../" needed will vary by user). That's sensible. But in that case it seems to me that it would have been better simply to try to detect cases like '\\' or NFS mount points. >> If I have to add 1000 jars, I have to tick 'relative' 1000 times > > Certainly for any kind of bulk operation you are better off editing > project.properties directly. But I'm not talking bout bulk operations. I mean having to add some jar now, another one two hours from now, another two during the afternoon. Today, tomorrow and the day after. Or having to create a bunch of projects from existing sources. The fact is that every single time I want to add a jar into a project I have to remember to manually change the radio button's setting. That's tiresome, not less emotionally.
(In reply to comment #7) > IDE settings are not stored in the repository In this case using a relative path is not so important anyway; you will not, say, be breaking a continuous builder by accidentally checking in an absolute path. > I'm trying to get people to use Maven That would certainly make this kind of issue moot. >> You can define variables and refer to them in file paths. > > In my project.properties I usually find 'references' > which seem like ant-usable variables In this context, "variables" means things defined in Tools > Variables. > it seems to me that it would have been better > simply to try to detect cases like '\\' or NFS mount points. Perhaps. Not possible in a portable way prior to JDK 7. > I'm not talking about bulk operations. I'll let David comment. The best I can think of is to record cases where the default behavior would have been absolute and the user explicitly picked relative instead (and perhaps vice-versa as well), and then an analogous situation arose again. Or to inspect existing file references in the project, and if they all use one style consistently, use that as the default in the file chooser subsequently (if it is permissible in the particular case, i.e. if that radio button is enabled).
Should be open as an enhancement, though the current behavior is as originally designed.
entonio, > IDE settings are not stored in the repository as Jesse said, if you do not store NetBeans project settings in repository in order to share them with other NetBeans users in your team then what's the point of relative paths? Just use absolute ones. > But I'm not talking bout bulk operations. is this because you do not store NetBeans project settings in repository and you have to recreate these settings repeatedly from scratch? My ratio of editing-source-code versus configuring-project-classpath is like 1000:1. Sure when you start project you tweak the classpath couple of times but remaining 999 days you just type code and project settings are the same no? I would be interested in learning more about the way you use the IDE and projects. Btw. when adding jars you should be able to select multiple jars at once. Defining variable in Tools->Variables for "Projects/Project1/devel/Module1" or maybe directly for "Projects/Project1/devel" should be exactly what you need. For example if you define MODULE1_ROOT variable as Projects/Project1/devel/Module1 then your project files will contain just MODULE1_ROOT/lib/some.jar. I would also strongly encourage your company to change practice and store project metadata along side of project sources, that is directly in Module1/, Module2/ etc. Or if they insist have something like Projects/Project1/devel/Module1/netbeans (nbproject, build, dist) Projects/Project1/devel/Module1/eclipse (.project, .classpath) it would not only make it easier for your IDEs to setup them but I would also argue that storing project metadata with your source files is best practise and essential to reproduce the same build of your projects today and in future time. It is also essential for team members to share single (correct) project setup. It is possible I'm missing a full picture here of your setup. Anyway, this is just FYI.
Thank you all for commenting, >> IDE settings are not stored in the repository > > as Jesse said, if you do not store NetBeans project settings in repository in > order to share them with other NetBeans users in your team then what's the > point of relative paths? Just use absolute ones. When I copy some project over from my Windows to my Mac, or give it to some co-worker, it works perfectly well since every where there is some Projects/Netbeans/... folder alongside all the Projects/ProjectX folders - only the specific location of 'Projects' varies. >> But I'm not talking bout bulk operations. > > is this because you do not store NetBeans project settings in repository and > you have to recreate these settings repeatedly from scratch? I seldom have to create them more than once. It's more like programs being built from scratch and growing to include more dependencies along time. > My ratio of > editing-source-code versus configuring-project-classpath is like 1000:1. Sure > when you start project you tweak the classpath couple of times but remaining > 999 days you just type code and project settings are the same no? I would be > interested in learning more about the way you use the IDE and projects. I routinely have to switch between lots of projects. Many are dependent on others, so often the same jar has to be added to more than one. In particular, whenever possible I don't put any java into web projects, so each web application usually requires two projects (I find the Netbeans split between java/web projects inconvenient; I'd like a 'web project' to be simply a java project with added web things, rather than a project with web things which also edits/compiles java). After five years of using it every week-day, this is the way I found I can make the most out of NB. > Defining variable in Tools->Variables for "Projects/Project1/devel/Module1" or > maybe directly for "Projects/Project1/devel" should be exactly what you need. > For example if you define MODULE1_ROOT variable as > Projects/Project1/devel/Module1 then your project files will contain just > MODULE1_ROOT/lib/some.jar. I suppose then that if I define PROJECTS_ROOT as 'Projects' in every project it will be a way to get what I want (the dialog to default to 'relative'). I'll try it when 6.9 comes out. > I would also strongly encourage your company to change practice and store > project metadata along side of project sources, that is directly in Module1/, > Module2/ etc. Or if they insist have something like > Projects/Project1/devel/Module1/netbeans (nbproject, build, dist) > Projects/Project1/devel/Module1/eclipse (.project, .classpath) > it would not only make it easier for your IDEs to setup them but I would also > argue that storing project metadata with your source files is best practise and > essential to reproduce the same build of your projects today and in future > time. It is also essential for team members to share single (correct) project > setup. As I said, I'm working on having everyone move to Maven. The problem is that project metadata is part of the project, but at the same time it is IDE-specific.
(In reply to comment #11) > if I define PROJECTS_ROOT as 'Projects' in every project it > will be a way to get what I want Yes, I think this is a good fit. A given user need only define this variable once to be able to use any of the projects, and the projects are not forced to be in a particular position relative to the versioned sources. > (the dialog to default to 'relative') Well, to "Path from Variable". > I'll try it when 6.9 comes out. Should work already in 6.8 (maybe even 6.7, don't remember).
Integrated into 'main-golden', will be available in build *201002180200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/010e399af0da User: Jesse Glick <jglick@netbeans.org> Log: Reverting bad fix of #169967: preference for selection style.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss