Thanks for the feedback Naci, all good point/concerns. An explanation of the "ejb.dev.mode" group (which I made up on the fly as I was writing the doc, so good chance it's not quite right...)
It starts from the premise that use of xdoclet should be user selectable, and that (as you guessed) ISV's should be able to plug in alternative ejb codegen tooling options. The WTP ejb wizard could have a checkbox for xdoclet on the first/only page. But then ISVs are faced with either implementing their own separate EJB wizard (i.e. WTP's wizard only supports xdoclet), or extending the first page of WTP's EJB wizard in an arbitrary way. Thus I think the facet selection page, coupled with presets, is good way to offer extensibility and UI consistency. So if you agree that there should be a "jst.ejb.xdoclet" facet, then what does the base "jst.ejb" facet represent? * project can be "contained" in an EAR project, e.g. should be available in the "EAR Modules" properties page. * project shows up in the "EJB Projects" folder in the Project Wizard. * project can be added to a server that supports standalone EJB deployment. * javax.ejb.* interfaces will be on the project classpath The issue is whether the jst.ejb facet also implies there is a user-editable, source-controllable META-INF/ejb-jar.xml file in the project. Given that xdoclet and other DD generating utilities don't want/need there to be one, this needs to be factored out of jst.ejb, thus the "jst.ejb.default" facet whose job is to lay down a stubbed out META-INF/ejb-jar.xml file. The "ejb.dev.mode" group is simply a way to force the user to select only one of "jst.ejb.default" or "jst.ejb.xdoclet" or any ISV defined alternative that adds itself to the group. It should be noted that this design leaves open the possibility that the user can select NONE of ejb.dev.mode facets, and if they do so, then they basically have a do-it-yourself empty java project marked as something that will build into an ejb module. With regards to the concern that there are "too many facets". Presets are the best response we could come up with. They are intended to aggregate a functional group of facet settings. We probably would want to define at least a "Default EJB" preset, which is the default used by the WTP EJB wizard, and preselects "jst.ejb" and "jst.ejb.default". I disagree with the opinion that the user should be sheltered from seeing too many facets. As with other software installers, you make available "Recommended/Default" configurations (Presets), while also making available "Custom" installs (the visibility and control of the facet selection panel). That said there needs to be good judgement as to what should be represented as a facet vs. what is just a configuration option of a facet. Other comments: * The Web and EJB pages facet selection pages should be optional in the sense that I should be able to click Finish after the first page. The first time I run the wizard, I may want/need to click through the pages to make sure my preferred defaults are selected, but subsequently, if I want to replicate the previous project, I should only need to fill out the first page. Even for the App Client and Connnector wizards which really don't have any additional facets (that I know of), I think the facet UI is useful because it provides a consistent way to select java and j2ee spec versions. * Disclaimer: there's a known hole in the WTP 1.0 facet framework - there is no formal way for facets to "override" other facet implementations, either via subsuming their UI or overriding their installers. This is something we should try to address post-1.0. * We could have "jst.web" servlet version number imply support for particular versions of JSP and JSTL. Seems possible there could be users, tooling, and/or server impls that make use of explict version numbers for these, but I don't have a strong opinion, or good use case, either way. -Ted [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Naci Dai Sent: Saturday, November 05, 2005 1:24 AM To: General discussion of project-wide or architectural issues. Subject: Re: [wtp-dev] WTP 1.0 project facets I would to keep the number of standard facets to a minimal, easy to understand set. I am concerned about the potential abuse of the facet concept every time we think we have something a little different. For example, I could not understand all the ejb.modes they either need more explanation for me to understand what they mean or a clearer design; What is a development mode (jst.ejb.default, ejb.dev.mode)? I am assuming it is not a mode to distinguish runtime/development but xdoclet/vs another method for ejbs (i.e. beehive). It also seems the facets are one-dimensional (i.e. xdoclet for web/ejb will require two facets is this correct). Along that line of thought, why should jstl need an additional facet, should it be default capability with jst.web facet with proper version. Struts on the other hand can have a facet (as it is not a standard technology), but as Arthur pointed out, it is outside our scope. Finally, the concept of a facet is not much different than eclipse base project natures (now that we do not have multiple modules/project). Like the natures and from a usability point-of-view, they should not be something that is exposed to users freely in all tools. Facets are too abstract for a user (compared to a server or an html file). Most users will not care what facets are for as long as the tools do the work for them. If this is what we mean by presets, I am all for it. Maybe, facet pages of the wizards should be optional . I guess what I am suggesting is facets should be an API level concept (as opposed to User tool level). We should take extra care when we add new ones, and expose them to the users when there is no need to do so. > First draft of a document describing the project facets that will be > in WTP 1.0 is available at > > http://www.eclipse.org/webtools/development/proposals/WtpProjectFacets.html > > > > TBD: > > · the ejb-related facets are just a proposal at this point > > · the Runtime Components list is incomplete, id strings may change > > · Presets will probably be added > > · no web service-related facets in there yet > > · should WTP 1.0 include facet ids for Struts, JSTL, … ? > > > > Also note that this is not a developer’s guide (e.g. no implement X > interface instructions). Needs to be written... > > > > Comments welcome. > > > > -Ted > > > > [EMAIL PROTECTED] > >------------------------------------------------------------------------ > >_______________________________________________ >wtp-dev mailing list >[email protected] >https://dev.eclipse.org/mailman/listinfo/wtp-dev > > -- Naci Dai, eteration a.s. Inonu cad. Sumer sok. Zitas D1-15 Kozyatagi, Istanbul 34742 +90 (533) 580 2393 (cell) +90 (216) 361 5434 (phone) +90 (216) 361 2034 (fax) http://www.eteration.com/ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
