Community
Participate
Working Groups
1.5 RC1a There is no capability for the validation stuff. There should be a way to hide all validation property pages, preferences pages, builders and actions behind a capability so that adopters aren't forced to expose it in their products.
Gunnar, Validation cuts across all components. Capabilities are aligned with roles. I don't understand what you are proposing. Can you be more concrete? Thx.
I'm assigning this to Lawrence who set up the current capabilities.
Capabilities are not necessarily aligned with roles only. According to bug 134498 comment 1 they are also used to filter things in the UI. And that's what I'd like to achieve. I'd like to hide the validation preference pages, the validation property pages that appear even on simple projects, any validation actions in the UI and I don't want to have validation errors in the problems view. The thing is, that there is just to much for people start using WTP and everything is exposed by default. I'm comfortable with it but we deploying Eclipse within our company and it's interesting to see new developers being confused by the many features exposed by default. You have to adapt them one by one. ;)
I believe the intent of the comment is that you can filter out capabilities such as Java or Web development (your original comment stated that you did not want WTP in some workspaces), not specific tools or frameworks such as validation or URI resolution which, as Arthur pointed out, cut across components. You stated in your original comment, "There should be a way to hide all validation property pages, preferences pages, builders and actions behind a capability so that adopters aren't forced to expose it in their products." Adopters can define their own capabilities in their product and can filter the functionality in any way they'd like. I'd be happy to show you how to define your own capabilities. In comment #3 you stated, "I'd like to hide the validation preference pages, the validation property pages that appear even on simple projects, any validation actions in the UI and I don't want to have validation errors in the problems view." I'm surprised that you've focused on validation as a source of simplification in the WTP UI. (Have you focused on other tools/frameworks as well? Have you opened any other bugs?) Validation adds a single preference page to the global preferences and a single preference page to the project specific properties. Both of these preference pages are meant for advanced users and I wouldn't expect most new users to venture straight into the preferences. As an alternative, although I don't recommend it as validation is a sanity check on the validity of documents, how about disabling all the validators? Disabling the validators will prevent errors and warnings from being generated and displayed. And, because I'm curious and very interested in improving the out-of-box usability of WTP, can you shed some further light on what you've found confusing for new users with WTP's validation framework? (Or are you just trying to trim WTP down and think validation is something you can do without?)
(In reply to comment #4) > I'm surprised that you've focused on validation as a source of simplification > in the WTP UI. (Have you focused on other tools/frameworks as well? Have you > opened any other bugs?) Validation adds a single preference page to the global > preferences and a single preference page to the project specific properties. > Both of these preference pages are meant for advanced users and I wouldn't > expect most new users to venture straight into the preferences. Validation seems to be a piece of WTP that is not included in the existing capabilities. > As an alternative, although I don't recommend it as validation is a sanity > check on the validity of documents, how about disabling all the validators? > Disabling the validators will prevent errors and warnings from being generated > and displayed. That's true. But I try to keep the amount of setup tasks as a minimum. And in the past the validation component has had (and still have) some problems with disabling the validation. Bug 102882 Bug 134590 Bug 137056 Bug 138120 http://eclipselowdown.blogspot.com/2006/05/dont-speak-until-spoken-too.html > And, because I'm curious and very interested in improving the out-of-box > usability of WTP, can you shed some further light on what you've found > confusing for new users with WTP's validation framework? (Or are you just > trying to trim WTP down and think validation is something you can do without?) I think validation is an important part and very helpful if you are running in a very strict environment. However, we don't need it in our environment yet. I provide a customized IDE distribution based on Eclipse, WTP and some other nice plug-ins. I could successfully disable/hide some parts (eg., PDE, Team/CVS) by not including their features (PDE) and/or not enabling their capability or defining my own. (Because the Eclipse capabilities are defined in the SDK product and I excluded it.) With WTP it's a little bit different. WTP defines its capabilities and including a default enablement in its runtime features. Thus, someone would need to exclude the main runtime features. I don't like that because then I have to maintain the WTP plug-in dependencies myself and cannot just include the WTP runtime features.
>Validation seems to be a piece of WTP that is not included in the existing >capabilities. Validation and more specifically the validation framework is included as part of the XML Development capability. This is the lowest level WTP capability and is required by the rest of the WTP capabilities. The XML Development capability contains other WTP frameworks that cross components such as SSE and the common utilities. >And in the past the validation component has had (and still have) some problems >with disabling the validation. Bug 134590, bug 137056 and bug 138120 have been resolved and bug 102882 is only an issue when validation is enabled. As for the blogspot comment, I'd prefer to spend time fixing problems in the validation framework rather than work on ways to circumvent or disable it. >WTP defines its capabilities and including a default enablement in its runtime >features. Perhaps this is the real problem and something WTP needs to address for consistency with the plaform. Will removing the WTP capability definitions from the runtime component solve your problem?
(In reply to comment #6) > Perhaps this is the real problem and something WTP needs to address for > consistency with the plaform. Will removing the WTP capability definitions from > the runtime component solve your problem? Yes. :)
Chuck, who owns the capabilities for WTP?
John, I created the WTP capabilities so I guess that makes me the defacto owner although I haven't touched these definitions in quite some time. Care to take control of the capabilities?
All right, I'll take ownership here.
I think some similar bugs opened ... we'll try to sort them out in 3.0.
Helen, Lawrence, then Amy use to handle a bunch of our "capabilities" stuff ... are you interested?
I think this was essentially fixed in 3.1. If there's remaining issues, please open a new bug (or, repopen if I'm missing the point).
