Bugzilla – Full Text Bug Listing
| Summary: | Not possible to Enable an arbitrary project as a Faceted Project from UI | ||
|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | Darryl Miles <darryl> |
| Component: | Faceted Project Framework | Assignee: | Konstantin Komissarchik <konstantin> |
| Status: | RESOLVED FIXED | QA Contact: | Konstantin Komissarchik <konstantin> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | benjamin.dev, burkhard.vogel, david_williams, deboer, eclipse.dserodio, konstantin, mauromol, pwebster, remy.suen, s.maratea, susan, thatnitind, wmitsuda |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | 3.2 M6 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
It would be cleaner to use the Configure menu (http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08487.html) on non-Faceted projects. > Marked "Major" as this is a regression, there used to be a Project right click > action to setup/enable faceted project on any project. In 3.5.1 is does not > appear which is the main reason for this bug "Not possible to Enable an > arbitrary project as a Faceted Project from UI". Not sure who was providing this action before, but it certainly wasn't coming from the framework. Converting an arbitrary project to a faceted project is discussed frequently, but we have not taken any actions to move in that direction because the general problem is quite involved. While it's trivial to just enable the nature and the builder, that's really a small portion of a complete story. Presumably the project has some content in it already, so you'd want to be able to detect what's there and have some sort of a mechanism to apply facets, deal with conflicts, etc. In short, quite a substantial undertaking to do it in a way that wouldn't just confuse most users. > Please ensure the Project preferences page for "Project Facets" is always > available (to all projects at all times). > > However... if the project is not a faceted project (i.e. there is no builder > and nature setup in .project file) then the ONLY thing on the page should be an > explanation about what Project Faceting is with a button to enable it on this > project. That's certainly one approach. One of the complications is that the framework actually has two property pages: Project Facets and Targeted Runtimes. Using the context menu is also a possibility, but as you say it's very crowded. > I also think that there should be a repair "Repair Project Settings" button > too, i.e. at the left hand side (inline with the Revers/Apply buttons). When > the project preference page is first loaded a quick "installation check" is > performed, which basically re-checks the necessary builder/nature are > installed (and in the correct order, in relation to other builders/nature, if > order is important). If they are found to be correctly in place the button > is greyed out, if a discrepancy is found the button is active. You are not the first to propose a repair action. However, there is already a facility in Eclipse for detecting problems, reporting those problems and letting users fix them. Of course I am talking about builder/validators, problems view and quick fixes. Faceted Project Framework includes a light-weight validation framework than any facet author could choose to take advantage of to perform integrity checks and then attach quick fixes to repair the configuration. (In reply to comment #1) > It would be cleaner to use the Configure menu > (http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08487.html) on non-Faceted > projects. Can't say I'm a fan of any right-click actions (which is used once for the lifetime of the project). Makes most sense just to have everything in one place in the project preferences page. (In reply to comment #2) > Not sure who was providing this action before, but it certainly wasn't coming > from the framework. Converting an arbitrary project to a faceted project is > discussed frequently, but we have not taken any actions to move in that > direction because the general problem is quite involved. While it's trivial to > just enable the nature and the builder, that's really a small portion of a > complete story. Presumably the project has some content in it already, so you'd > want to be able to detect what's there and have some sort of a mechanism to > apply facets, deal with conflicts, etc. In short, quite a substantial > undertaking to do it in a way that wouldn't just confuse most users. Exactly what does go on behind the scenes during "Faceted Project Enablement" process (please describe in detail) ? Remember we are not adding any faceted attributes we are simply discussing enablement of the facet system/philosophy on a project. So that the Project preference page becomes active to configure the specific facets. Nope I'm not asking for some system to detect stuff, maybe you can save that for version 3 or something, write a paper and open up discussion on it etc..., lets just get version 1 usable for real-life situations. The real-life situation now is that many plugins are using facets to enable features based on project type detection. So if the facets are not set then great amounts of functionality is automatically disabled and hidden from view. The next problem is that for many project wizards the resulting project is left in a state where it is not possible via the GUI to make the Facet configuration page appear in the "Project Preferences". Arrrrrggggghhhhhhhh <hair-pulling-action/> !! <polite-tone> So stop being annoying and hypothesizing on potential future problems which do not exist yet and stop using them as a barrier to addressing the issue. This problem needs a solution today as it is a very real problem today. </polite-tone> Are you saying that in order to get assurance and guarantee of access to add facets, all projects must start life via the project creation wizard as a "Faceted Project Wizard". If so do you know that you are not the only project that demands this and there is something of a glaring hole in the Eclipse philosophy where many module providers only support *their* features on a project if you started with *their* wizard. The problem of course if you can only start with one project wizard but my project should be able to make use of various features all at once, should not it ? This is a kind of project-racism and I see it developing in eclipse now, it does not not harbor collaboration. Isn't the Facet system itself is trying to address this problem ? > That's certainly one approach. One of the complications is that the framework > actually has two property pages: Project Facets and Targeted Runtimes. Using > the context menu is also a possibility, but as you say it's very crowded. This bug is about the complete lack of approach, so any approach would be welcomed. I was just trying to report that other plugins use the project preference pages as the entry point to "setup" of that component as well as the "reconfiguration" of that component. You just change what is displayed on the main part of the page. The reason why I like this approach is that there is no longer any hidden button/action/toolbar items to find and I like the concept that everything that is possible to be setup on a project be available by flicking through the "Project Preference" pages as a kind of catalog/menu of what is possible. Also if something is not possible the page can also explain why it is not possible to the user. If the "Project Preferences" gets too cluttered itself with features that are not yet enabled then just add a new top level in "Project Preferences" to group them, a node "Inactive Features" and have a sub-tree of them all under there. > You are not the first to propose a repair action. However, there is already a > facility in Eclipse for detecting problems, reporting those problems and > letting users fix them. Of course I am talking about builder/validators, > problems view and quick fixes. Faceted Project Framework includes a > light-weight validation framework than any facet author could choose to take > advantage of to perform integrity checks and then attach quick fixes to repair > the configuration. The problem with "Problems View" it doesn't solve then question: Is my project correctly configured to be "facet-able" ? The problems view is "reactive", it sees problem and reports a problem. You can't inquire with the question "Is there a problem with xyz ?" To help you diagnose a situation. The "Problems View" is best left to assisting with problems better addresses reactively. It is no good for fault diagnosis, since it doesn't tell you what things are "good". Users can be very quick to blame the IDE and software in the IDE (for what are configuration problems). The use of a button in the way I described addresses everything. Sorry if this comment has turned slightly into a push for culture change. Its been a few major versions of Eclipse since facets were around and still such glaring problems exist. I'd hate to be a new user trying their best to get work done without knowing how to manually edit .project files. Wow, I can see that you are very passionate about this. We need more users like you contributing to the discussions and maybe eventually contributing patches. ;) > Exactly what does go on behind the scenes during "Faceted Project Enablement" > process (please describe in detail) ? Nothing beyond what you have already discovered. A nature and a builder that's used for validation are added. > Nope I'm not asking for some system to detect stuff, maybe you can save that > for version 3 or something, write a paper and open up discussion on it etc..., > lets just get version 1 usable for real-life situations. I realize that you are not asking for this, but you are an advanced user. The concern is if a novice user goes down this path, they will not necessarily know where to go from there. You have to have a really good idea of what's in your project already, enable the corresponding facets, select the correct version and tweak their install configuration. If a user screws up during this process, the results can be rather unpredictable, leading to a lot of confusion. An expert like you would likely be able to navigate this process. A novice user, not so much. > <polite-tone> So stop being annoying and hypothesizing on potential future > problems which do not exist yet and stop using them as a barrier to addressing > the issue. This problem needs a solution today as it is a very real problem > today. </polite-tone> I understand that you feel this to be a critical outage and I can assure you that your opinion will be considered, but you have to realize that we have to look out for all users out there and make sure that any features that we introduce don't have unintended consequences. This does not imply that I am against moving on this incrementally. > Isn't the Facet system itself is trying to address this problem ? Exactly. The key is to make sure that you are starting from a stable state. We have a pretty good grip on how to start from an empty project (via a variety of wizards), but starting from a project that already has stuff in it but doesn't have any of facet bookkeeping is completely different level of complexity in terms of being reasonably assured a positive outcome. There is also an API for anyone to roll their own entry point, like the entry point that it sounds like you've used in a prior version that someone else wrote. We have had cases were people wrote specific conversion actions for specific cases that were limited in scope and therefore could be configured automatically with minimal possibility for user confusion. > The reason why I like this approach is that there is no longer any hidden > button/action/toolbar items to find and I like the concept that everything > that is possible to be setup on a project be available by flicking through the > "Project Preference" pages as a kind of catalog/menu of what is possible. > Also if something is not possible the page can also explain why it is not > possible to the user. I tend to agree with you on this point. You cannot beat the discoverability as users who expect facets will head to that project properties page first. > The problem with "Problems View" it doesn't solve then question: > Is my project correctly configured to be "facet-able" ? That's a completely separate question from validation. A project is still valid if it doesn't support facets. > The problems view is "reactive", it sees problem and reports a problem. You > can't inquire with the question "Is there a problem with xyz ?" To help you > diagnose a situation. I would argue that you shouldn't have to inquire. The system is fully capable of detecting any issues on the fly and telling the user about them without the user realizing that they should inquire. One case where you can see this in action is mismatch between java facet version and java compiler level settings in project properties. If the two get out sync, the user is immediately told about the problem and is given quick fixes for the various ways to get back to a good state. I look at the problem in reverse. You claim a new user would be confused by facets if they did not interact correctly. I am claiming that this interaction stuff between facets is an unimportant side-line, to the main purpose. Which is to ensure enablement of contributed features in the IDE so that real-work can be done using those contributed items. If there is ever conflict between the 2 goals the enablement must always win, the interaction problem will come out during use/testing. But you can't even develop/use/test things enablement can not be effected. Its far easier to diagnose an error message you see (from some bad interaction between facet combinations) than it is to get real-work done when the buttons to do the work don't even show up in the IDE. New users can not press on something they can not see, so no wonder you don't get any bug reports from users about problems in functionality they can not access or didn't know existed. The lack of bug reports means everybody must be happy and there are no bugs. Or could it mean that no one is using it. I understand you as "facet subsystem" creator have your vision in an ideal world which may include : * You write up and keep up-to-date some best practice guidelines * You provided "Technology Compatibility Kit" to allow other plugin vendors to verify their usage of the facet system. * You provide a complex example where all that best-practises can be demonstrated in use. * Where plugin vendors can request certification that they conform to best-practice. * Plugin vendors have all the time the need to take proper attention to the above resources and keep up-to-date. But this isn't the world I see, far from it. I take the point of validation being around for this purpose but the validation concerns should be separated: * Validation of the project content (source, descriptors, classpath, etc...) * Validation of project IDE configuration (enabled facets are each happy with their own specific part of project configuration, etc..) * Validation of IDE configuration (plugins installed, workspace, etc...) I'm sure most users would think that validation covered only the first item. This item leads itself to having a builder and running asynchronously and in real-time during project changes. The last 2 items should have a formal "Start" button, with a detailed diagnostic output, cut'n'paste-able. Any validation presented outside of that process should only be in the form of a *warning* and the user should always have the *right* to override the IDE warning. After all this is validation, i.e. guidance not policy enforcement. Sometimes you need to let users screw up their configurations all they want, sometimes you have to make a mess to cleanup. Any novice users could always run the "validation of project IDE configuration" process and get a blow by blow account from each thing about what that thing sees as wrong with the project. For example two facets object to each other being set on the same project, so the report will show both of them opposing the other facet. Now you give back the developer (the user) the choice in the matter. Note that I consider the greying out of the "Apply" and "Ok" buttons in the facet preference pages to be a form of policing not a form of advisement. IMHO the user should have the right to click "Ok" swallow a dialog warning and reconfirm they really do want to proceed and then be left to the consequences. The objection is when guidance turns into policy enforcement and that policy enforcement rightly or wrongly now gets in the way of getting real work done. The purpose of using Eclipse IDE is to be more productive and anything Eclipse does out-of-line of that basic goal is not good for Eclipse's reputation. The above is more for background on my point of view and thoughts, since I do not have any concerns expressed here over the facet configuration page itself. The purpose of this bug is over the matter of "Faceted Project Enablement". I am claiming that I do not think every project wizard needs to get directly involved in ensuring all the projects they create are "Faceted Project Enabled", I think this is a matter 100% for the "Faceted Project Framework" component to deal with. Thanks for your replies. I think my PoV has been expressed enough with clear reasoning and suggestions for a better path to tackle problem touched upon. (In reply to comment #5) > I tend to agree with you on this point. You cannot beat the discoverability as > users who expect facets will head to that project properties page first. Perhaps, but as the Configure context menu is more widely adopted, that will become where users go to for turning features on. I released some preliminary changes for this feature. I took the approach of showing Project Facets properties page for all projects and handling conversion from there. I think that this will be far more intuitive than the Configure menu alternative. Basic conversion works already and I put in some very preliminary changes towards a "detectors" infrastructure. The basic idea is to let facet owners register a bit of code that will be called during the conversion process so that they can examine project contents and determine whether content of the project implies that the their facet should be enabled. I have one detector implemented already for the Java facet. It works both if the project is a java project (java nature is present) as well as if the project is a generic one (no java nature) but java source files are detected. In the second case, it will look inside the source files to detect package names and derive java source roots that should be configured. Much work still remains to be done on the detector infrastructure, but I wanted to put this out for people to experiment with and give feedback. Targeting this to WTP 3.2 release. (In reply to comment #7) > > Perhaps, but as the Configure context menu is more widely adopted, that will > become where users go to for turning features on. What's more, this is the place that in cross-projects we agreed to put such actions. This is where we (the platform) would tell people to look for such actions. While I don't know the extent of how much functionality you associate with your preference page, I do know that it should also be exposed in the Configure menu. Platform UI put it there at the behest of the many projects (that are not platform :-) and contribute to eclipse (hence the cross project discussion). Please make sure you honour the convention in new functionality that you expose here. PW Paul, Thanks for your feedback, but it doesn't sound to me like you are familiar with the facets technology. The reference to the Configure menu in this bug is in connection to the way of making a project "faceted", which in turn allows functionality (in the form of facets) to be added/removed/managed via the facets property page. Since the direct interaction point for facets is the property page, I see sub-par usability in requiring users to find a menu item under Configure context menu upon discovering that the Project Facets properties page is missing on a given project. Further, I see the Configure menu as a temporary solution utilized by projects that haven't yet adopted facets. With facets, there is no need for projects to create custom actions and wizards for enabling features. And there is no need to find place in the UI to anchor those actions. My prediction is that the Configure menu will experience some near term growth before reversing and disappearing completely from lack of use. :) (In reply to comment #11) > Paul, > > Thanks for your feedback, but it doesn't sound to me like you are familiar with > the facets technology. The reference to the Configure menu in this bug is in > connection to the way of making a project "faceted", which in turn allows > functionality (in the form of facets) to be added/removed/managed via the > facets property page. Since the direct interaction point for facets is the > property page, I see sub-par usability in requiring users to find a menu item > under Configure context menu upon discovering that the Project Facets > properties page is missing on a given project. It's a convention to be used by WTP, or if you think WTP should opt out you should bring it up with your PMC and we can discuss on the Cross Projects list ... I never said there was anything wrong with allowing it to be added from the property pages, but it should also appear in the Configure menu (unless you can state WTP is opting out of this). i.e. I would look for something like: "Configure>Enable Facets" menu item and would never look at existing property pages to add new functionality. From a UI usability point of view, one property page doesn't usually create new ones (although I might have this incorrect. Susan, do we have an example?). PW (In reply to comment #11) > My prediction is that the Configure menu will experience some near term growth > before reversing and disappearing completely from lack of use. :) We're using the Configure menu elsewhere in WTP (JSDT, and ideally Java EE as well), so don't expect it to go away. > i.e. I would look for something like: "Configure>Enable Facets" menu item and
> would never look at existing property pages to add new functionality.
I still get a feeling that you aren't quite connecting with what this bugzilla
entry is all about.
Project facets have been managed from project properties page for many releases
now. The original implementation, many years ago, did not use a properties
page. Instead, it used a context menu action that would bring up a wizard.
There was a lot of arguing about that and in the end we settled on the project
properties page instead. Haven't heard any complaints about that since. If any
party at this stage feels that we ought to make this also accessible via the
new Configure menu, then I am certainly open to code contributions.
Now, getting back on topic of this bug... This is not about enabling individual
facets via the Configure menu. This is about enabling the use of the facets
framework on a project. Once again, if someone wants to make a contribution of
"Configure->Convert Project to Faceted Form" action, that does the same thing
as already possible via the properties page directly, then I will certainly
consider such a contribution.
Should this or bug 168538 be marked as a dupe of the other? *** Bug 168538 has been marked as a duplicate of this bug. *** (In reply to comment #14) > Now, getting back on topic of this bug... This is not about enabling individual > facets via the Configure menu. This is about enabling the use of the facets > framework on a project. Once again, if someone wants to make a contribution of Correct, the Configure menu would not be used to enable specific facets. It is a mechanism to add something "new" (most commonly) to a projects nature. i.e. make a java project a PDE project as well, upgrade a plain project to java project. Mostly "conversion" actions. It seems to me that "allow this project to use facets" is exactly what is supposed to go in the Configure menu. > "Configure->Convert Project to Faceted Form" action, that does the same thing > as already possible via the properties page directly, then I will certainly > consider such a contribution. It's functionality that (assuming Facets are still part of WTP) you need to provide with this feature. We don't provide a cohesive platform at eclipse by randomly ignoring conventions. PW (In reply to comment #12) > It's a convention to be used by WTP, or if you think WTP should opt out you > should bring it up with your PMC and we can discuss on the Cross Projects list > ... I never said there was anything wrong with allowing it to be added from the > property pages, but it should also appear in the Configure menu (unless you can > state WTP is opting out of this). > > i.e. I would look for something like: "Configure>Enable Facets" menu item and > would never look at existing property pages to add new functionality. > > From a UI usability point of view, one property page doesn't usually create new > ones (although I might have this incorrect. Susan, do we have an example?). > > PW I haven't noticed any property pages that are contributed solely to activate other property pages. This might be a good solution for a general "enable any nature" property page, but it feels a bit odd to do this for one particular nature. But one could argue that facets is trying to push the envelope for a general solution, and that the user reaction to this design will help move us to a better general solution going forward. The idea can be battle-tested in facets and possibly made more generic later. I would suggest following the convention used when enabling project vs. workspace specific settings. A simple checkbox at the top that enables the rest of a page (maybe you are already doing this). That being said...it is ironic that a project whose purpose is to design discoverability of project function from the ground up does not wish to participate in the existing Eclipse convention for discovering project function. If the issue is that there is no appropriate, default configuration for facets at a generic level, this menu could bring up a dialog explaining facets and offering to take you to the properties page. Just to chime in here. I've no objections in having 2 ways to achieve the same thing. Providing both methods invoke the same code (and have the same error feedback and quality as each other). Having a "Perform Project Facet Enablement" function on a "Configure" menu implies there should also be an "Unconfigure" menu to do the opposite! But I bet lazy contributers don't think about that kind of thing and so the 10,000 foot view of overall quality of Eclipse the product diminishes. "Facet Disablement" which is something that at the moment is not possible, as enablement is a one-way process (that the user is never warned about it being irreversible as well!). I'm not sure there is a call for it. But I am all for "completeness" and putting control and power in the hands of the developer/user of Eclipse. So there should be a disablement if you are going to have an enablement. :) Otherwise the Eclipse user enters the one-way maze that is "Eclipse IDE". Well thats one possible perception (be careful not to step on a mine while you try to figure your way out!) I would have objection to removing the Property Page way (as I could not care less about this right click Configure action, to me this is an unscalable solution that works well for maybe 30 things and then starts to looks ugly and a bad idea). So I guess then you have a "Configure..." dialog box. Ha! Maybe you should have a "Configure stuff on project" page in side your scalable and hierarchical Project Preference pages ? You can even have a button that lists all possible contributers actions but greys out those ones which the contributor decided was not possible on this project. That is a pet-peave with Configure menus (or the concept of right click actions), it simply removes all the things you can not do and leaves you a list of things it can. But due to bugs in Eclipse you can not even see what it is possible to do (or you think/know it should be possible to do) but because you can't see it you don't know. Where-as a "Configure Stuff" page in the project preferences would have a list of everything which by default is filtered by those actions that are possible. Then we are only one checkbox away listing everything :) even if they are greyed out. Just to clarify, property pages are not being "added". The facet page is a single page. It is just the main area of the page (after this bug is resolved) would now toggles between 2 states: * An information/help page, that explain what facets subsystem is or why this project can not used the facet subsystem, which a button action on it to perform the "Project Facet Subsystem Enablement" process. This edits .project and such and refreshes the project/IDE as necessary. * The current facet view/modify page (we all know and love) that allows us to view/add/modify/remove individual facet attributes on that project. This is only possible of the "Facet Subsystem" has been enabled on the project. Before this bug the first page/state did not exist. Also there was no action a user could perform to make the 2nd page exist/appear, if the project was not _ALREADY_ facet enabled already (and for that to happen _EVERY_ Wizard writer must be all trained up on "facets" to have initialized it from their wizard, i.e. the facet system was forcing all wizard writers to re-write their wizard just because facets came along, fine for long-term view, bad for the next release, or as it happens the next 3 releases). The only method was to manually edit project configure file(s). > That being said...it is ironic that a project whose purpose is to design
> discoverability of project function from the ground up does not wish to
> participate in the existing Eclipse convention for discovering project
> function. If the issue is that there is no appropriate, default configuration
> for facets at a generic level, this menu could bring up a dialog explaining
> facets and offering to take you to the properties page.
To be very clear, I do not oppose a secondary way of converting the project to faceted form via the Configure menu. At the same time, given limited resources, I chose in-place enablement in the facets property page as being most useful to users. If someone feels strongly that I am wrong on this, I would welcome a patch. Heck, if I see evidence of strong use of the Configure menu and users remarking that they didn't find this functionality there, I would probably be inclined to look into that myself...
(In reply to comment #20) > To be very clear, I do not oppose a secondary way of converting the project to > faceted form via the Configure menu. At the same time, given limited resources, We all have limited resources, but that doesn't make it a good idea to ignore these guidelines and conventions ... which according to this bug report was mentioned within 2 days of the bug being entered. PW We get that you weren't interested in doing this in the first place and still aren't :-) But it's a convention, and it's important to be good eclipse citizens unless there's a really good reason not to. You can ask your PMC if it's important in this case to follow the convention or if they want to opt out. PW Paul, I am a somewhat tickled by your comments and the implication that there is central control at Eclipse that can compel any committer to do anything. There are methods to prevent a committer from doing something, but not the inverse. That would require a salary or a consulting fee. ;) I heard your argument that it's a convention. I don't disagree with you in principle. If you'd like, I will open an enhancement request to that effect. As with other items, I cannot promise when it will be looked at. If it is that important to you, you know the path that you must follow. I was honestly more on the fence about this before you started to suggest that I must do it this way because of some convention that I was not a party to. Maybe I will cool-off and reconsider your request at some point... (In reply to comment #23) > Paul, > > I am a somewhat tickled by your comments and the implication that there is > central control at Eclipse that can compel any committer to do anything. I might be mistaken about how different PMCs run their project ... they are the central authority for a given project and *can* request that you focus your energies for the good of the project ... maybe yours doesn't. > I was honestly more on the fence about this before you started to suggest that > I must do it this way because of some convention that I was not a party to. > Maybe I will cool-off and reconsider your request at some point... You're right about one thing and wrong about one thing. Right: while we will continue to harangue you, we cannot make you do anything. Wrong: you are a party to these conventions because your PMC is. Feel free to follow the cross-project list, bring comments to your PMC if you disagree with some of them, etc (that's the process). PW Enhancement entered: Bug 300182 PW I am going to close this is as completed. The baseline has been established. Further work will be tracked by separate bugs. |
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18 Build Identifier: E3.5.1 Please ensure the Project preferences page for "Project Facets" is always available (to all projects at all times). However... if the project is not a faceted project (i.e. there is no builder and nature setup in .project file) then the ONLY thing on the page should be an explanation about what Project Faceting is with a button to enable it on this project. If the project already enabled to be faceted then the current facet settings page appears as normal. I also think that there should be a repair "Repair Project Settings" button too, i.e. at the left hand side (inline with the Revers/Apply buttons). When the project preference page is first loaded a quick "installation check" is performed, which basically re-checks the necessary builder/nature are installed (and in the correct order, in relation to other builders/nature, if order is important). If they are found to be correctly in place the button is greyed out, if a discrepancy is found the button is active. Marked "Major" as this is a regression, there used to be a Project right click action to setup/enable faceted project on any project. In 3.5.1 is does not appear which is the main reason for this bug "Not possible to Enable an arbitrary project as a Faceted Project from UI". However (IMHO) there is already a lot of clutter on the right click project actions and why have 2 different (and therefore confusing to a new user) places to configure/setup facets. Which is why I only suggest to use the project preferences page to also allow the user to setup things. It is not like it is a "common" thing to do that is deserves a right click action. The workaround for anyone else is to either shutdown Eclipse or Close the affected project. Then edit the ".project" file to add the following 2 items in the appropriate places. <projectDescription> <!--- ...SNIPPED... --> <buildSpec> <buildCommand> <name>org.eclipse.wst.common.project.facet.core.builder</name> <arguments> </arguments> </buildCommand> <!--- ...SNIPPED... --> </buildSpec> <natures> <!--- ...SNIPPED... --> <nature>org.eclipse.wst.common.project.facet.core.nature</nature> </natures> </projectDescription> Reproducible: Always