Change Notes item #658052, was opened at 2002-12-24 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=658052&group_id=22866
Category: Build System Group: v4.0 Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: David Jencks (d_jencks) Summary: XDoclet built in JBoss Initial Comment: I've addded an xdoclet module to jboss 4 (head) that builds xdoclet from source from the xdoclet cvs tree. To minize disruption, please read! You can avoid requiring a fresh jboss checkout by executing in jboss-head cvs get _jboss_xdoclet WARNING you may have to run build/build.sh twice, see "Issues". I am investigating this. HOW IT WORkS------- The first time you build jboss, xdoclet source is checked out into a directory checkout by the xdoclet/build.xml ant script. The cvs properties are set in the xdoclet.cvs.properties file. After successful checkout and build, flag files are created xdoclet.last.checkout and xdoclet.last.build. As long as the checkout folder remains, and these files are not touched, xdoclet will not be rebuilt. On my machines building xdoclet takes about the same amount of time as building jboss. The xdoclet build is supplied with some properties so it builds into xdoclet/output/lib. The libraries.ent file is modified to use xdoclet from here. If all goes well I will remove the xdoclet copy from thirdparty in a day or two. if you want to modify xdoclet, remove the xdoclet.last.build file and your modifications will be compiled the next time you build jboss. CHANGES WITH THIS VERSION OF XDOCLET------- --The main change is that xdoclet no longer copies over all the imports from your source class to generated interfaces, instead fully qualifying all class names in the generated interfaces. WARNING!!! THIS REQUIRES YOU TO EXPLICITLY IMPORT EVERY CLASS IN EVERY JAVA FILE XDOCLET LOOKS AT!! NO import x.y.x.*;!!!!! If you import a package.*, xdoclet may find a class referenced in a file in which it is not explicitly imported and decide the class is "unknown" and therefore to be generated in the "current" package, and not fully qualify the name in ANY file it generates. This can be extremely confusing since the effects are in a file totally unrelated to the file with the package import, and there is no obvious warning of where the problem came from. I'm looking for a way to at least provide a more obvious warning for this. --xmbean operations require you to list the managed-parameters with the correct types. While a nuisance, this at least encourages you to comment them. --xmbean display-names can be specified, and they display in the jmx-console. ----------------------------- Issues: --currently xdoclet head is checked out. After I make sure this works a little more and fix a couple of xdoclet problems I will tag xdoclet source so we have a more stable checkout. --On some machines it appears that the first build will not be able to find the just-compiled xdoclet jars. Running build/build.sh again seems to find them. (I thought it worked on apple 1.4.1, but a fresh checkout on linux sun 1.3.1 fails on the first build). I'm looking at this. ------------------------------ Next steps: put the jboss xdoclet module into jboss cvs and build it with the rest of xdoclet. provide instructions for xdoclet committers to work with a "live" copy of xdoclet in jboss. Thanks david jencks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=658052&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
