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.
I have a project/POM at directory X. I then have the structure: X -shared --results -gui --cfg Too, I'm using Mercurial, and I am working on more than one branch at a time, so I will pull and push from/to the central server using only one directory: hg clone http://somepath X-integration Next hg clone X-integration -b THEBRANCHTOWORKON X-branchname I will push/pull in X-branchname from X-integration. From integration will pull/push from server. I have opened projects from X-integration before. I now have a (File->Project Group) with only projects from X-branchname open however. I have cfg open but not shared/results. I click on a method call of an object from shared/results(someObjectInstance.someMethod()) and the IDE opens the file. The file it has opened is under X-integration and not under X-branchname. So that is wrong. Too, now when I click on "Select in projects" and the IDE asks if I would like to open the project and I click "Yes" it opens the one under X-integration instead of the one I wanted. I am unsure of the hooks the IDE has to the projects in this regard nor if there is an SPI where Maven support has registered a provider of some kind which tells the IDE what to open, but these projects do point to reference parent POMs. Scanning the directory the current project resides backwards/upwards, checking pom.xml, would yield the parent folder eventually. Too, scanning the tree back down would yield the correct child. I don't know what kind of indexing the Maven support does of the overall project structure in this case, but that seems something which could be done to make this faster for consecutive uses. Anyways, currently a PITA as one has to close out and open the right ones manually. I have noticed this for a long time, but just now lazily getting around to filing it.
I also noticed that after I opened the correct project under X-branchname that the IDE still opens the file under X-integration when I click on the method name. I am having to manually go to the file.
in general only 1 project/location per entry in local repository is safe. If you have 2 projects at different locations that have the same GAV and share the same space in local repository, the results observed will depend on what was opened in which order etc.. Applies not only to project loading, but also to cmd line maven builds. Only save way there is to rebuild the entire source tree. also please note that closing a project will have no effect, nor will restarting the IDE, as we currently persist the mapping of GAV to local source pom.xml file. Only opening the alternate location should overwrite the mapping..
(In reply to comment #2) > in general only 1 project/location per entry in local repository is safe. If > you have 2 projects at different locations that have the same GAV and share the > same space in local repository, the results observed will depend on what was > opened in which order etc.. > That is only due to the current design of the project support in the IDE though, and not a general rule of safety. > Applies not only to project loading, but also to cmd line maven builds. Only > save way there is to rebuild the entire source tree. > Sure, but that is just because the artifacts and location. Once one rebuilds maven doesn't care where on the disk the sources were. Surely anyone using a revision control system, even with Maven, works on more than one branch at a time, and many times it is just more natural to have two working directories. Otherwise you are stuck doing a bunch of commit, update, merge, commit, etc and just add blather to your project until you actually have some work done. Having to perform a build versus being able to have two or more working sets of changes is a very minor trade off. The only safety concern comes into play if someone tries to build a project depending upon something they are changing in another branch. They can get funky results etc. If they understand that, and I think most Maven users should (...maybe would), then they can get all the benefits from Maven and Mercurial together. For instance, we have a rather large NB RCP based project. It takes me a minute or two to build (Maven is much faster than Ant in this regard from what I have seen). If I have 2 or more people I'm reviewing things for, helping fix bugs, and working on my own code and issues, I would have to not only build again, but would have to make sure everything is committed, perform updates to a different branch, etc. Adds an extreme amount of time to a days work for no gain. I think without doing that one would have to change out POM versions across an entire project, which can be really massive, and then change them back before they merged and pushed since individual feature sets do not change the version of the final product one is trying to release. Still yet another time factor. > also please note that closing a project will have no effect, nor will > restarting the IDE, as we currently persist the mapping of GAV to local source > pom.xml file. Only opening the alternate location should overwrite the > mapping.. I am not sure even opening the alternate location is doing it. I have manually opened the other project under X-branchname, yet when I click on the method name, it still opens the source file under X-integration. However, I did perform this operation again, after restarting and it is working this time. I'm not sure, but it isn't clear how to really make it happen in a consistent manner. I have a project group opened for X-integration. I open the one for X-branchname and close a specific project. I change back to the X-integration project group. I make sure and open a file from that specific project using a method name as a link. It opens the one under X-integration. Next, I open the project group for X-branchname (the one where I was sure to close that specific project). I open a another project under X-branchname where I know I can click on a method as a link and open a file in the project I had closed from which I should be able to click "Select in projects" and it open the project which the file belongs. It is now opening files under X-branchname, so something is not consistent with the way things are working. The solution to me is for the IDE to be smarter about which file it has open and how things should be relative to that, and then barring that, use some other mechanism to locate something the IDE knows about. I can easily derive that if the file I have open resides under X-branchname that other projects I link to, if they exist under that, should be opened versus one which simply has the same GAV. It is even easier if they exist under the parent path of another and my POM references the others as parents. Seems some of this information is used already. For instance, I have this structure: X-branchname -pom.xml -gui --pom.xml --cfg ---pom.xml --geometry-client ---pom.xml -shared --pom.xml --results ---pom.xml I can expand the "Dependencies" node under cfg. It depends among many other things on geometry-client (sibling in file system structure) as well as shared/results (not a sibling and outside of the top level POM project folder, in a different tree. If I click on those dependency nodes and choose to open the project it will open the correct ones under X-branchname versus X-integration. The projects do not use the path element of the POM parent, but only reference the parent GAV. The IDE is some how deriving those locations correctly, but then again, as I mentioned earlier in this comment, it seems things are not behaving consistently. For some projects it is opening them the way I say it should were it "being smarter", but some, it isn't. I'm still trying to track down the issue it seems. When I started writing this comment I thought I understood what was happening exactly, but that isn't entirely accurate I do not believe.
OK, I have it now. This accounts for what I observed, and thinking as I'm about to write things work as I expect. If one has a structure: X-integration -shared --results -gui --cfg --geometry-client and they open only cfg, then clicking on something which should open geometry-client or results will not. If they open gui, then clicking on something in a file of cfg which would open a file in geometry-client will correctly open the file. If they open X-integration, then clicking on something in results from cfg will open the correct results even if not open. However, if those parent POM projects are not open, then the result of that click will be to first try to open the last opened project/copy, and barring that, decompile compiled code if able. So, to me, it seems the only thing missing is a little analysis of where cfg/pom.xml resides when it is opened alone. Working ones way backward up the directory structure they can find parent POM files which will eventually lead them to a state where it would be as if having X-integration open. That not being the case now makes for some funny situations. Now that I know how it works, and Milos if this is what you meant, apologies, then it will be a lot easier to use, but I think until one knows that things are pretty confusing. What do you think about walking up the dir tree looking for pom.xml to compare parent POMs? That seems it would make the way this works complete. Too, is this current behaviour documented any where?
I can see this being an improvement/enhancement per my last comment, but I still feel it is a defect because using the context of an opened POM seems correct and natural to me. That said, if you all need it to be an enhancement I could live with it, but I do think it is a big deal if everyone else is a thick headed as myself :-P I have sucked up a lot of time with that little issue over the past so many months.
(In reply to comment #4) > X-integration > -shared > --results > -gui > --cfg > --geometry-client > > and they open only cfg, then clicking on something which should open > geometry-client or results will not. Right - the IDE does not check stuff up the tree, only down. > If they open gui, then clicking on > something in a file of cfg which would open a file in geometry-client will > correctly open the file. Right. > If they open X-integration, then clicking on something > in results from cfg will open the correct results even if not open. Right. > the only thing missing is a little analysis of where > cfg/pom.xml resides when it is opened alone. Under consideration if performance can be made good. If in doubt, always open the root aggregator project first. *** This bug has been marked as a duplicate of bug 203222 ***
jglick: a possible cause of the problem is that MavenFileOwnerQueryImpl maps maven coordinates to project urls, but for some reason uses only groupId + artifactId (GA) in the mapping. when asking for ownership we get the project url for GA from preferences and load the project at found url. if GAV (not GA) matches we declare victory, if version is different however we just return null. That way if you open 2 projects with the same GA but different GAV (typically 2 branches of the same codebase) one of them will always be ignored by the FileOwerQuery which has significant consequences.
(In reply to comment #7) > MavenFileOwnerQueryImpl maps > maven coordinates to project urls, but for some reason uses only groupId + > artifactId (GA) in the mapping. Right; wanted to avoid excessive churn in mapping, and huge numbers of stale entries, just due to routine use of maven-release-plugin or the like. > if you open 2 projects with the same GA If you open them at once you are likely to have problems, regardless of <version>. If you open them separately (i.e. close all old projects, then open at least the root aggregator for the desired branch) then externalOwners.properties should record the currently open locations and all will be well. > different GAV (typically 2 branches of the same codebase) Possibly, though most actively developed branches are likely to use the same <version> as trunk, at least in the naive Maven workflow which (as in comment #2) is error-prone. In the less common case that the GAV actually differs on the branch, keying externalOwners.properties off GAV (and dealing with stale entries some other way) could help with this issue, but a fix of bug #203222 would be more general.