[wtp-dev] Re: Annotated bean/servlet creation work for M3

[Naci Dai <naci.dai@xxxxxxxxxxxxx>]

John,

You were looking at the right place.    The short of the
story with  the Lomboz EJB support is:

        

-Create a
model object (that is what the wizard does).  Our EMF models are
based extended J2EE xsd.

        

-Pass this
model to  JET template that will create a "start"
annotated java implementation.
            .The
xml you saw in the code is how we store our EMF model.  Not clean
but It was always kept with the code.

        

-Add the
EJB to a module (this info is stored in a file named beans in the
META-INF)

        

-You edit
the code with Java editor after that, and get xdoclet code assist (we
will use your framework for this)

        

- Use ant
scripts to generate EJB classes and ejb-jar.xml etc. with xdoclet


The Plan for EJB support in WTP is:

a) Use MOFJ2EE instead of our EMF models. Chuck says we will access them
from natures (i.e. nature.getEjbModule()...).

        

-How do
natures stored information about EJBs?
          - Who keeps the
model them in sync with the annotated code? What is the role of  a
builder here? Are there any?

b) Use and extension model similar to that of Lomboz to support different
EJB annotations (i.e. XDoclet will only be an example of such an
extension)

        

. 
This extension will use JET emitters with the models from (a).

c) Edit annotated files with Java editor, but provide xdcolet code
assist. For this purpose we started reviewing the annotation support that
is in WTP (jst.annotation.core/controller/ui).  But it has no use in
any WTP plugin, so I guess we need an example of how the annotation
support framework works.  I tried a simple extension (attached the
plugin.xml)  but could not get it to work.

        

.What are
the roles of the AnnotationController and ValueHelper?

        

.Are there
APIs for them?  I found some Interfaces classes and they were in a
"internal" package.  Also there seems to be some
"com.ibm..." name space use left in that code.




At 07:22 AM 1/19/2005, Chuck Bridgham wrote:

Hi Naci,

I did publish the rose diagram on the web for now....  http://www.eclipse.org/webtools/jst/components/j2ee/model%20diagram/j2ee_rose.html
I will continue to explore an alternative "open" file format.

All of the models can be loaded using our Nature api for now... This will obviously change with module level granularity being introduced....

For instance...
nature = (J2EEWebNatureRuntime) project.getNature(IWebNatureConstants.J2EE_NATURE_ID);
nature.getWebApp().getServlets();

Thanks - Chuck

Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email:  cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)



John Lanuti/Raleigh/IBM

01/18/2005 03:49 PM

To

Naci Dai <naci.dai@xxxxxxxxxxxxx>

cc

Chuck Bridgham/Raleigh/IBM@IBMUS

Subject

Annotated bean/servlet creation work for M3



Hey Naci,

First off, the code assist piece and the xdoclet tag sets for the java editors is functional and has been released to WTP.

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.

1) Am I even looking at the right stuff?  Are these lomboz plugins what you are proposing to drop to WTP?  If I am way off, please
correct me so I can get a look at the tooling.

2) Project/Module Creation:

 

This wizard is definately going to have to be reworked or might not even be necessary when our flexible project support wizards are
ready.  We probably just want to piggyback of what we have for module creation.

3) The bean creation wizard I saw was the following:

 

This wizard has a whole lot going on and definately has some UI flaws we will have to work out.  The flow may need
to be reworked and we might want to think about adding more pages to specialize the content the user sees for the type
of bean they want.  We also need to work on the defaults and enablement/disablement of next and finish.  I would reccommend
the wizard be ported to our data model framework because it makes a lot of the validation and enablement issues seamless
and trivial.  We can do some simple tidying up of the spacing as well.  I can help you guys with this.

4)  The CMP settings page I saw was this:

 

This page I think can be simplified.  I don't think we want the backend schema and mapping information in an
ejb creation wizard and especially not for M3.  We probably just want a dialog to enter cmp attributes.  We need
to work on the validation as well as it is quite slow, and again I really think porting to the wizard data model framework
would be a worthwhile endeavour.

5) Are these wizards, as is, extensible?  That's another benefit of the data model wizard framework, it gives you extensibility.

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:

 <!--  begin-lomboz-definition -->
 <?xml version="1.0" encoding="UTF-8"?>
 <lomboz:EJB xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:lomboz="http://lomboz.objectlearn.com/xml/lomboz">
 <lomboz:entity>
 <lomboz:entityEjb>
 <j2ee:display-name>TestBean</j2ee:display-name>
 <j2ee:ejb-name>SampleEjb</j2ee:ejb-name>
 <j2ee:ejb-class>test.TestBeanBean</j2ee:ejb-class>
 <j2ee:persistence-type>Container</j2ee:persistence-type>
 <j2ee:prim-key-class>java.lang.Integer</j2ee:prim-key-class>
 <j2ee:cmp-version>2.x</j2ee:cmp-version>
 <j2ee:abstract-schema-name>mySchema</j2ee:abstract-schema-name>
 <j2ee:primkey-field>id</j2ee:primkey-field>
 </lomboz:entityEjb>
 <lomboz:fieldMappings>
 <lomboz:fieldName>id</lomboz:fieldName>
 <lomboz:fieldType>java.lang.Integer</lomboz:fieldType>
 <lomboz:columnName>ID</lomboz:columnName>
 <lomboz:jdbcType>VARCHAR</lomboz:jdbcType>
 <lomboz:sqlType>fpoo</lomboz:sqlType>
 <lomboz:readOnly>false</lomboz:readOnly>
 <lomboz:primaryKey>true</lomboz:primaryKey>
 </lomboz:fieldMappings>
 <lomboz:fieldMappings>
 <lomboz:fieldName>id2</lomboz:fieldName>
 <lomboz:fieldType>java.lang.Integer</lomboz:fieldType>
 <lomboz:columnName>ID</lomboz:columnName>
 <lomboz:jdbcType>VARCHAR</lomboz:jdbcType>
 <lomboz:sqlType>fpoo</lomboz:sqlType>
 <lomboz:readOnly>false</lomboz:readOnly>
 <lomboz:primaryKey>false</lomboz:primaryKey>
 </lomboz:fieldMappings>
 <lomboz:tableName>Foo</lomboz:tableName>
 <lomboz:dataSourceName>dooo</lomboz:dataSourceName>
 </lomboz:entity>
 </lomboz:EJB>
 <!--  end-lomboz-definition -->

Is this really needed for the WTP solution?  Hopefully this information can be removed as it is "clutter", is not kept in synch with the xdoc tags and is
really redundant of the info in the xdoc tags.

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. 

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.

9) We should definately link the final wizard in with the toolbar for the J2EE perspective and in the J2EE project explorer, as well as add the wizard to the
new menu options.

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?

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?

What are your thoughts and feedback on my comments?  What were you guys planning for M3?  How much time and resources do you have available?
How can I help?  We will probably need another conference call, but for now, let me know what you were thinking of contributing and what you think about
the suggestions.  If you are willing to work on the wizards, I can go into much greater detail with you and we can work together on prototyping. 

Looking forward to your feedback,

John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861

"Wouldn't it be the best day if we all took time to breathe?"  - Of A Revolution
"A man who doesn't spend time with his family can never be a real man."   - Don Corleone, The Godfather

Attachment: plugin.xml
Description: XML document

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