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.
Currently, it is not possible to store the project home anywhere else than in the root of the project home directory. Sometimes it would be useful to specify a different location, e.g. if the project's policy is not to put the IDE-specific files to the versioned repository, or if there is a specific subdirectory designated for the project file (the user does not want to clutter the top-level directory).
this seems like a strange request. what are the user needs? a hypothetical isn't enough here and moreover, the problem of wanting to keep the project file separate from the sources is already solvable with no additional changes.
What do you mean by saying that this is already solvable now ? You mean that you can add additional directories, where you then keep the sources, and leave the Project Home empty ? You are right, this is close, but that's not quite it. The difference is in whether or not you see the directory containing the project file in the explorer. I would argue that in this scenario the users won't want to see that - in your solution they would. As for whether this is really needed - no, this is not the kind of requirement that is absolutely necessary or the product is unusable. It's just handy sometimes. Like if you asked "why would a user want to call their java root directory 'javasrc' instead of 'src'?" I don't think you can get a clear answer to that, but users still do that.
what is so strange about it? I think that Petr described the user needs well. I will try to reword it if it was not clear: 5 developers are working on project X, 3 of them are not using any IDE, 1 is using idea and only one of them is using netbeans. Their company has a policy that they can use whatever IDE they like but they should not put any IDE-specific files into shared code base. Thus the netbeans user would prefer to store the project file outside of project sources, otherwise it appears in his 'cvs up' log all the time. There are other solutions to this: cvs allows you to mark .project as ignored file (not sure about other VCSs). Also note that this is a 'SIMPLEFIX': just make the location field editable or put a button next to it "Choose different location". on the other hand I think it's a P5, not P3
dropping the priority. what worries me is that we came to agreement that the directory the project file is in is considered an implicit source root and now you're suggesting that we have to satisfy another imaginable use case regardless of the decision we made. we chose to include the parent directory as an implicit source root bcs for the typical project hierarchies that we gleaned from interview data this was the solution that met the most user's needs. i believe we also need the implicit source root so vcs's can work with the project file as there has to be a directory to give the vcs. and yes, the project file can be anywhere you please, but no matter where it goes the parent directory will be considered an implicit source root and will show up as the first node under the project node in the Files View. this implicit source root can be used to house all other sources or it can be completely separate from the rest of the project contents therefore not poluting the sources at all. an alternative is to consider the project node as the project file's parent directory but this leads to having unnatural siblings in the Files View tree.
> on the other hand I think it's a P5, not P3 I'd settle on P4. > what worries me is that we came to agreement that the > directory the project file is in is considered an implicit > source root and now you're suggesting that we have to > satisfy another imaginable use case regardless of the > decision we made. I don't see how the decision about the implicit source root is affected by this enhancement. We can still say that the Project Home is the implicit source root, regardless of whether the project file is also in the Project Home or not. The goal is to make the implicit source root the same as the directory where the sources actually are, right? I believe this enhancement is not in conflict with this goal. BTW, it is not quite precise to say that a particular directory is the implicit source root, as the source root will be technology specific. For Java files, it will be <Project_Home>/src, for web files it will be <Project_Home>/web etc. I am sorry but I don't understand the rest of your comment, Chris. Can you please explain in other words ?
First of all, the projectHome is a well defined location that modules can use (and depend on). Yes, they can append something to it, but the project home needs to be defined. The problem is that currently the project home is derived from the location of project file, it is not stored as a separate value in project. This has a significant advantage in that when you copy/move the contents of project home dir (incl. the project file) it continues to work without any further action (provided that everything is in project home -- but that is the default). If you allow project file outside or projectHome you would need to solved this in a different way, probably by specifiying the project home in project file explicitly. It would also need to be synchronized with reference points to allow user to resolve the location of project home when she moves the project.
Yes, this is true. However, since we want to allow adding files from outside the project home to the project, we will need to solve this anyhow. If the project contains files from outside the project home, then just copying the subtree of the project home will not be sufficient to make the project work on another machine. There will still need to be UI where the user will specify the new location of the files. So what I would suggest is to reuse this UI also for Project Home, in case the Project Home is not the directory containing the project file. In a sense, Project Home would be one of the reference points. I would even argue that the project home should not be distinguished in the API in any way, it should be just one of the reference points. It could be distinguished in the UI (for the user), but modules should not be aware of it.
Given the available work arounds and the amount of other "real" problems my vote is not to do this for 4.0 and wait for the user to tell us they need it. I have no more comments to this.
i agree.
Agreed.
project's work is doing something very different now and this bug doesn't particularly apply (or it needs to be in the context of the new build system).