Hi Daniel,
On Wed, Dec 1, 2010 at 11:56 PM, Daniel Kulp <[email protected]> wrote: > On Wednesday 01 December 2010 10:15:36 pm Nithya Sivasubramaniam wrote: > > Hi, > > > > I am looking at fixing some open issues in jira. I am new to CXF, so I > > thought I would get started with some simple ones. I am currently looking > > at defect 'CXF-3129 - wsdl2java: place @Generated annotation on generated > > code'. > > > > Since jaxb-xjc already has such an option (-markgenerated), I passed in > > this option when CXF calls XJC. At first look, that seems to work. > > That covers the stuff XJC generates, but not the stuff we generate. Thus, > that is PART of the solution, but not all of it. The place to look would > be > in the velocity templates in: > > tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/ > I looked into the velocity templates and updated them to include support for the @Generated annotation as well. I have attached a patch to the defect ( https://issues.apache.org/jira/browse/CXF-3129). > > > > I still > > have to test some more scenarios. I will create a patch with the fix and > > some test cases soon. In the meanwhile, if anyone has any > > comments/suggestions on how to go about this, please let me know. Maybe > > adding the @Generated annotation can be made optional by having a flag in > > wsdl2java? > > That's probably a good idea. The starting point for that would be to add > the flag to the jaxws-toolspec.xml file. That would get it parsed and > into > the ToolContext that is passed around where you can query it where needed. > I created a new option '-mark-generated' which, when set, would cause all generated java class files to have the @Generated annotation at the class/field/constructor/method levels. This is also included in the patch I attached to the defect (https://issues.apache.org/jira/browse/CXF-3129). > > > > Also, I saw in the CXF website that one other area to contribute is by > > writing junit test cases. Does anyone have any particular area in mind > that > > I can work on, that is also easy enough for me to get involved? > > > > Thanks, > > Nithya > > A suggestion would be to look at the code coverage metrics at: > > http://nemo.sonarsource.org/drilldown/measures/117804?metric=coverage > > and find someplace that is pretty low but also interesting and start > working > on boosting the coverage in areas. You could definitely learn about some > areas of the code while helping to boost the code coverage. > The code coverage tool was very confusing to me. There were a few areas that I identified in sonarsource to have less coverage. When I ran all related junit tests myself and used another code coverage tool (eclemma - http://www.eclemma.org/), it showed that there was more coverage than what sonarsource showed. Maybe I didn't know how to use sonarsource. Anyway, I did create a few junit tests and I am attaching a patch with this email for those tests. Here are comments for the patch: (1) When a wsdllist file is opened for reading in WSDLToJavaContainer, it was not closed after reading. Fixed that. (2) Added new tests in CodeGenOptionTest to test -wsdlList option. Hope they are worthwhile! - Nithya
