Community
Participate
Working Groups
Build 20020404 Adding Java nature is not enough to cause a project to show up inside the package view. Steps: 1- create base project "Proj" 2- edit its .project file to add Java nature & builder: <?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>Proj</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.jdt.core.javanature</nature> <nature>org.eclipse.team.cvs.core.cvsnature</nature> </natures> </projectDescription> 3- switch to package view, notice that project "Proj" isn't there. Now go back to navigator, and force close/open of "Proj". It is now listed amongst other Java projects in package view.
Did we get a delta when the nature got added ? Suspect we did, but the nature was not added yet, so we did not consider it...
You need to go through IProject.setDesription(...) to add a java nature to a project. This is done if you use the UI (see Properties->Capabilities). If you just edit the .project file, platform is not aware of the change. Moving to Platform/Core for information.
I kind of remember platform advertizing this .project file as being reconciled (like we do for .classpath file). Isn't it true ?
I tried adding the java nature: - via an editor on the .project file - using Notepad in Windows Explorer and then doing a refresh local on the project Both times a delta was fired saying that the project description had changed and there was a content change on the .project file. Moving to JDT/Core for comment.
We were not clear enough. The problem is that configure() is not called on the java project when the project description is set. Moving back to Platform/Core
Ahh, that explains the problem. The #configure method should only be called once on a particular nature, and when we discover new natures via the above 2 scenerios we do not call #configure. Check out the UI doc on Natures/Capabilities for more information about when #configure is called. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/project-capabilities/Proposal.html Is it possible to listen for resource changes on the project description in your case? The problem is that in the case where we discover a project nature has been added to the description file manually, #configure may have already been called on that nature. Consider the scenerio where we are loading a project from the server. The team provider copies the .project file to the project content location and then it is discovered by us. In most cases #configure has already been run by the person who originally shared this project, and thus the build spec has already been updated, etc etc. (whatever else the nature's #configure method does) If you are providing the "edit .project manually" as a work-around to another problem, note that adding the java builder to the build spec along with the java nature will get the project to appear in the packages view. Is having users add this second entry reasonable for your work-around?
See also bug 14284. JDT Core should listen for project description changes in the delta. Moving to JDT Core for comment.
We can listen for project description changes, but there is no project description delta that I can see. So how do we know that the java nature was added or removed?
If the .project is reconciled, it must be done entirely by the platform, like we do for .classpath reconciliation. It is part of the contract that platform is configuring natures when added, and deconfiguring natures when removed. Thus if the nature is added through .project edits, it should still call #configure. If not, then consistently it should never do it, and always notify a precise delta for it, in reaction to which we would internally call #configure. Moving to Platform/Core for comments.
The contract is that configure/deconfigure is called when a nature is added/removed via IProject.setDescription. The purpose of allowing edits to .project is to support "catching up" to project (de)configures that happened in another workspace. In this case, the primary consequence of the (de)configure, updating the project build spec, has already happened. This is described in more detail in the nature proposal that DJ included a link to. Look at the final section entitled, "When are natures configured". However, your problem remains. How do you detect that a project has just become a java project, or has just become a non-java project? Can you just query the java model when the project description changes to see if that project is found in the model? Jeem, do you have any ideas about how they should deal with this? It would be possible for us to expose the old project description in the delta if necessary.
*** Bug 14284 has been marked as a duplicate of this bug. ***
Moving back to JDT Core ;-) You should be able to detect based on the resource delta when a project has become a java project. If the description has changed and the java nature is present, but that project is not found in the java model, then you should consider this to be a new java project. If you don't think this is possible, let us know and we can look into alternatives.
Moving back to Platform/Core. We will revisit the strategy w.r.t. Nature configure/deconfigure to ensure we are doing the right thing.
After discussion between Jim and Philippe, it was decided that the problem should be handled by JDT/Core for now. Moving back to JDT/Core.
Changed configure() and deconfigure() on JavaProject to just add/remove the java builder. Changed DeltaProcessor so that it listens for DESCRIPTION changes.
*** Bug 12392 has been marked as a duplicate of this bug. ***
