[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-dev] Re: Annotated bean/servlet creation work for M3
|
First off, the code assist piece and the xdoclet tag sets
for the java editors is functional and has been released to WTP.
Can you point me in that direction.. What are the plugins? XDoclet
tagsets support should be generated in my view. There are many
xdoclet modules, and it would be collossal task to maintain them if the
plugins that supported these tagsets were not automatically generated
from xdoclet modules.
With that in hand,
I went ahead and downloaded the 3.1 level of the Lomboz plugins for
eclipse to see more of what you were
talking about in our discussion. I was able to create
annotated enterprise beans very quickly and easily, however playing
with
the wizards and tooling opened up an array of questions and
suggestions about where we should be going togehter with the
annotated creation support in WTP.
We will not port any of the UI pieces from Lomboz. It builds on a completely different module/project/ejb modle concept. So, although you have looked at the right place. We will not use those for WTP.
2) Project/Module Creation:
EJB Modules should be created with Project/Module creation wizards that Chuck is working on.
3) The bean creation wizard I saw was the following:
This UI will not be brought into WTP so no need to wory about it.
4) The CMP settings page I saw was this:
Currently, we will focus on simple EJBs (Session/MDBs etc) for M3. CMP mapping is not within the scope of this release. We will have more time to work it out.
5) Are these wizards, as is, extensible? That's another benefit of the data model wizard framework, it gives you extensibility.
Same as before no need to wory about these wizards. However, I find the current IBM wizard/command "framework" overly abstract and therefore not very useful. I'd rather we keep to the general wizard practices followed in eclipse base platform and JDT.
6) When I hit finish on the bean creation wizard I did get a valid xdoc annotated bean class, but I also got a whole bunch of
duplicate information at the time you guys are storing in comments:
This is the XML serialized model. I see are options as:
- Introspect source/annotations and construct a model everytime.
- Store model with the project (always have the potential to loose sync with code)
- Store model with the source (like what we have done. This also has the potential to loose sync with code if the editors do not update it)
7) We need to come up with a new plugin or an existing plugin for all of your stuff to live. We'll have to discuss pros and cons to puttin it into existing
ones we created for ejb or whether we should create new plugin.
Annotations for EJBs can be many. XDoclet is just one. We have a simple extension model where annotation types can be registered as extension points, and user "prefers" the one they would like to use. I would like to keep this as the model for annotation support in EJBs, Web, Struts what have you. We cannot push a certain type. Therefore, they will be seperate plugins with an extensible model for tool developers to register their "annotation style". This means although the wizards maybe the same, the code generated will be different based on users' choice.
8) For where we are at right now, I think the java editor should be the only way to edit the annotated bean. You mentioned some minilamistic editor, but I did not see it in the lomboz tooling. JDT should be good enough for now. That keeps things simple and in synch.
I agree. In lomboz you can menu click an on EJB and choose "EJB Editor". It is a Java Editor with additional form-based tabs. But I perefer to remain simple and just use Java Editor and code-assists for now.
10) The ant task for the xdoc is not tied to a builder, it is in an action called "Generate EJB classes". This will go ahead and invoke the xdoc
and overwrite anything in the eb-jar.xml with what is currently on disk for the bean class. It will not respect or have any notion of changes you
may have in the bean class at the time, like a working copy would, but thats just the way xdoc works. It would be nice to get this tied to the build
rather than a specific action, but I could also see the benefit of it being delayed because it is a pretty expensive operation, especially when you
start to scale. What do you think? Should we have the xdoc gen tied to the build?
Builder support is imperative, i.e. if the annotations change xdoclet emitted code becomes invalid.
11) Where is the servlet wizard? I did not see one anywhere. We have one in our Rational tooling we could push down if we
had to, or do you guys already have one?
There is a simple one. New>Servlet. But you can add yours. It is better.
Naci Dai,
Managing Director
eteration a.s.
Inonu cad. Sumer sok. Zitas D1-15
Kozyatagi, Istanbul 81090
+90 (532) 573 7783 (cell)
+90 (216) 361 5434 (phone)
+90 (216) 361 2034 (fax)
http://www.eteration.com
mailto:nacidai@xxxxxxx
mailto:naci@xxxxxxxxxxxxx
