Sachin, Excellent information. It would be nice if we didn't have to create a specific project type for OpenEJB but if we must, we'll do it. I do see in WTP 1.5.x that EJB 3.x is mentioned as an available option so I wonder if EE5 is available now. The facet idea is great as well because beyond the WTP server type, I really think the benefit of this plugin will be the value-add stuff that will need to be enabled for OpenEJB projects. (I use the term project but I mean any WTP EJB project that has an OpenEJB server type as the project runtime.) Since this information is defined in the serverdef, do you have any insight as to the other portions as well? (start, stop, classpath, launch and so on) I have some ideas but the more minds involved the better.
Take care, Jeremy On 2/14/07, Sachin Patel <[EMAIL PROTECTED]> wrote:
Great! So I think using the Generic Server Framework to start is definitely the way to go as I see your serverdef file. This approach will also help expose areas that the Generic Server Framework doesn't work for openejb and help determine the areas need to be overridden for now and re-implemented when the plugins are converted to a full blown implementation. So basically I think the next step trying to enable a simple scenario. (1) creating an openejb project. (wether that is a stand-alone new project type, or an extension to WTP's ejbproject). (2) The ability to apply the openejb runtime to the project. (3) The ability to define an openejb server. (4) The ability to deploy the openejb project to the server. So from looking at your extension points, you can probably already define an openejb runtime and server. So question 1 is: Are you planning to support this runtime on WTP's existing ejb project or any POJO project? If WTP's existing ejb project, keep in mind that the released version of WTP does not have any EE5 support so the ejb.jar xml file that will get generated will be a 1.4 deployment descriptor. You may want to check if the ability to create EE5 projects has been added to WTP 2.0 yet. You'll also may consider providing a openejb facet that is preselected if the openejb runtime is chosen, this facet can then prompt for any openejb specific information during the project creation wizard and also generate any openejb specific artifacts like the openejb-jar.xml file. For (4), then the key coding piece will be the deployer. More advanced adapters have the ability to deploy projects to a given server as-is, so there is only one copy of a given resource and the server is running the project directly from the project workspace. But for now, the deployer can just export as part of the deploy operation a jar file and then run the deploy class Dain pointed to invoke the deployment. -sachin On Feb 14, 2007, at 12:55 AM, Jeremy Whitlock wrote: > Hi All, > Thanks to David we now have a wiki page. I have just updated it > with a > little more information. To make getting involved easier, lets get > a list > of resources: > > Wiki: http://cwiki.apache.org/confluence/display/OPENEJB/Eclipse > +Plugin > Email: [email protected] > Source: > http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb- > eclipse > > By the time you get this, you should see that I have made an > initial code > contribution. This is just a starting point that, when ran, allows > you to > see OpenEJB as a Server Type and you can see where the user > interface is > going with regard to configuration. I have been using the > presentation > slides for EclipseCon to get to where I am now. It is nothing more > than a > starting point and I encourage you all to begin communicating about > the > project's development and feature set on the mailing list. Now > that we have > the collaboration resources publicly available and there is an initial > contribution, although minimal, we are ready to get this thing going. > Please post all communication about this plugin's development on > this list > which happens to be mentioned above in the "Email" item. > > Take care, > > Jeremy
