Community
Participate
Working Groups
Currently we add the ant tasks via the New Wizard. However, this is really just adding some code to the project so it is more consistent to treat this as a facet. BTW - It might also make sense to treat adding the UDDI Test Registry as a Facet. The reason I say this is that any one-time action on a project, like installing code, is what facets are for. Facets also have an uninstall action and handle versions well.
It's a bit of a stretch to say we're installing code. We're just dropping a couple prototypical ".properties" files a wee Ant XML file into the project. The tasks themselves are part of the platform and don't get copied into the target project at all. I'm not against the use of facets, but I'm also not sure the overhead of a facet is warranted for an operation as tiny as the one the current wizard executes, and I certainly have not thought about this enough to understand the ramifications to usability. I'd be happy to discuss this further.
Chris, A build script is code. But even if it was just a data file, I'd make the same argument. The New Wizard should be used for creating application artifacts. You should be able to run a New wizard many times and create different artifacts. On the other hand, a facet is really just some type of configuration operation on a project. You can install the facet and uninstall it. I like the ability to undo any configuration operation. There is no Unnew wizard :-)
BTW, I'm now sure what you mean by "overhead" of a facet. Do you mean coding overhead or runtime overhead? I think a Facet extension is probably comparable to a New extension in terms of coding.
I was thinking "usability overhead". I've read, and don't totally disagree with, concerns over the number of facets to contend with and understand in our various project creation and facet wizards. I wouldn't want something simple like dumping our Web service properties/scripts into a project to get lost in the mix.
Assigned to you, Kathy. Thanks - CB.
No plan to implement this RFE given the current resource and priority.
Please verify the defect you originated with a recent WTP driver which could be found in: http://download.eclipse.org/webtools/downloads/ If defects in resolved state is not verified within a couple of weeks, the development team might verify and close the defect on the originator's behalf. Thank you for your attention!
Since you won't fix this, why do I need to verify it?
Comment #7 was a generic comment I added to all defects in resolved state. For defects in Resolved Wontfix state, it meant to say verify that it's ok to not fix it. Closing on behalf of the originator.
