Hi, looking at the different APIs which seem to be useful all the ways lead to TypePage. I believe to remember that there was a announcement on this list saying that it is available and will eventually promoted to the API (Unfortunately I don't have the mail anymore and can't go online to look for it). There was also a request for feedback. I am looking at it from the perspective to develop an EJBBuilder, which should build the bean types and create/update the deployement descriptor. I like the current implementation very much. I especially like the small things like finding the unimplemented methods. That would be very handy for the creation of the ejb bean class to provide stubs for all the lifecylce methods. This will keep the generation code clean and slick. It is also nice to reuse the source folder and package browser. Still there are some things which doesn't make it easy to be reused for the a.m. job (ejbbuilder). I do confess that I probably haven't looked close enough to make a valid statement. Extracting the data to a model as well as pulling out the generation code. Reuse would be much easier. For example: For an ejb is more than one type to be generated, leaving alone the dd. Having the model and controll logic separated from the ui I could extend the current model and trigger the generation myself and generate more than one CU. Pulling up some behaviour and state to a new abstract class. At least when looking from the ejbbuilder job, there seems to be a gap between ContainerPage and TypePage. Actually a good name for TypePage could be [Single/Simple]PageTypePage and making TypePage the superclass of it and New[Class/Interface]CreationPage as concrete subclasses of SinglePageTypePage. Stuff like access modifier make sense for an interface or class but doesn't make much sense for generating ejb, so if they were pushed down from the new TypePage to the new SimpleTypePage, I could leave them alone and extend the new TypePage. Just curious - as an eclipse newbie - why is it implemented as a page instead of a wizard? It is not supposed to interact with other pages, is it? As I am at it. Browsing through the code it seems, that after some indirection it ends up in CreateTypeOperation and this being a subclass of JavaModelOperation I was expecting some UpdateOperations as well, but haven't found any. After building the initial ejb wizard we would like to enhance the plugin to provide full lifecycle support and are looking for the right way of doing it. The whole code looks a tiny little bit like scripting code - not meant to be offensive though - maybe there is even more features which can be extracted to different classes because of their broader usage patterns. choosePackage() is one example here. If nothing of this makes any sense to you, it would at least nice if StubUtility would be promoted to the eclipse API. Btw. I don't think that ejbs are the only potential clients, which aren't fitting in the current picture. Creating stubs for WebServices or O/R mapping classes could be other candidates and I haven't really started thinking about it. I know it is much easier to critize, than .... I really do not intend to be offensive here and I probably missed the whole point - it is meant constructive. I do like and enjoy eclipse a lot. In the current project I am working my whole team of up to twenty developers is using eclipse since the middle of november and they love it - just discovered remote debugging. Mariano ps. Is there any particular reason that sometimes the instance variables are prefixed with "f" and sometimes not?
Back to the top