Bugzilla – Full Text Bug Listing
| Summary: | Project Facets Framework | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | Ted Bashor <tbashor> | ||||||||||
| Component: | wst.common | Assignee: | Konstantin Komissarchik <konstantin> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P4 | CC: | david_williams, deboer, ed.burnette, gorkem.ercan, gunnar, john.arthorne, john.oshea, koinuma, manahan, Mike_Wilson, mlists, nmahajan, patmc, pombredanne, rsinha, tbashor, thatnitind, tyip, vbhadrir, yung-chang.chen | ||||||||||
| Version: | 1.5 | ||||||||||||
| Target Milestone: | 1.5 M5 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Ted Bashor
Changed Version field given new release numbering. This feature has been deferred to 1.0 due to scheduling constraints. I just noticed this proposal in the context of the discussion in bug 102527. I suspect it might be a bit late, but I have a couple of comments: 1) Use of the term "feature" for this proposal is a bit awkward. In purpose and implementation it looks very much like project natures, but at the component level. For this reason I suggest the term "component nature" rather than "component feature". For plugin developers already familiar with natures in Eclipse, it's intuitive to continue to think of them as natures, but at the component level. "feature" is already understood in Eclipse to mean a collection of related plugins (org.eclipse.update.core.IFeature), so there is further potential for confusion with this overloading of the terminology. 2) The proposed IFeature.activate() API is very worrisome. This goes very much against the lazy plugin loading principle in Eclipse. This looks like a ripe opportunity for performance problems in the future. At the very least, when considering a new plugin activation point, consider whether activation is *always* required, or whether some declarative rules could be added to the extension point schema to allow extensions to specify under what conditions they require activation. All of the items under "What will a feature do" are actions that only ever need running once. Eagerly activating *all* component features in *all* cases on startup is likely to cause unnecessary plugin activations for those features that only need to do work when first configured. The classic "requirement" for plugin activation mentioned in the document, installation of resource change listeners, is mistaken. JDT and others make use of the ISaveParticipant API to ensure their resource change listeners are fully caught up to changes when they become activated. See: http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html#2 Such eager activation protocol was carefully ommitted from the design of project natures for this reason. John, Thanks for your comments... 1. Pretty much all good terms are overloaded already. As it stands, this use of term "feature" is different enough from the PDE feature, that I doubt there would be actual user/developer confusion. In the discussions (on the wtp-dev mailing list) following the release of this version of the spec, an issue came up as to whether this should even be done on component level vs. project level. That's still up in the air. At the project level, this is kinda like nature++. When the platform-ui team proposed something similar in 2002, they called it "capabilities". That proposal didn't go anywhere and the term has since them be used in other contexts. 2. I definetely agree. My current thinking is that instead of having an IFeature interface at all, we switch to a delegate-based architecture. That is, feature author would get to provide delegates for any number of points that we provide. If the feature author provided a delegate for "activate", then the plugin would be loaded and the the activate delegate would be called. If no such delegate was provided, the plugin will not be loaded. 1. I agree all good terms are overloaded. The platform does a pretty good job of co-opting all the good words (resource, part, capability, adapter, etc) and leaving nothing for other plugins... I just thought that since one of the platform words was nicely applicable it was a good candidate for "reuse". I agree there likely won't be significant confusion with the install/update notion of features. 2. That sounds good. As long as plugin activation is based on some kind of "opt-in" by the feature writer, WTP can't be blamed for unneccessary activations. This kind of issue can seem minor at design time, but I have seen cases where a seemingly innocent plugin activation caused a chain of a hundred or more plugin activations, resulting in real performance/scalability problems. I skimmed through the wtp discussion and I echo the sentiment that pushing "project-like" function below the project level is a slippery slope, given that other project-level functions such as builders and Java classpaths don't currently work below the project level. I suspect what's really motivating this is the fact that Eclipse doesn't provide much help for organizing and browsing through large sets of projects. Some attempt was made in 3.1 to use working sets for this (in the JDT Package Explorer), but it was a partial fix at best. "project" is another one of those overloaded words and everyone has a different interpretation of what their granularity should be. Jumping into the discussion, and trying to understand a bit more the features... 1)On the name, I would vote for something like Component Nature, if I had a say :-). If this enhancement ever makes it to the platform someday, I think it would be a no no to have two Features. Component nature speaks to me right away, when feature is way too vague for me. Component Feature could be another approach. 2)If a project feature sits at the project level and becomes a nature + some extra metadata, I am not sure I understand why it could not just be that? Like John, my hunch is that it might be slippery to start creating something like a project within a project, and have to take on full control for what's happening then, and eventually have to replicated many of the platform services. I understand the specific J2EE needs to deal with each specific components type in a certain way, but one the other hand, if you were to address each component type separately (ie as a seperate but coordinated development effort) it would be likely that the chosen solution may be different, and you could end up with a set of natures and builders. This could lead to inflation of natures, but why would that be a bad thing? And builders -while each must have a unique id- can have arguments and point to the same class if needed, and like the ExternalToolBuilder even work in abstraction of a nature if needed. I may be missing the point completely, but I am trying to gently understand what makes WTP so unique that the platforms services for natures and builders would not good enough. The current spec is a bit dated with respect to current thinking, I am working on updating it... The notion of the flexible project model and multiple components is independent of the features infrastructure. The reason that the current spec associates features with components is that if multiple components are allowed per project, they should have a separate set of features. There are a variety of technical reasons why features are not natures + something else. I will cover that in more detail in the next draft of the spec. I view (and I belive I am on the same page as the platform team on this) natures as an implementation detail. Similar to builders, they are not something that the user should ever manipulate directly. Features on the other hand are designed specifically for that. They are visible to the user. The user can add and remove them. Feature installation logic can add any number of natures, any number of builders, manipulate classpath, etc. Konstantin, in reply to comment #7: I believe also that natures should have been as an implementation detail, never presnet in the UI. But today they have been exposed and widely exposed be it by the PDE itself, which is now the cornerstone of RCP development, not only for IDE developers anymore, and by many project inside and outside of Eclispe.org. So they are de-facto visible to the users. The Spring IDE plug-in offers a command to "Add/Remove Spring Project Nature", AJDT to " Convert to an AspectJ project" , PDE to "Convert Projects to Plugin projects" and many more. But I like the idea of features as a way to group several project related transforms together, be they nature related or not, and expose that in the UI at that level. Some 2cents comments on the updated proposal: http://eclipse.org/webtools/development/proposals/Component_Feature_Proposal.html In the intro your write about features vs natures. ># Features are designed to be added and removed by the end user, >while natures are an implementation detail. >A feature can, if necessary, add a nature to the project as part of >it's installation logic. Not all features will use natures. I think that is calls for a generic project refactoring approach. Your features can be orthogonal to natures. ># Features can be versioned. That is something that could be seen as very specific to WTP, but may be not. If you look at language compliance, (ie take Java 1.3, 1.4, 5, 6 and else) it is becoming very messy out there. And being able to associate a some version with some project attribute may have larger applications. It has been dealt so far outside of natures. But why would that be different from natureid.1 and natureid.2 ? ># Features support a richer constraint expression language >than natures. The constraints expression language should be platform provided imho. ># It would be difficult to add additional lifecycle event >methods to the IProjectNature interface, >because doing so will break all of the existing implementations. I am not buying that. There could be an IProjectNature2 interface and a similar delegate approach could be implemented in the platfom. The platform team has been fairly good at providing adapters and keep upward compatibility so far. But then again, if you consider a concept of project refactoring, nature become just an implementation detail. A project does not require any nature to exist, like your features do not require natures. And repeating myself, you may end-up taking over a big chunk of what projects and natures are supposed to do. >This makes it very easy to add support for new lifecycle events >without effecting existing code. This to me calls for support of lifecycle events at the platform level. ># The IProjectNature's configure and deconfigure methods >do not take any parameters. >This makes them of limited use in situations where input >from UI needs to be taken into account and has resulted in a situation >where most of the necessary work happens in the wizards. 100% right. And that may call for some IProjectNature2 ? Or a declarative way to execute project refactorings, and some simple extension implementation to extend add/remove natures, so an implementer would not have to know HOW to add or remove a certain pre-existing contributed nature. >This makes it quite difficult for someone to say add java >functionality to a project at the API level. In the case of Java, that could call for the JDT team to offer such an API. Which could be vastly made easier if project refactoring had platform support. Or support for wizards level chaining, rather than page level chaining to re-use existing wizard. See below. >The features framework addresses this problem by allowing >the install and uninstall delegates to take a configuration object. >The configuration object can either be filled out by the UI >or someone working at the API level. I see that your <extension point="...ui.wizard"> deals with Wizard pages, things that have never been exposed in an extension before AFAICT. That seems a bit dangerous to me, (but at least a workaround to Bug 72211 ;-) ) . Especially a page in itself is not supposed to do much IMHO, but the wizard itself should do the grunt work in it's performFinish() While I like the ability to chain wizard and pass object between them, making it at a wizard page level makes it very specific to you feature aprpoach an probably hard to reuse in the platform. So I assume that the performFinsh of your one wizard will invoke the delegate for a feature/version? The issue I have with pages is that you could not re-use existing wizards. Case in point: the flexible Java creation wizard should be able to reuse the Java project creation wizard, which it does not today. Dealing with wizard pages is IMHO too granular and restricts re-use of available wizards. Now just a last comment: I am still not sure I understand why you could not re-use natures. But WTP is an important project and IMHO, if natures are not enough for WTP, there must be good reasons, then that could mean that natures are broken and either need extension or re-work. This should be platform business, I guess. I definetely think that the features framework could be useful outside wtp and we have talked to a few people in the platform team about this, but at this point there is limited interest. It's not so much that project natures absolutely could not be changed to support requirements outlined in the features spec, but that doing so would be sufficienly painful while trying to maintain backwards compatibility that perhaps it's best to leave natures alone and create a standalone feature construct. There are several benefits gained from explicitly versioning features: (1) the feature selection ui can be optimized by showing just one list entry for every feature vs. a list entry for every version, (2) it's possible to express that feature Av1 requires feature Bv2 or newer, (3) it's possible to associate upgrade logic with user changing the version of an already installed feature instead of just treating it as uninstall followed by install. The point about the difficulty in creating a java project at the api level would not really be addressed by having the JDT team provide some api, because that still requires the user to know about that api. I will argue that what the user really wants to do is say addFeature( "java", "5.0", config ) and have whatever is necessary happen. I am not quite understanding the root of your apprehension over using wizard pages in the extension points. Wizard is pages + performFinish. This doesn't fit with the framework because the whole point is that all the logic should be encapsulted in the install delegates. The project wizard should just run through the feature pages, gather up the state, and call addFeatures method. At that point the framework would call the necessary install delegates. I think you are wrong about the feasability of just chaining existing wizards together. The first problem you will run into is that they are all "project creation" wizards so each one will want to create a project from scratch. For instance, the PDE project wizard creates a project, sets up java nature / classpath, and finally sets up the PDE-related stuff. In order to get this to work in an incremental fashion, you would have to pull out just the PDE- related stuff from both the ui and the performFinish logic. I have some comments on the new proposal: Feature versioning: Each feature is of course defined by some plugin, and that plugin has a version. Is the plugin version sufficient to express these relationships? For example, do you anticipate that a single plugin version might define multiple versions of the same feature? Relying on plugin versions would avoid the need to implement a similar constraint satisfaction system for features (which is not easy). Soft pre-reqs: Consider calling the attribute "optional=true" rather than "soft=true" to match the syntax of plugin pre-requisites. I have no compelling reason other than using terms consistent with the platform. Your syntax for match rules could also use the richer match rules used by plugin pre-reqs (perfect, equivalent, compatible, greaterOrEqual). Feature constraints: These are very close to nature constraint rules. This is one place where it would be nice to take advantage of the existent nature mechanism rather than duplicating it. Otherwise, for those features that do have a corresponding nature, each plugin defining a feature/nature pair would presumably have to duplicate the constraint rules in each. The two things missing from nature constraints are the "or" construct and the "version" contraint. I would be curious to hear a use case for the "or" constraint, since it is not common in expressions of prerequisites. If the nature constraints were sufficient (and they can be improved in 3.2 if necessary), that would avoid some complication at the feature level (a feature would just specify that it requires a particular nature, and the nature constraints would take care of the rest). Consider defining categories as a separate element from features. I.e., instead of a feature knowing what category it belongs to, have the category define what features it contains. This allows the aggregation of features to happen at a higher level in a separate plugin. From the perspective of the plugin defining individual features, it his hard to see what granularity of aggregation will be needed. As a contrived example, say someone creates a plugin that adds some additional JSP functionality. That plugin writer might decide that their feature should belong to a "JSP" feature category. However, someone building a large product containing thousands of plugins might have a different perspective and decide to put that feature in a more general "J2EE" or "Web" category. This is the approach taken by capabilities in the platform, which separate elements for "activities", "categories", and "activity-category bindings". It's more complicated, but more powerful. One thing I could not find in the proposal is whether the association between a feature and a project is persisted somewhere. I.e., after a feature is configured on a project, is there any way for someone to query for its existence? If so, where is that association stored? Consider the case where a feature is configured on a project, the project is released to a repository, and another user then loads the project. Does the second user still have that feature on that project? John, Thanks for your comments. 1. I don't believe the plugin version is sufficient for our purposes. We certainly anticipate that there will be multiple versions of the same feature loaded from the same plugin, but more importantly each plugin might contain multiple different features, each with their own versions and their own separate constraints. 2. Term consistency is definetely good. we should look into aligning terms such "optional" vs. "soft", etc. 3. The feature constraints are definitely very close to nature constraints, but nature constraints and how they are enforced are not sufficient for our purposes. The "version" part is very important and so is the "or" constraint. Here is an example of what we need to be able to express: "beehive controls 1.0 requires web 1.4+ or ejb 1.4+". The feature constraints are enforced when the features are installed. The natures constraints are enforced when the project is loaded. If there are conflicts, some natures loose and are not loaded. I believe that solves a usecase for where in a team environment, different people might have different plugins (with different natures) installed, but it's not a desired behavior for features. Also, there is no need to duplicate a feature's constraint onto the nature that's associated with the feature. 4. You have a good point about categories. We should look into that. 5. The features installed on a project are definetely persisted in the project directory. In your example, the second user would see features installed by the first. How they are persisted is an implementation detail that might change in the future. I'm missing something in this proposal. You are investing a lot effort in defining dependencies between some abstract features including versioning etc. But all this requires the end user to know, which features/bundles/plugin someone has to install to resolve the dependencies. I think the proposal should go deeper. If someone imports a project he want to contribute to or develop on Eclipse should determine that some plugins/features/bundles are missing for an acceptable development experience (for example, some 3rd party code generator plug-ins like Hibernate or JavaCC). Eclipse should offer the user to download and install these plug-ins. I've opened bug 106281 to track this. Theme: Simple to Use;Enterprise Ready I have updated the website with a refreshed version, that Konstantin has contributed. But the name of the file changed, so the URL is slightly different. See http://www.eclipse.org/webtools/development/proposals/index.html or http://www.eclipse.org/webtools/development/proposals/Features%20Framework%20Specification.htm I have a request and a suggestion. As I read the document, it didn't seem to have many "uses cases" ... "from the users point of view". It was pretty abstract. I think I'd understand better if you could give a page or so of a simple examples, perferably the one planned to be implemented in WTP. (e.g. struts would not be appropriate in WTP ... what would be?) I think in our conversations, I was convinced with the "Struts example" (adding, removing, different versions of struts). but 1) would want to understand better what's expected to happend during all those lifecycle stages ... change classpath?, add libraries from somewhere? change UI? Reorganizte projects? Where's the limit? As for a suggestion ... that 'feature' name is REAL confusing ... especially since some other life cycle terms are real similar to OSGI bundles. (They really are not related, right?) So ... I have three candidates ... aspect (as in "project aspect", "the aspect of the project") .... or 'facet' .... or 'flavor'. I like the last one the best ... but admit I am kind of hungry while I'm typing this. Thanks much. Created attachment 26737 [details] Redirecting Page It looks like the old URL (http://www.eclipse.org/webtools/development/proposals/Component_Feature_Proposal.html) is still accessible and it brings up the old version of the spec. I am attaching a redirect page that should replace it. There is no need to preserve the old version. I applied to website the re-direct fix in comment 16. Works fine. Though could use a flaming logo :) *** Bug 94610 has been marked as a duplicate of this bug. *** Created attachment 26782 [details]
Framework + Base Features 20050901
The attached zip contains BEA's contribution of the spec implementation. The
implementation is mostly complete with a notable exception of the runtime
integration. The contribution also contains full working implementations of the
following features: java 1.3/1.4/5.0, wtp.framework 1.0, web 2.2/2.3/2.4, ear
1.2/1.3/1.4, and utility 1.0. There are also three new project wizards built
with this framework (ear, web, and utility). They are located under the "Web
Tools (New)" category.
Notes:
1. Due to the current lack of the runtime integration, the wtp.framework
feature associates the project with the default runtime for the workspace.
Therefore, to get the correct behavior make sure that you have at least one
runtime created and that it is designated as default in workspace preferences.
2. The ui rendering of fixed features in bold in the features selection panel
is temporary until we have time to devise a prettier ui.
3. All features prefixed with "Sample" don't actually do anything. They are
there to demonstrate various facilities provided by the framework, like
categories and presets.
Agree that the name "feature" is very confusing. My view: change it now, before the er... feature gets any more widely adopted. *** Bug 106781 has been marked as a duplicate of this bug. *** I also agree that the term "feature" will be too easily confused with its other well-established definition in Eclipse. I also agree with John that most good terms are overloaded. Rather than tax my own limited imagination, how about considering a few synonyms for "feature" or "capability" from an online thesaurus - something less spoken for in Eclipse already. Examples: aspect, facet, quality, trait, facility or capacity? There are two perspective to examine this terminology question from. The perspective of a plugin writer using the api and the perspective of a novice end user. All of us here fall into the first category and I admit that for plugin writers overloading the term feature without qualification is somewhat confusing. On the other hand, most people on the street have an intuitive understanding of what a "feature" is. It's self-describing in a way that it's synonyms are not. There are many analogs in the real world where people run into lists of things labeled "features". In some of the cases they even have a form with checkboxes to select the features that they want. The point that I am trying to make is that when a novice user goes to create a web project for the first time and sees a checkbox list labeled "features", they have an intuitive understanding of what is expected of them. I remember when I was new to Eclipse and I first ran into a term "nature". I had no idea what it represented until I poked around and found documentation. That was somewhat ok since end users don't run into that term and more is expected from plugin developers. I propose that instead of coming up with a different term we instead qualify the existing term "feature" and make it a "project feature". That has the advantage disambiguating things for plugin writers without hurting the novice user. I'll add my vote to change the term from "feature". Was having a discussion about eclipse installation related issues when this proposal caught our attention. We wasted about an hour and the time of one of the wtp developers understanding it had nothing to do with "real" features :-). The fact that the proposal makes use install terminology makes it even more confusing in the context of eclipse as "features" in eclipse are about installation. Created attachment 26963 [details]
Patch - 20050908
This patch contains api cleanup to make all api use collections, some
refactoring, and a few bug fixes.
Created attachment 27056 [details]
Patch - 20050912
This patch includes:
1. Support for version change delegates. Includes version change delegates for
the java, web, and ear features.
2. More checks for illegal actions, especially covering cases that are not
reachable through the UI.
3. Transitioned to using IStatus for reporting validation problems. The
ValidationProblem class is now a subclass of Status and has been made internal.
The api is all IStatus-based. Instead of returning a set of ValidationProblems,
a MultiStatus object is now returned.
4. Transitioned string resources handling to use the OSGI NLS utility.
5. Made a slight improvement to how version selection ui is rendered.
Are features combined into features? If so you could limit to one feature per plug-in, and since a feature can contain multiple plug-ins, a feature could support multiple features. I have a question about these patches - if I want to look at the most recent implementation, is it best to look at the contents of the projects in HEAD? I.e., are the patches being applied to HEAD regularly? I just want to make sure I'm looking at the most up to date implementation. The patches are regularly applied to HEAD. Currently, the 2005908 patch has been applied, but not the 20050912. I suggest "facet" instead of "feature" to avoid confusion. I'll suggest "project capabilities" for the list. I'll suggest "project attributes" Though I also like "virtue" and "ingredient" as well :-) I suggest "Characteristic" or "Project Characteristic" in the API, extension points etc for plugin developers. In all user UI, we can keep using the word "Feature": "Feature Preset", "Java Feature", "Web Feature" etc. I think both "characteristic" and "facet" are good suggestions. Although the two underlying 'feature' concepts are in no way related I'd agree with Konstatin - the suggested alternatives like 'aspect', 'facet', 'capability' do not as accureatly convey the same meaning to Joe User through the UI. As plugin devlopers we are more sensitive to the (new) overloading of the term than any regular end user will be. In fact, end users will look upon both types of features in the same way - both the application (platform) they are running and projects they hold their date in have "features" - it's just that the underlying mechanisms used to implement these features are completely different. For plugin developers, if the PDE documentation/UI consistently qualifies references to these types of features as "Project Feature"s and points out they shouldn't be confused with Eclipse features then I'd imagine we will adapt to the overloading quickly. (Remember Eclipse features were called 'components' in Eclipse 1.0, can you imagine if it hadn't been changed!) I feel I have to add a general comment on this bug and it relates to open issue #1 in the propsal - I agree completely with Philippe Ombredanne's observations in #9 that this (hmm, har to overload 'feature' again here) is really something that belongs to platform. I understand that WTP have the immediate requirement for managing project/component resource(.project, .classpath, .wtpmodules) consistentency with the workbench/workspace (supported builders, natures, servers, module types, versioning etc) but platform should be encouraged to take ownersip of these extension points at the earliest opportunity. If WTP needs this facility then they will be of benifit to other top level projects like DTP and BIRT as well as possible future projects like SOA Tools and JSF(if/while it remains outside WTP) - they just may not know it yet. Aside: I noticed one of the open issues in the proposal asks the question " Are features a property of a project or of a component?" I presume the answer is that are project related only? After the project features open house, members of the platform team had several rounds of discussion on this proposal. Here are some comments on the proposal that came out of those discussions. Our general concern is that the proposed features framework is trying to solve several different problems. On the surface, these problems seem to be strongly linked, but in reality they can be different problems, and a single mechanism is not likely to succeed at solving all of them. When a feature is attached to a project it could mean several things: 1) A particular tool or plugin is associated with that project. For example, a certain plugin has stored its metadata in that project. 2) A particular set of UI wizard pages need to be presented to the user in order to properly configure that project. 3) The project has particular compile-time characteristics. For example, the classpath is configured in a certain way, and various compilation prerequisites such as JARs are available to that project. 4) The project needs to be deployed to a runtime environment with certain characteristics. For example, the runtime has a particular JRE version, or is a J2EE server that supports struts, JSPs, etc. These four cross-cutting concerns kept popping up as we discussed the various parts of the feature framework. For example, if someone says that feature X requires feature Y, does it mean: 1) For a tool that supplies feature X to function properly, a tool that supplies feature Y must be present. 2) The UI configuration pages for Y must be shown to the user before the wizard pages for feature X. 3) Feature Y must add its classpath entries and builders before feature X adds its classpath entries and builders. 4) Feature X will only exist in the runtime environment if feature Y exists. Based on the demo, it seems that both 2) and 3) apply. However, it is not always true that these two go together. For example, PDE requires JDT, and must be configured after JDT has been configured. However, PDE chooses to hide most of the JDT project configuration pages in its project wizard. This is one of the points Mike was trying to make at the open house. There are two interesting cases when there is a dependency of one tool on another. In some cases, it is a simple ordering dependency and configuring one before the other will do the trick. In other cases, one is a hidden implementation detail of the other, and a feature may not want to expose to the user other features it depends on. Trying to drive the UI automatically based on this dependency information is not likely to be the right answer in many cases. We realize there are two general problems in the platform UI in this area right now: proliferation of specialized project wizards, and no UI for adding additional features to an existing project. We don't see a unified feature-based wizard solving the wizard proliferation problem, because it simply pushes the array of options one page deeper to the feature selection page. However, the idea of feature presets seems like a step in the right direction. Interestingly, if we solve the second problem of being able to add features after the fact, then the wizard proliferation problem becomes less significant. Ideally, these kinds of project transformations would happen implicitly rather than through a buried property page: adding a .java file to a C++ project would open a dialog or status line hint asking if you would like to add the "Java" feature to the project. If we were "smart" enough to add features on the fly as needed, you may only need a small set of "new project" wizards to facilitate the new user experience (acting as pre-canned groups of related features that satisfy common new user scenarios). In addition, it is important to note that the solution suggested with features simply is not consistent with the current approach of added new "New" wizards to solve this problem and while it may offer more, it is also not going to be consistent with what is around you and may only serve to confuse instead of help. Users expect things to work in a common way. Hiding features while still making use of them under the covers and still remaining consistent should be considered in the best interest of all users. We had a similar confusion when thinking about feature version numbers. To say that a feature has version X, it is not clear whether it means (I'm using the same numbering as above for consistency): 1) A particular version of a tool is associated with that project 3) A particular version of the compile-time libraries must exist 4) This project is destined for a runtime with a particular version. Based on what we saw in the demo, you intend for the version number to represent the runtime version (for example, Java 1.4 or 5.0). This is confusing because you also define a runtime extension point where runtimes also specify their version number. The relationship between the runtime version number and feature version number is fuzzy to us. In the proposal, you have feature "web" version "1.0". If "1.0" in this case is referring to a version of the tooling rather than runtimes, then that number won't make much sense to the user. If you imagine a product with dozens of features coming from different sources, they will all likely have different feature version numbers, none of which is likely to match the version number of the product familiar to the user. For example, the IBM IDE might be version 6, the BEA IDE version 10, but they both contain "web" version 1.0 and "java" version 3.1. In our view, we see a demand for version numbers in sense 1). For example, a project is created with version 3.0 of JDT, and JDT has attached certain metadata and preferences to the project that correspond to that version. Later, that project is imported into a product containing JDT 3.1. If the version information was encoded in the project, JDT would be able to perform the correct migration on its metadata for that project. However, if this is what the version number meant, it would certainly not be exposed to the user in the UI. Some of these comments may be due to our misunderstanding about what features are meant to be. If so, please clarify your intent where it doesn't match the descriptions above. Our current general feeling in the platform is that there are some interesting problems here that we would like to explore platform-level solutions to. However, we don't want to bog down your progress by trying to make the features framework solve all of these general problems in the short term. Thanks for taking the time to give this feedback! Let me try to clarify some misunderstandings. My appologies for not making it clear in the first place. Q: What does it mean for feature X to require feature Y? A: If feature X depends on feature Y, feature Y must be installed prior to installing X and Y cannot be uninstalled without first uninstalling X. As a consequence of that, if X and Y are installed together, the configuration pages for Y appear prior to configuration pages for X. Q: But what if feature X wanted to take over configuration of feature Y like PDE takes over configuration of JDT? A: We actually talked about providing a way for a feature to declare that it takes over configuration (UI) and perhaps installation of another feature. Adding support for this would not be all that difficult. At the moment we (WTP) don’t have any usecases for this, so we didn’t move further on that, but this can be added in the future. Q: What about project feature versions, what do they mean and why should they be visible to the user? A: A feature version represents the version of functionality that’s being added to the project. For instance, the java feature has versions 1.3, 1.4, and 5.0 to represent the compiler levels; the web and ear features have versions corresponding to the J2EE spec levels; someone might write a feature that adds a library to project classpath and use feature version to represent the version of the library. A user that’s going to select features (vs. a user who is going to be happy with a default) needs to be aware of versions and able to pick which version they want. Q: How does this interact with runtimes? A: Features and runtimes are linked by “supports” mappings. This enables the framework to understand which runtimes support which features and which features will work with which runtimes. A user can either pick a runtime, in which case their choice of features will be appropriately constrained or they can start selecting/deselecting features and watch the list of runtimes shrink and grow. Runtimes, just like features, are versioned, but those versions don’t represent the same thing (even I they happen to be the same string). In the case of java feature and various java runtimes, the version happen to line up, but that’s because the various JVM vendors have chosen to align their runtime versions with java language spec version. A better example would be the web feature, where web v2.3 might be supported by Tomcat v5.0, WebLogic v9.0, WebSphere v6.0, etc., while it might not be supported by Tomcat v1.0. Q: Why are you saying that this will do anything to address wizard proliferation? Doesn’t this just push the problem one screen further? A: The framework helps address the problem of wizard proliferation by avoiding the cross-product effect that surfaces when people try to create wizards for all different permutations of functionality. The framework is also a very powerful tool in allowing the users to put together projects composed of features from different vendors. This is something that’s not really possible today. Q: Shouldn’t transforms like these be done automatically? We could detect that .java files are added to a project that doesn’t have the java feature installed and install it. A: While I think that would be awesome and a great compliment to this framework, the cases that it will be possible to do this in are an exception rather than the rule. In most cases, the user will still have to make an explicit choice to add the functionality. Q: But this is not consistent with the current approach of adding more “New” wizards. This will just confuse the users. A: There is no question that this is new and different, but hopefully the users and the developers will enjoy the new flexibility. A terminology vote has been started on wtp-dev. I am re-posting it here in case not all of the people on the CC list are on wtp-dev. ====== -----Original Message----- From: wtp-dev-bounces@eclipse.org [mailto:wtp-dev-bounces@eclipse.org] On Behalf Of Konstantin Komissarchik Sent: Tuesday, September 20, 2005 3:30 PM To: General discussion of project-wide or architectural issues. Subject: RE: [wtp-dev] Please vote: "project feature" name As you vote consider both the perspective of the end user as well as the perspective of a plugin developer. Despite Ted's comment, having a different term for the ui from the one that's used in the api is unlikely to happen since that would create even more confusion. I would assume that the term that you are voting for will be used in both contexts. Having said that, consider whether the term will convey an intuitive meaning to someone who has never used wtp/eclipse before. Try using it in a sentence such as "Please select <term>s to install." or "<term> Struts 1.0 depends on <term> Web Module 2.4." - Konstantin -----Original Message----- From: wtp-dev-bounces@eclipse.org [mailto:wtp-dev-bounces@eclipse.org] On Behalf Of Ted Bashor Sent: Tuesday, September 20, 2005 2:28 PM To: wtp-dev@eclipse.org Subject: [wtp-dev] Please vote: "project feature" name Well it's primary day here in Washington State, and to share that democratic vibe, we're asking you to vote on your favorite class name for use in the "project features" api. If you haven't already, please take a look at the spec http://www.eclipse.org/webtools/development/proposals/Features%20Framewo rk%20Specification.htm as well as https://bugs.eclipse.org/bugs/show_bug.cgi?id=94608 and maybe even peruse and run the org.eclipse.wst.common.features.* plugins in in WTP's CVS common component repository. The candidate list is: ProjectAspect ProjectAttribute ProjectCapability ProjectCapacity ProjectCharacteristic ProjectFacet ProjectFacility ProjectFeature ProjectFlavor ProjectQuality ProjectTrait A couple points: 1) this is a vote for the api name for these things, the UI name *could* end up being different. 2) "Feature" and "Capability" are terms already used by the Eclipse platform, so voting for them means that you think the project qualifier is sufficient to avoid confusion. Please send me ( tbashor@bea.com ) your three favorites listed in preference order. Your first choice gets 3 votes, the second gets 2, and the last gets 1 vote. Voting is open for the next 24 hours. Thanks, Ted tbashor@bea.com I'd like to suggest two aspects of "good eclipe integration" be added to the proposal. 1. Unitified undo. The idea being that if a user picks a set of capabilities for the project, then changes their mind, they should, via undo, be able to simple undo that whole setting as one operation. Second, The project capabilities should be written to be sensitive to the workbench capabilities, for example, if they have choosen to at a work bennch level to "never work with EJB's" then they should never see those choices in their wizard choices. (Except, of course, there is another good-instegration-point of having a check box on the wizard that says "show all capabilities". +1 for "ProjectTrait" I know this has been discussed before but my vote is just to enhance project natures and use them for this, calling the whole thing "natures". It's an existing term that means almost the same thing already, and it's not overloaded up the whazoo. Plus I'd like to see natures extended anyway because I want to see a nice story about adding and changing project natures in the UI. For example I want to add a "mobile nature" to a project, a "javaforge nature", a "SAS nature", etc., that can optionally make changes in how you build or launch or deploy or source control things. And the winner is... ProjectFacet
Thanks to all who participated. Please double check that your vote is properly
recorded below.
ProjectFacet: 18
ProjectFeature: 10
ProjectCapability: 8
ProjectCharacteristic: 7
ProjectAttribute: 6
ProjectFlavor: 5
ProjectAspect: 4
ProjectFacility: 4
ProjectConfiguration: 3
ProjectFunction: 3
ProjectDomain: 2
ProjectTrait: 2
ProjectCapacity: 1
Arthur Ryman
1) ProjectFacet
2) ProjectFacility
3) ProjectCharacteristic
Jason Sholl
1) ProjectFunction
John Lanuti
1) ProjectFacet
2) ProjectFeature
3) ProjectCapacity
Jay Cagle
1) ProjectCapability
2) ProjectFeature
Mike Wilson
1) ProjectFacet
2) ProjectTrait
3) ProjectFlavor
Joan Haggarty
1) ProjectAspect
2) ProjectFacet
3) ProjectAttribute
Philip Avery
1) ProjectFacet
2) ProjectFacility
3) ProjectFlavor
Vijay Bhadriraju
1) ProjectConfiguration
2) ProjectDomain
Thomas Yip
1) ProjectCharacteristic
2) ProjectFlavor
3) ProjectFeature
Konstantin Komissarchik
1) ProjectFeature
2) ProjectFacet
3) ProjectAspect
David Williams
1) ProjectCapability
2) ProjectAttribute
3) ProjectFlavor
Craig Salter
1) ProjectCharacteristic
2) ProjectFacet
3) ProjectFeature
Ted Bashor
1) ProjectAttribute
2) ProjectCapability
3) ProjectFeature
I know this has been mentioned before, but I wanted to reiterate that the terminology of the API doesn't need to be surfaced in the UI. For example, menus and toolbars in Eclipse are driven by "Actions", but the word "action" generally doesn't appear anywhere. Workbench pages, parts, sites, markers, and many other terms don't surface either. For example, I could picture the wizard page where facets are chosen may just say something like "Choose the tools you would like to have available for this project", or just have a title like "Project Configuration". You may be surprised at how little of the API language in Eclipse needs to bubble up to the user level. I'd like to close this. We should be opening specific bugs from now on. This change is a bulk update of all _un_targeted, fixed, resolved bugs upon release of M5. This particular bug _might_ have been fixed earlier than M5. (Feel free to correct). verified against 1.0 release |