-
1. Re: Code generation for JBJCA
jesper.pedersen Apr 8, 2010 8:02 AM (in response to jeff.zhang)Sounds good
For the first iteration I would just take the input from the command line - like the seam-gen tool. Once we have all the input we need we can then make an XML model of that. That configuration can then be passed into the tool using f.ex. a -f switch.
Create the code under a
codegenerator
modul in the repository, and follow the layout of our current modules.
I think a good first step would be to generate a ResourceAdapter class into a specified output directory. Then we can add more input and generate additional code based on that.
-
2. Re: Code generation for JBJCA
jesper.pedersen Apr 8, 2010 8:06 AM (in response to jeff.zhang)A key feature of the tool would be to generate all the boiler plate code for all the config-property's for the various objects, and map them into ra.xml or annotate them. This is really painful work, so lets make it easy.
Of course the skeleton must pass all validation rules of our validation module. So the config-property's comes into play there too for the equals() / hashCode() implementations.
-
3. Re: Code generation for JBJCA
jesper.pedersen Apr 8, 2010 8:10 AM (in response to jeff.zhang)Regarding the XML model - I think that using a StAX based model would be the best solution.
See the
javax.xml.stream
package for details - we currently have some code in the repository using this method.
-
4. Re: Code generation for JBJCA
jeff.zhang Apr 13, 2010 6:00 AM (in response to jesper.pedersen)I commit the initial codes of code generation. That is first step and simple. Just input resource adapter package name and class name and code generator will create a resource adapter java file.
The code is in the trunk\codegenerator.
use "ant sjc" in the trunk directory. It will create jboss-jca-codegenerator.jar in the sjc/lib. Currently we need copy the codegenerator.sh/bat into lib directory and execute it.
Please input ResourceAdapter package name:
org.jboss.jca
Please input ResourceAdapter class name:
BaseResourceAdpater
Java file wroteThen BaseResourceAdpater.java file output.
PS: Jesper, you said we output the code into doc/codegenerator directory, this is default directory and we can use -output to configure it, correct?
-
5. Re: Code generation for JBJCA
jesper.pedersen Apr 13, 2010 9:23 AM (in response to jeff.zhang)Looks good I have placed the code generator in doc/codegenerator in the distribution as we talked about.
Next would be
- Support for adding <config-property> elements - with matching get/set/is methods
Move text strings in the tool to a resource bundle, so they can be translated (not the generated code)
- Support for adding a header in the generated files
- Basic code formatting rules (indentation, placement of "{", ...)
- Support for an output directory
Also I think it is best to have the input on the same line as the question:
Main resource adapter package: org.jboss.jca.example.jca16annotation
-
6. Re: Code generation for JBJCA
jeff.zhang Apr 21, 2010 5:20 AM (in response to jesper.pedersen)So far, my idea is based on template engine + variable value. But it seems not easy to implement this feature:
- Basic code formatting rules (indentation, placement of "{", ...)
Using "out.print" from scratch could control these very easy. But if we want replace it by thirdparty template engine jar later, it should be harder.
-
7. Re: Code generation for JBJCA
jeff.zhang Apr 21, 2010 6:47 AM (in response to jeff.zhang)An approach is using code formatter tools after code generation.
I found jalopy and eclipse code formatter can do this job well.
But jalopy is big (>1.2M, include swing gui tool) and eclispe code formattor embbedded any eclipse module code, I don't know can we use it in the code.
-
8. Re: Code generation for JBJCA
jesper.pedersen Apr 21, 2010 10:18 AM (in response to jeff.zhang)I think you should continue down the path you started - by having special keyword expansion inside on our template model.
Then just have keywords for " " (indentation - spaces/tabs), "{" (incl. an optional newline character) and so on.
Yes, the templates will be a bit more unreadable to a human, but when we consider some of the requirements down the road - like embedding specification references inside the method definitions - I think that the tradeoff is ok.