[Xdoclet-devel] Struts forms futures
gents, I'm considering a problem with building struts forms that maybe you can shed some light on. A missing feature that I am presently finding very important would be the generation of forms based on multiple value objects. As it stands today, the only forms that can be generated are against a single source bean dataobject. I submitted a patch that at least allows me to be able to use struts forms in combination with value objects, but the singular nature of the forms really seems to be a problem for real-world apps... or am I missing something huge? Considering dataobjects need to be pulled from the forms anyway, it seems like the right time to implement this. In other words, a single form name could be referenced by multiple classes, and the form that is generated would have value objects for all of these classes contained therein. Then, for every method-level @struts:form-field tag, the corresponding encapsulation would be generated into the form object. The encapsulation would simply be a call-through to the correct class and method of the contained value objects. What this would allow is for complex forms to be generated with the possibility of including multiple objects. One of the things that would need to change is the patterned filename options -- the form is the same name across different source beans that reference it. Does this sound like a reasonable goal and would it be something that you would want to add to the tree if I put it together? It's probably going to take me a relatively obscene amount of time to pull it off, but I guess the first one is always like that, right? OTOH, if someone who can churn these out faster than I can, I'm just as happy to work on some other stuff ;) If it sounds like something worthwhile, any tips on where to start would be great, but I think I can pick existing code apart to get it going as well... thoughts appreciated, -b --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Feature Requests-578989 ] Gen constants for ejb-ref COMP_NAMEs
Feature Requests item #578989, was opened at 2002-07-09 08:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=578989&group_id=31602 Category: ejbdoclet Group: None >Status: Closed Priority: 5 Submitted By: William Ferguson (williamferguson) Assigned to: Nobody/Anonymous (nobody) Summary: Gen constants for ejb-ref COMP_NAMEs Initial Comment: XDoclet should generate constants for the COMP_NAMEs declared in the ejb-refs for a bean. Ie For BeanA that has an ejb-ref to BeanB, I declare an ejb:ejb-ref (or ejb:ejb-external-ref) tag and an appserver tag to bind the BeanB's COMP_NAME to a JNDI_NAME for BeanA. During BeanA's setSessionContext() I would like to resolve the reference to BeanB's Home using the COMP_NAME. At the moment you must manually include a second String specifying the same COMP_NAME as declared in the ejb-ref tag in BeanA's header. It seems sensible to automatically generate the COMP_NAME constant for beans that are *referenced*. NB The BeanUtil class that XDoclet can generate is not a solution as it (aberrantly IMO) generates a COMP_NAME for the bean itself and the beans that are referenced. Kind of like putting the cart before the horse :-) -- >Comment By: Aslak Hellesøy (rinkrank) Date: 2002-07-09 21:38 Message: Logged In: YES user_id=49846 Dupe of #558937 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=578989&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] XDocletGUI cvs broken?
Is there anyway to compile xdocletgui ? The build.bat file seems to be broken (the path to xjavadoc.jar is wrong) and when I correct it, it sounds like xjavadoc changes are not backward compatible with xdocletgui so I can't compile it... Any help appreciated. Thanks, Jerome. ** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail: to do so could be a breach of confidence. Please notify us immediately by reply e-mail and then delete this e-mail from your system. Please contact our IT Helpdesk on +44 (0)20 7212 or e-mail [EMAIL PROTECTED] if you need assistance. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. This e-mail has been sent through the e-mail gateway of Vizzavi Europe Limited ("VEL") on its own account or on behalf of and for the benefit of other Vizzavi group companies who use this facility from time to time. VEL Registered office - 80 Strand London WC2R ORJ England. Registered in England No. 04064873 For this message in Dutch, French, German, Greek, Italian, Portuguese and Spanish, click on http://www.corp.vizzavi.net/disclaimer/ Visit Vizzavi at: http://www.vizzavi.net/ This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
[Xdoclet-devel] Fwd: Mail delivery failed: returning message to sender
> <[EMAIL PROTECTED]> wrote: > > Is there anyway to compile xdocletgui ? > > > > The build.bat file seems to be broken (the path to > > xjavadoc.jar is wrong) > > and when I correct it, it sounds like xjavadoc > > changes are not backward > > compatible with xdocletgui so I can't compile > it... > I'm developer, and I work under Linux / Unix - so build.bat may be not up to date. You are welcome to fix it ( I can not testr it ) and submit a patch - I will commit it. Though it will not run at the moment. It's being switched to module loading like xdoclet core, and at the moment there is no decision how to integrate xtags into core ( where it belongs ) regards, = Konstantin Priblouda ( ko5tik )Freelance Software developer < http://www.pribluda.de > < play java games -> http://www.yook.de > < render charts online -> http://www.pribluda.de/povray/ > __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE : [Xdoclet-devel] Fwd: Mail delivery failed: returning message to sender
> I'm developer, and I work under Linux / Unix - so > build.bat may be not up to date. > > You are welcome to fix it ( I can not testr it ) > and submit a patch - I will commit it. Well I can do it myself as I am a commiter. This issue is to make the code compiling though. > Though it will not run at the moment. It's being > switched to module loading like xdoclet core, > and at the moment there is no decision how to > integrate > xtags into core ( where it belongs ) Does it mean that there is no way to use xdocletgui while it has not been updated? Jerome. --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: RE : [Xdoclet-devel] Fwd: Mail delivery failed: returning message to sender
> Well I can do it myself as I am a commiter. This > issue is to make the > code compiling though. Oh, it compiles without any problems through build.sh Steal ideas from there. > > Though it will not run at the moment. It's being > > switched to module loading like xdoclet core, > > and at the moment there is no decision how to > > integrate > > xtags into core ( where it belongs ) > > Does it mean that there is no way to use xdocletgui > while it has not > been updated? The problem lies in detail. I initially wrote tag description xml file. It worked with it fine. Then xtags.xml was broken in parts, which reside in different modules. For now, there is no decision how to load those broken out xtags files. I'm faworing to expand XDocletModule to load and parse own xtags, and to offer them for those who ask for it. But on the eve of new xdoclet release - no new features into core. Maybe we shall tag our own wersion and proceed? regards, = Konstantin Priblouda ( ko5tik )Freelance Software developer < http://www.pribluda.de > < play java games -> http://www.yook.de > < render charts online -> http://www.pribluda.de/povray/ > __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] XDocletGUI cvs broken?
I haven't tried it in a while. Since we have removed ant.jar, optional.jar and the various build.bat/build.sh scripts from xdoclet and xjavadoc, I think we should do that for xdocletgui too. All classpaths should be handled in build.xml, and it should be possible to build with the "official" ant batch scripts. This will also remove incompatibilities between various environments/OSes. Konstantin, is this something you could take a look at? Aslak -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bernard, Jérôme Sent: 10. juli 2002 17:47 To: '[EMAIL PROTECTED]' Subject: [Xdoclet-devel] XDocletGUI cvs broken? Is there anyway to compile xdocletgui ? The build.bat file seems to be broken (the path to xjavadoc.jar is wrong) and when I correct it, it sounds like xjavadoc changes are not backward compatible with xdocletgui so I can't compile it... Any help appreciated. Thanks, Jerome. ** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail: to do so could be a breach of confidence. Please notify us immediately by reply e-mail and then delete this e-mail from your system. Please contact our IT Helpdesk on +44 (0)20 7212 or e-mail [EMAIL PROTECTED] if you need assistance. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. This e-mail has been sent through the e-mail gateway of Vizzavi Europe Limited ("VEL") on its own account or on behalf of and for the benefit of other Vizzavi group companies who use this facility from time to time. VEL Registered office - 80 Strand London WC2R ORJ England. Registered in England No. 04064873 For this message in Dutch, French, German, Greek, Italian, Portuguese and Spanish, click on http://www.corp.vizzavi.net/disclaimer/ Visit Vizzavi at: http://www.vizzavi.net/ This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE : RE : [Xdoclet-devel] Fwd: Mail delivery failed: returning message to sender
> Oh, it compiles without any problems through build.sh > Steal ideas from there. Could you explain me which xjavadoc.jar archive you are using and where it is supposed to be?? There is none in the lib directory and you're not using the one produced when compiled the xjavadoc module... Are you sure, there is nothing missing? Jerome. --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: RE : RE : [Xdoclet-devel] Fwd: Mail delivery failed: returning message to sender
--- Jérôme_BERNARD <[EMAIL PROTECTED]> wrote: > > Oh, it compiles without any problems through > build.sh > > Steal ideas from there. > > Could you explain me which xjavadoc.jar archive you > are using and where > it is supposed to be?? It pulls all the jar files from xdoclet dist. Basically directory structure shall be somewhere/xdoclet /xjavadoc /xdocletgui Xdoclet shall be compiled of course. regards = Konstantin Priblouda ( ko5tik )Freelance Software developer < http://www.pribluda.de > < play java games -> http://www.yook.de > < render charts online -> http://www.pribluda.de/povray/ > __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] XDocletGUI cvs broken?
--- Aslak_Hellesøy <[EMAIL PROTECTED]> wrote: > I haven't tried it in a while. Since we have removed > ant.jar, optional.jar > and the various build.bat/build.sh scripts from > xdoclet and xjavadoc, I > think we should do that for xdocletgui too. All > classpaths should be handled > in build.xml, and it should be possible to build > with the "official" ant > batch scripts. > > This will also remove incompatibilities between > various environments/OSes. > > Konstantin, is this something you could take a look > at? Already at it. ( it seems that I'm somehow in charge for GUI :) ) But what we really need for GUI ( and fast ) is the way to locate xtags.xml files out of modules. Parsing is not yet necessary, we can do it in GUI, but location is paramount... regards, = Konstantin Priblouda ( ko5tik )Freelance Software developer < http://www.pribluda.de > < play java games -> http://www.yook.de > < render charts online -> http://www.pribluda.de/povray/ > __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] Any schedule for 1.2 beta
Title: Any schedule for 1.2 beta Just wondering when will be released 1.2 beta. I know it was a very annoying accident of stoled computer. May be someone knows already about new plans. Thanks Boris
[Xdoclet-devel] patch applications
Could a committer please review and apply the following patches: 579252, 579236, 579172. Thanks, Michael --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/core/src/xdoclet/tagshandler AbstractProgramElementTagsHandler.java
User: pathoss Date: 02/07/10 11:29:13 Modified:core/src/xdoclet/tagshandler AbstractProgramElementTagsHandler.java Log: Applied patch 579252 "missing @ on doc tags in generated code". Thanks for reporting! Revision ChangesPath 1.5 +2 -2 xdoclet/core/src/xdoclet/tagshandler/AbstractProgramElementTagsHandler.java Index: AbstractProgramElementTagsHandler.java === RCS file: /cvsroot/xdoclet/xdoclet/core/src/xdoclet/tagshandler/AbstractProgramElementTagsHandler.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -w -r1.4 -r1.5 --- AbstractProgramElementTagsHandler.java15 Jun 2002 20:25:53 - 1.4 +++ AbstractProgramElementTagsHandler.java10 Jul 2002 18:29:12 - 1.5 @@ -35,7 +35,7 @@ /** * @authorAra Abrahamian ([EMAIL PROTECTED]) * @created Oct 15, 2001 - * @version $Revision: 1.4 $ + * @version $Revision: 1.5 $ */ public abstract class AbstractProgramElementTagsHandler extends XDocletTagSupport { @@ -603,7 +603,7 @@ if (memberTagName.indexOf(':') == -1 && memberTagName.indexOf('.') == -1 && getDocletContext().getExcludedTags().indexOf(memberTagName) == -1) { sbuf.append(spaces).append(" * ") -.append(memberTags[i].getName()).append(' ') +.append('@').append(memberTags[i].getName()).append(' ') .append(memberTags[i].getValue()); // for all lines but not the last line --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/ejb/src/xdoclet/modules/ejb/dd/resources ejb-body.xdt
User: pathoss Date: 02/07/10 11:35:13 Modified:modules/ejb/src/xdoclet/modules/ejb/dd/resources ejb-body.xdt Log: Applied patch 579172, "ejb:external-ref dies if view-type=local". Revision ChangesPath 1.8 +1 -1 xdoclet/modules/ejb/src/xdoclet/modules/ejb/dd/resources/ejb-body.xdt Index: ejb-body.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/ejb/src/xdoclet/modules/ejb/dd/resources/ejb-body.xdt,v retrieving revision 1.7 retrieving revision 1.8 diff -u -w -r1.7 -r1.8 --- ejb-body.xdt 8 Jul 2002 23:25:32 - 1.7 +++ ejb-body.xdt 10 Jul 2002 18:35:13 - 1.8 @@ -174,7 +174,7 @@ > - + --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources struts_config_xml.xdt
User: pathoss Date: 02/07/10 11:50:35 Modified:modules/apache/src/xdoclet/modules/apache/struts/resources struts_config_xml.xdt Log: Applied patch 574466, "New Merge Points for struts-config". Revision ChangesPath 1.6 +9 -1 xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources/struts_config_xml.xdt Index: struts_config_xml.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources/struts_config_xml.xdt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -w -r1.5 -r1.6 --- struts_config_xml.xdt 9 Jul 2002 13:21:29 - 1.5 +++ struts_config_xml.xdt 10 Jul 2002 18:50:35 - 1.6 @@ -114,4 +114,12 @@ + + + + + + + + --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources struts_config_xml.xdt
User: pathoss Date: 02/07/10 12:01:35 Modified:modules/apache/src/xdoclet/modules/apache/struts/resources struts_config_xml.xdt Log: Fixed merge points to support Struts 1.1. Revision ChangesPath 1.7 +24 -15 xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources/struts_config_xml.xdt Index: struts_config_xml.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources/struts_config_xml.xdt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -w -r1.6 -r1.7 --- struts_config_xml.xdt 10 Jul 2002 18:50:35 - 1.6 +++ struts_config_xml.xdt 10 Jul 2002 19:01:35 - 1.7 @@ -3,6 +3,16 @@ " ""> + + + + + + + @@ -15,19 +25,22 @@ - + - + - + - - - - - - + @@ -114,8 +119,12 @@ - - + + + + + + --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/ejb/src/xdoclet/modules/ejb/dd/resources asm-descriptor.xdt
User: pathoss Date: 02/07/10 12:07:12 Modified:modules/ejb/src/xdoclet/modules/ejb/dd/resources asm-descriptor.xdt Log: Applied patch 579717. Revision ChangesPath 1.5 +7 -0 xdoclet/modules/ejb/src/xdoclet/modules/ejb/dd/resources/asm-descriptor.xdt Index: asm-descriptor.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/ejb/src/xdoclet/modules/ejb/dd/resources/asm-descriptor.xdt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -w -r1.4 -r1.5 --- asm-descriptor.xdt25 Jun 2002 22:32:43 - 1.4 +++ asm-descriptor.xdt10 Jul 2002 19:07:10 - 1.5 @@ -1,5 +1,12 @@ > + + + --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] Not back... yet
Hello folks! Sorry for me disappearing. My home computer crashed and is now waiting for replacement parts and for me having money to pay for them. I was without any internet conectivity for the last two weeks. I'm back to the Internet and will start reading the lists again, however I won't be able to do any coding till I get my computer again. If anything happened on the last few weeks that should concern me, please notify me again. -- Marcus Brito <[EMAIL PROTECTED]> --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xjavadoc/lib log4j.jar
User: pathoss Date: 02/07/10 12:20:32 Modified:lib log4j.jar Log: Upgraded to 1.2.5. Revision ChangesPath 1.3 +905 -447 xjavadoc/lib/log4j.jar <> --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdocletgui/lib log4j.jar
User: pathoss Date: 02/07/10 12:21:19 Modified:lib log4j.jar Log: Upgraded to Log4J 1.2.5. Revision ChangesPath 1.2 +1277 -609 xdocletgui/lib/log4j.jar <> --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] XDocletGUI cvs broken?
> -Original Message- > From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]] > Sent: 10. juli 2002 18:44 > To: Aslak_Hellesxy > Cc: [EMAIL PROTECTED] > Subject: RE: [Xdoclet-devel] XDocletGUI cvs broken? > > > > --- Aslak_Hellesxy <[EMAIL PROTECTED]> wrote: > > I haven't tried it in a while. Since we have removed > > ant.jar, optional.jar > > and the various build.bat/build.sh scripts from > > xdoclet and xjavadoc, I > > think we should do that for xdocletgui too. All > > classpaths should be handled > > in build.xml, and it should be possible to build > > with the "official" ant > > batch scripts. > > > > This will also remove incompatibilities between > > various environments/OSes. > > > > Konstantin, is this something you could take a look > > at? > > Already at it. ( it seems that I'm somehow in charge > for GUI :) ) > Well, you've done a great job so far, so why not make it your baby? > But what we really need for GUI ( and fast ) is the > way to locate xtags.xml files out of modules. > Shouldn't be too hard. This can be obtained by adding code to read xtags.xml inside xdoclet.loader.ModuleFinder.findModules(). In addition to that, we could make an XTagsXmlParser (inspired from xdoclet.loader.XDocletXmlParser/xtags.ConditionFactory). Finally, I think it would be a good idea to hook up the objectified xtags.xml's on the xdoclet.loader.XDocletModule objects. I don't see why this work couldn't start right away. Here is a proposed process for it: 1) Start on some design documents under xdoclet/xdocs where we can start to describe our ideas for the xtags architecture (and also Velocity). When we agree on how to proceed, move to 2). 2) Make a branch e.g. XTAGS_REFACTORING on the xdoclet module and start moving over the xtags stuff from xdocletgui. This will have no impact on the forthcoming XDoclet 1.2 release. Any thoughts on this? Aslak > Parsing is not yet necessary, we can do it in GUI, but > location is paramount... > > regards, > > = > Konstantin Priblouda ( ko5tik )Freelance Software developer > < http://www.pribluda.de > < play java games -> http://www.yook.de > > < render charts online -> http://www.pribluda.de/povray/ > > > __ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] Any schedule for 1.2 beta
Title: Any schedule for 1.2 beta It would be unfair to blame the overdue release on my stolen computer. Anyway, I've got a new one now ;-) Also see my reply here for general comments about the upcoming release: http://sourceforge.net/mailarchive/forum.php?thread_id=876652&forum_id=1106 We *hope* to release 1.2 beta within a couple of weeks, but we can't promise anything. Aslak -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Boris TamarkinSent: 10. juli 2002 19:39To: '[EMAIL PROTECTED]'Subject: [Xdoclet-devel] Any schedule for 1.2 beta Just wondering when will be released 1.2 beta. I know it was a very annoying accident of stoled computer. May be someone knows already about new plans. Thanks Boris
[Xdoclet-devel] CVS update: xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/resources jbosscmp-jdbc_xml.xdt
User: rinkrank Date: 02/07/10 12:58:00 Modified:modules/jboss/src/xdoclet/modules/jboss/ejb/resources jbosscmp-jdbc_xml.xdt Log: Fixing incorrect BWC tags/tag attributes Revision ChangesPath 1.6 +12 -12 xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/resources/jbosscmp-jdbc_xml.xdt Index: jbosscmp-jdbc_xml.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/resources/jbosscmp-jdbc_xml.xdt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -w -r1.5 -r1.6 --- jbosscmp-jdbc_xml.xdt 25 Jun 2002 22:34:09 - 1.5 +++ jbosscmp-jdbc_xml.xdt 10 Jul 2002 19:57:59 - 1.6 @@ -57,8 +57,8 @@ - - + + @@ -69,17 +69,17 @@ - - + + - + - - + + - - + + @@ -277,16 +277,16 @@ - + - + - + --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Feature Requests-578937 ] Gen constants for ejb-ref COMP_NAMEs
Feature Requests item #578937, was opened at 2002-07-09 01:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=578937&group_id=31602 Category: ejbdoclet Group: None Status: Open Priority: 5 Submitted By: William Ferguson (williamferguson) Assigned to: Nobody/Anonymous (nobody) Summary: Gen constants for ejb-ref COMP_NAMEs Initial Comment: XDoclet should generate constants for the COMP_NAMEs declared in the ejb-refs for a bean. Ie For BeanA that has an ejb-ref to BeanB, I declare an ejb:ejb-ref (or ejb:ejb-external-ref) tag and an appserver tag to bind the BeanB's COMP_NAME to a JNDI_NAME for BeanA. During BeanA's setSessionContext() I would like to resolve the reference to BeanB's Home using the COMP_NAME. At the moment you must manually include a second String specifying the same COMP_NAME as declared in the ejb-ref tag in BeanA's header. It seems sensible to automatically generate the COMP_NAME constant for beans that are *referenced*. NB The BeanUtil class that XDoclet can generate is not a solution as it (aberrantly IMO) generates a COMP_NAME for the bean itself and the beans that are referenced. Kind of like putting the cart before the horse :-) -- >Comment By: Andrew Stevens (stevensa) Date: 2002-07-10 16:57 Message: Logged In: YES user_id=247081 For that matter, why do we generate the COMP_NAME and JNDI_NAME in the Home interface, rather than in the Util class that uses them? Is it just historical (they predate the Util class generation), or is there some other reason? Having them in the Home is causing me problems with Powerbuilder proxy object generation for my EJBs, which would go away if the constants were in the utility class instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=578937&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Feature Requests-579713 ] apply labels in cvs to mark releases
Feature Requests item #579713, was opened at 2002-07-10 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=579713&group_id=31602 Category: ejbdoclet Group: None Status: Open >Priority: 4 Submitted By: toby cabot (tcabot) Assigned to: Nobody/Anonymous (nobody) Summary: apply labels in cvs to mark releases Initial Comment: Folks, It would be very useful if you could apply CVS labels to the source that you use to build releases. This would allow people to grab specific releases, not just the head, from CVS. Here's the issue I've got now: I'm using xdoclet 1.1.2 (it's cool!) and I'd like to make a small hack to it. The current cvs head xdoclet would require that I upgrade ant to a beta version which I'd rather not do. If there were tags in CVS I could just grab the source to 1.1.2 and rock-n-roll. Yes, I can get the source tarball but then I lose all of CVS's useful features such as diffing and merging from the repository. Thanks, Toby Cabot -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=579713&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Feature Requests-579717 ] [patch] assembly-descriptor merge point
Feature Requests item #579717, was opened at 2002-07-10 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=579717&group_id=31602 Category: None Group: None Status: Open Priority: 5 Submitted By: toby cabot (tcabot) Assigned to: Nobody/Anonymous (nobody) Summary: [patch] assembly-descriptor merge point Initial Comment: Here's a patch to add another merge point to the ejb-jar.xml file. I found it useful while converting over from a hand-made ejb-jar.xml to an xdoclet-generated one. This allowed me to cut the old file into merge points and switch to an ejbdoclet-generated ejb-jar.xml, then move the beans to ejbdoclet one by one. --- modules/ejb/src/xdoclet/modules/ejb/dd/resources/asm-descriptor.xdt 25 Jun 2002 22:32:43 - 1.4 +++ modules/ejb/src/xdoclet/modules/ejb/dd/resources/asm-descriptor.xdt 10 Jul 2002 17:28:37 - @@ -1,5 +1,13 @@ > + + + + -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=579717&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Feature Requests-579713 ] apply labels in cvs to mark releases
Feature Requests item #579713, was opened at 2002-07-10 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=579713&group_id=31602 Category: ejbdoclet Group: None Status: Open Priority: 5 Submitted By: toby cabot (tcabot) Assigned to: Nobody/Anonymous (nobody) Summary: apply labels in cvs to mark releases Initial Comment: Folks, It would be very useful if you could apply CVS labels to the source that you use to build releases. This would allow people to grab specific releases, not just the head, from CVS. Here's the issue I've got now: I'm using xdoclet 1.1.2 (it's cool!) and I'd like to make a small hack to it. The current cvs head xdoclet would require that I upgrade ant to a beta version which I'd rather not do. If there were tags in CVS I could just grab the source to 1.1.2 and rock-n-roll. Yes, I can get the source tarball but then I lose all of CVS's useful features such as diffing and merging from the repository. Thanks, Toby Cabot -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402707&aid=579713&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Patches-579172 ] ejb:external-ref dies if view-type=local
Patches item #579172, was opened at 2002-07-09 18:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402706&aid=579172&group_id=31602 Category: ejbdoclet Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Newcomb (mnewcomb) Assigned to: Nobody/Anonymous (nobody) Summary: ejb:external-ref dies if view-type=local Initial Comment: When the view-type for ejb:external-ref is 'local', the resulting ejb-local-ref element is bad because it just contains a element instead of a element as specified in the ejb 2.0 dtd. This was just a one-line fix in: modules/ejb/src/xdoclet/modules/ejb/dd/resources/ejb-body.xdt I've included the patch which fixes this bug. When this patch is applied, ejb-local-refs will work properly. Michael -- >Comment By: Mathias Bogaert (pathoss) Date: 2002-07-10 20:35 Message: Logged In: YES user_id=102175 Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402706&aid=579172&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Patches-574466 ] New Merge Points for struts-config
Patches item #574466, was opened at 2002-06-27 08:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402706&aid=574466&group_id=31602 Category: vendor Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Volker Krebs (vkrebs) Assigned to: Nobody/Anonymous (nobody) Summary: New Merge Points for struts-config Initial Comment: I've added two merge points for Struts 1.1. Thess are for plug-ins and controllers. This patch is to be applied over XDoclet-v1-1-2 tag, because it needs struts-config_1_1.dtd. After applying it, you will be able to include a file called struts-plugins.xml and struts-controllers.xml in your merge dir. So, the strutsconfigxml task will include your plugins and controllers in your struts-config.xml generated file. This is neccesarry if you want to use the new struts plugin validation. Since this was my first patch, I hope everything was submitted correctly. Volker -- >Comment By: Mathias Bogaert (pathoss) Date: 2002-07-10 20:50 Message: Logged In: YES user_id=102175 Added in CVS. Thanks for the patch! -- Comment By: Volker Krebs (vkrebs) Date: 2002-07-01 16:00 Message: Logged In: YES user_id=569376 Sorry forgot the file. -- Comment By: Volker Krebs (vkrebs) Date: 2002-07-01 15:59 Message: Logged In: YES user_id=569376 Sorry for the wrong patch submission. I've made a diff against the latest CVS, hope this patch is ok now. Volker -- Comment By: Aslak Hellesøy (rinkrank) Date: 2002-06-27 12:23 Message: Logged In: YES user_id=49846 Hi Volker, and thanks for your patch. You did a few things wrong... Patches should always be done against the latest CVS version, otherwise it's a high chance that they're obsolete and therefore impossible to apply. Can you do that (if it's still appliccable?) Also, a patch should be submitted as a diff, not an entire file, so we can see _what_ you changed. Here is info about how to produce a diff: http://jakarta.apache.org/site/source.html Cheers, Aslak -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402706&aid=574466&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [ xdoclet-Patches-579252 ] missing @ on doc tags in generated code
Patches item #579252, was opened at 2002-07-09 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402706&aid=579252&group_id=31602 Category: xdoclet Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Newcomb (mnewcomb) Assigned to: Nobody/Anonymous (nobody) Summary: missing @ on doc tags in generated code Initial Comment: Whenever you generate code from methods that have valid javadoc tags (@return, @param, etc.), the generated files would be missing the '@' in front of the tag. This patch adds the missing '@' symbol in front of javadoc tags. It touches just one file: xdoclet/core/src/xdoclet/tagshandler/AbstractProgramElementTagsHandler.java Michael -- >Comment By: Mathias Bogaert (pathoss) Date: 2002-07-10 20:30 Message: Logged In: YES user_id=102175 Thanks for the patch! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402706&aid=579252&group_id=31602 --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] XJavaDoc problem
I think there is a problem with http://cvs.xdoclet.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xjavadoc/src/ xjavadoc/XJavaDoc.java.diff?r1=1.44&r2=1.45 The thing is that when the a super class of a XClass does not exist on the classpath (as source or in a binary), I get a nullpointer. As I have almost no knowledge of XJavaDoc, I dunno how to fix this. When I put the jar with the missing class on the classpath, it works. Mathias --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] XJavaDoc problem
Can you post a stacktrace? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mathias > Bogaert > Sent: 11. juli 2002 07:55 > To: [EMAIL PROTECTED] > Subject: [Xdoclet-devel] XJavaDoc problem > > > I think there is a problem with > http://cvs.xdoclet.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xja > vadoc/src/ > xjavadoc/XJavaDoc.java.diff?r1=1.44&r2=1.45 > > The thing is that when the a super class of a XClass does not exist on the > classpath (as source or in a binary), I get a nullpointer. As I > have almost > no knowledge of XJavaDoc, I dunno how to fix this. When I put the jar with > the missing class on the classpath, it works. > > Mathias > > > > --- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > ___ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: [Xdoclet-devel] XJavaDoc problem
Here you go: [ejbdoclet] 0 [main] INFO ModuleFinder.findModules - Registering XDoclet modules (searching for jars containing META-INF/xdoclet.xml) ... [ejbdoclet] Running [ejbdoclet] --> etm.farrago.value.AccountValue [ejbdoclet] 3335 [main] ERROR TemplateEngine.invokeMethod - Invoking method failed: xdoclet.modules.ejb.entity.PersistentTagsHandler.forAllPersistentFields, line=19 of template file: jar:file:C:\java\development\etm\lib\xdoclet-ejb-module.jar!/xdoclet/modules /ejb/entity/resources/valueobject.xdt [ejbdoclet] java.lang.reflect.InvocationTargetException: [ejbdoclet] java.lang.NullPointerException [ejbdoclet] at xdoclet.modules.ejb.entity.PersistentTagsHandler.forAllPersistentMatchedFiel ds(PersistentTagsHandler.java:441) [ejbdoclet] at xdoclet.modules.ejb.entity.PersistentTagsHandler.forAllPersistentFields(Pers istentTagsHandler.java:310) [ejbdoclet] at java.lang.reflect.Method.invoke(Native Method) [ejbdoclet] at xdoclet.template.TemplateEngine.invoke(TemplateEngine.java:577) [ejbdoclet] at xdoclet.template.TemplateEngine.invokeMethod(TemplateEngine.java:476) [ejbdoclet] at xdoclet.template.TemplateEngine.invokeBlockMethod(TemplateEngine.java:897) [ejbdoclet] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:864) [ejbdoclet] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [ejbdoclet] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [ejbdoclet] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [ejbdoclet] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:777) [ejbdoclet] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:719) [ejbdoclet] at xdoclet.modules.ejb.entity.ValueObjectSubTask.generateForClass(ValueObjectSu bTask.java:197) [ejbdoclet] at xdoclet.TemplateSubTask.startProcessPerClass(TemplateSubTask.java:611) [ejbdoclet] at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:551) [ejbdoclet] at xdoclet.TemplateSubTask.execute(TemplateSubTask.java:489) [ejbdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:46) [ejbdoclet] at xdoclet.DocletTask.start(DocletTask.java:347) [ejbdoclet] at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:66) [ejbdoclet] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java) [ejbdoclet] at org.apache.tools.ant.Task.perform(Task.java) [ejbdoclet] at org.apache.tools.ant.Target.execute(Target.java) [ejbdoclet] at org.apache.tools.ant.Target.performTasks(Target.java) [ejbdoclet] at org.apache.tools.ant.Project.executeTarget(Project.java) [ejbdoclet] at org.apache.tools.ant.Project.executeTargets(Project.java) [ejbdoclet] at org.apache.tools.ant.Main.runBuild(Main.java) [ejbdoclet] at org.apache.tools.ant.Main.start(Main.java) [ejbdoclet] at org.apache.tools.ant.Main.main(Main.java) [ejbdoclet] 3445 [main] ERROR XDocletMain.start - Running XDoclet failed. [ejbdoclet] 3455 [main] ERROR XDocletMain.start - <> [ejbdoclet] xdoclet.template.TemplateException: Invoking method in class xdoclet.modules.ejb.entity.PersistentTagsHandler failed: forAllPersistentFields, line=19 of template file: jar:file:C:\java\development\etm\lib\xdoclet-ejb-module.jar!/xdoclet/modules /ejb/entity/resources/valueobject.xdt, excep tion: null [ejbdoclet] at xdoclet.template.TemplateEngine.invokeMethod(TemplateEngine.java:484) [ejbdoclet] at xdoclet.template.TemplateEngine.invokeBlockMethod(TemplateEngine.java:897) [ejbdoclet] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:864) [ejbdoclet] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [ejbdoclet] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [ejbdoclet] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [ejbdoclet] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:777) [ejbdoclet] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:719) [ejbdoclet] at xdoclet.modules.ejb.entity.ValueObjectSubTask.generateForClass(ValueObjectSu bTask.java:197) [ejbdoclet] at xdoclet.TemplateSubTask.startProcessPerClass(TemplateSubTask.java:611) [ejbdoclet] at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:551) [ejbdoclet] at xdoclet.TemplateSubTask.execute(TemplateSubTask.java:489) [ejbdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:46) [ejbdoclet] at xdoclet.DocletTask.start(DocletTask.java:347) [ejbdoclet] at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:66) [ejbdoclet] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java) [ejbdoclet] at org.apache.tools.ant.Task.perform(Task.java) [ejbdoclet] at org.apache.tools.ant.Target.execute(Target.java) [ejbdoclet] at org.apache.tools.ant.Target.performTasks(Target.java) [ejbdoclet] at org.apache.tools.ant.Project.executeTarget(Project.java) [ejbdoclet]
[Xdoclet-devel] CVS update: xjavadoc/src/xjavadoc UnknownClass.java
User: rinkrank Date: 02/07/10 14:18:10 Modified:src/xjavadoc UnknownClass.java Log: Set UnknownClass' superclass to java.lang.Object to avoid NPE Revision ChangesPath 1.14 +6 -1 xjavadoc/src/xjavadoc/UnknownClass.java Index: UnknownClass.java === RCS file: /cvsroot/xdoclet/xjavadoc/src/xjavadoc/UnknownClass.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -w -r1.13 -r1.14 --- UnknownClass.java 10 Jul 2002 01:01:42 - 1.13 +++ UnknownClass.java 10 Jul 2002 21:18:10 - 1.14 @@ -28,11 +28,16 @@ * @param qualifiedName Describe what the parameter does * @todo-javadoc Write javadocs for constructor * @todo-javadoc Write javadocs for method parameter + * @todo We're setting super to java.lang.Object, but if an + * instance represents an unknown interface, then the superclass should be + * null. How do we know whether an instance represents a class or an + * interface? (Aslak) */ public UnknownClass( String qualifiedName ) { super( null, qualifiedName ); - + // We don't know what our class is, so we'll set it to Object. + setSuperclass( "java.lang.Object" ); instanceCount++; } --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xjavadoc/test Hello.java
User: rinkrank Date: 02/07/10 14:18:10 Modified:test Hello.java Log: Set UnknownClass' superclass to java.lang.Object to avoid NPE Revision ChangesPath 1.13 +1 -1 xjavadoc/test/Hello.java Index: Hello.java === RCS file: /cvsroot/xdoclet/xjavadoc/test/Hello.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -w -r1.12 -r1.13 --- Hello.java10 Jul 2002 01:01:42 - 1.12 +++ Hello.java10 Jul 2002 21:18:10 - 1.13 @@ -12,7 +12,7 @@ * tea="bad" * */ -class Hello implements Remote, Serializable { +class Hello extends DoesntExist implements Remote, Serializable { /** * Braba papa, barba mama, baraba brother, barba sister --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/ejb/src/xdoclet/modules/ejb/entity PersistentTagsHandler.java
User: rinkrank Date: 02/07/10 14:18:10 Modified:modules/ejb/src/xdoclet/modules/ejb/entity PersistentTagsHandler.java Log: Set UnknownClass' superclass to java.lang.Object to avoid NPE Revision ChangesPath 1.9 +6 -2 xdoclet/modules/ejb/src/xdoclet/modules/ejb/entity/PersistentTagsHandler.java Index: PersistentTagsHandler.java === RCS file: /cvsroot/xdoclet/xdoclet/modules/ejb/src/xdoclet/modules/ejb/entity/PersistentTagsHandler.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -w -r1.8 -r1.9 --- PersistentTagsHandler.java10 Jul 2002 01:07:01 - 1.8 +++ PersistentTagsHandler.java10 Jul 2002 21:18:09 - 1.9 @@ -27,7 +27,7 @@ * @author Ara Abrahamian ([EMAIL PROTECTED]) * @created Oct 16, 2001 * @xdoclet.taghandler namespace="EjbPersistent" - * @version $Revision: 1.8 $ + * @version $Revision: 1.9 $ */ public class PersistentTagsHandler extends CmpTagsHandler { @@ -438,7 +438,11 @@ } // Add super class info -if (getCurrentClass().getSuperclass().getQualifiedName().equals("java.lang.Object")) { + XClass cur = getCurrentClass(); + XClass sup = cur.getSuperclass(); + String qname = sup.getQualifiedName(); + boolean top = qname.equals("java.lang.Object"); +if (top) { popCurrentClass(); break; } --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] XJavaDoc problem
Should be OK now. Aslak > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mathias > Bogaert > Sent: 11. juli 2002 07:55 > To: [EMAIL PROTECTED] > Subject: [Xdoclet-devel] XJavaDoc problem > > > I think there is a problem with > http://cvs.xdoclet.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xja > vadoc/src/ > xjavadoc/XJavaDoc.java.diff?r1=1.44&r2=1.45 > > The thing is that when the a super class of a XClass does not exist on the > classpath (as source or in a binary), I get a nullpointer. As I > have almost > no knowledge of XJavaDoc, I dunno how to fix this. When I put the jar with > the missing class on the classpath, it works. > > Mathias > > > > --- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > ___ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xjavadoc/src/xjavadoc UnknownClass.java
User: rinkrank Date: 02/07/10 14:21:20 Modified:src/xjavadoc UnknownClass.java Log: Comment typo Revision ChangesPath 1.15 +1 -1 xjavadoc/src/xjavadoc/UnknownClass.java Index: UnknownClass.java === RCS file: /cvsroot/xdoclet/xjavadoc/src/xjavadoc/UnknownClass.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -w -r1.14 -r1.15 --- UnknownClass.java 10 Jul 2002 21:18:10 - 1.14 +++ UnknownClass.java 10 Jul 2002 21:21:20 - 1.15 @@ -36,7 +36,7 @@ public UnknownClass( String qualifiedName ) { super( null, qualifiedName ); - // We don't know what our class is, so we'll set it to Object. + // We don't know what our superclass is, so we'll set it to java.lang.Object to avoid NPE. setSuperclass( "java.lang.Object" ); instanceCount++; } --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/xdocs tools.xml
User: pathoss Date: 02/07/10 14:28:32 Added: xdocstools.xml Log: Moved to XDocs. Revision ChangesPath 1.1 xdoclet/xdocs/tools.xml Index: tools.xml === Tools Aslak Hellesoy XDoclet's popularity has resulted in a number of related tools, all of which are either in alpha state, or not started. This document gives a brief description of these tools. Comments and thoughts about these tools are most welcome, and should be sent to mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] (Middlegen has its own mailing list: mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]). XJavadoc is a clone of Sun's javadoc core. It has code mutation capabilities for inserting and modifying tags in existing source code in the following way: XClass[] classes = _xj.classes(); SourceClass clazz = (SourceClass)classes[0]; // get the doIt( java.lang.String[] s, int i ) method XMethod method = clazz.getMethod("doIt", new String[]{"java.lang.String[]", "int"}); // get the javadoc SourceDoc doc = (SourceDoc)method.doc(); // modify a tag parameter XTag tag = doc.tag("numbers"); XTagParameter tagParameter = tag.getParameter("three", true); tagParameter.setValue("trois"); File modifiedDir = new File("modified"); String fileName = ((SourceClass)classes[0]).save(modifiedDir ); XJavadoc is used by XDoclet GUI to insert/modify tags in existing source code. XJavadoc will be used by the upcoming Reverse XDoclet. XJavadoc will be used by XDoclet (once XJavadoc is mature enough), and hopefully provide faster parsing and avoid some shortcomings such as warnings. XJavadoc will also remove the burden of parsing tag parameters from XDoclet. (See http://boss.bekk.no/boss/middlegen/";>http://boss.bekk.no/boss/middlegen/) Middlegen will be refactored into smaller pieces and work as a plugin for XDoclet GUI, which will be a more generalised GUI for XDoclet. The planned sub components of middlegen are: core core The core is a non gui component that reads JDBC metadata and generates an XML file describing the tables and the relationships in an existing database. The XML file will be inspired from EJB deployment descriptors, and serve as input for the GUI component code generator The code generator will create XDoclet tag annotated java source files. It will use XDoclet's template engine in stead of out.print() as it does today. The generated code will be based on the xml read by the core, and the settings set in the gui. gui The gui component will provide the main panel showing relationships, and configuration panels that will influence how the generated code will be. It will be written in a way that lets it integrate with the more general XDoclet gui. XDoclet GUI is a tag editor for existing source code. It provides tool tips for each tag/tag parameter taken from the xtags xml. It will only let you insert tags that are appropriate for the selected class/method. XDoclet GUI can also be integrated into IDEs such as Forte/NetBeans, JBuilder and IntelliJ IDEA. Here is a screenshot of the current state of the tool: Source code is available in the XDoclet CVS, as a separate xdocletgui module. XTags is a tool that can validate tags in source code. It can be used by XDoclet to validate tags, or by XDoclet GUI to decide what tags should be available in the panel for a selected class/method. Source code is currently available from http://www.pribluda.de/xtags.tar.gz";>http://www.pribluda.de/xtags.tar.gz and is developed by Konstantin Pribluda (mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]). There is an alternative implementation of xtags in the xdocletgui module. XDoclet GUI's xtags and Konstantin's xtags will probably be merged together and be moved under the xdoclet module in the future. The (not started) Reverse XDoclet tool will automatically insert tags into existing source code that doesn't have XDoclet tags. This will be done by parsing existing deployment descriptors and take advantage of xjavadoc's doc mutation features. The main purpose of Reverse XDoclet is to make it
[Xdoclet-devel] CVS update: xdoclet/docs/info tools.html
User: pathoss Date: 02/07/10 14:28:32 Removed: docs/info tools.html Log: Moved to XDocs. --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] Missing in one-to-many relationship (Possible JBossSubTask jbosscmp-jdbc.xml bug)
The following javadoc: /** * Get the fills * * @ejb:interface-method view-type="local" * * @ejb:relation *name="Orders-Fills" *role-name="one-Order-has-many-Fills" *target-role-name="one-Fill-belongs-to-one-Order" *target-ejb="Fills" *target-multiple="no" * * @jboss:target-relation *fk-constaint="false" *fk-column="ORDERID" *related-pk-field="orderid" * */ public abstract java.util.Set getFills(); /** * Set the fills * * @ejb:interface-method view-type="local" **/ public abstract void setFills(java.util.Set fills); Creates the following jbosscmp-jdbc.xml Orders-Fills one-Fill-belongs-to-one-Order one-Order-has-many-Fills Notice the missing key-fields on the "one-Order-has-many-Fills" Running xDoclet with debug logging revealed that the relationship is swaped and that the the string representation of the RelationHolder is relation: RelationHolder left=null.null right=com.brockhousecooper.tw.ejb.beans.OrdersBean.java.util.Set getFills() The left side is null. Is this normal? Is this my fault or xDoclet's? Philippe --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/ejb/src/xdoclet/modules/ejb/entity/resources valueobject.xdt
User: pathoss Date: 02/07/10 14:49:24 Modified:modules/ejb/src/xdoclet/modules/ejb/entity/resources valueobject.xdt Log: Fixed bug 577891: soft-locking version field long or int? Revision ChangesPath 1.5 +3 -3 xdoclet/modules/ejb/src/xdoclet/modules/ejb/entity/resources/valueobject.xdt Index: valueobject.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/ejb/src/xdoclet/modules/ejb/entity/resources/valueobject.xdt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -w -r1.4 -r1.5 --- valueobject.xdt 4 Jul 2002 20:31:35 - 1.4 +++ valueobject.xdt 10 Jul 2002 21:49:24 - 1.5 @@ -30,7 +30,7 @@ private pk; - private long _version = 0; + private int _version = 0; public () @@ -179,11 +179,11 @@ - public long getVersion() + public int getVersion() { return _version; } - public void setVersion(long version) + public void setVersion(int version) { this._version = version; } --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/resources jboss_xml.xdt
User: pathoss Date: 02/07/10 15:12:27 Modified:modules/jboss/src/xdoclet/modules/jboss/ejb/resources jboss_xml.xdt Log: Applied patch 579235: JBoss resource-manager fails. Revision ChangesPath 1.5 +0 -8 xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/resources/jboss_xml.xdt Index: jboss_xml.xdt === RCS file: /cvsroot/xdoclet/xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/resources/jboss_xml.xdt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -w -r1.4 -r1.5 --- jboss_xml.xdt 27 Jun 2002 21:03:13 - 1.4 +++ jboss_xml.xdt 10 Jul 2002 22:12:27 - 1.5 @@ -148,18 +148,10 @@ - - - - - - - - --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb JBossTagsHandler.java
User: pathoss Date: 02/07/10 15:12:27 Modified:modules/jboss/src/xdoclet/modules/jboss/ejb JBossTagsHandler.java Log: Applied patch 579235: JBoss resource-manager fails. Revision ChangesPath 1.4 +1 -24 xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/JBossTagsHandler.java Index: JBossTagsHandler.java === RCS file: /cvsroot/xdoclet/xdoclet/modules/jboss/src/xdoclet/modules/jboss/ejb/JBossTagsHandler.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -w -r1.3 -r1.4 --- JBossTagsHandler.java 12 Jun 2002 23:31:32 - 1.3 +++ JBossTagsHandler.java 10 Jul 2002 22:12:26 - 1.4 @@ -23,33 +23,10 @@ * @author Dmitri Colebatch ([EMAIL PROTECTED]) * @created October 18, 2001 * @xdoclet.taghandler namespace="JBoss" - * @version $Revision: 1.3 $ + * @version $Revision: 1.4 $ */ public class JBossTagsHandler extends ClassTagsHandler { -/** - * Describe what the method does - * - * @return Describe the return value - * @exception XDocletException Describe the exception - */ -public String jBossResourceClassName() throws XDocletException -{ -Log log = LogUtil.getLog(JBossTagsHandler.class, "jBossResourceClassName"); - -if (log.isDebugEnabled()) { -log.debug("Searching @jboss:resource-manager res-man-class for Class " + getCurrentClass().getName()); -} - -Properties prop = new Properties(); - -prop.setProperty("tagName", "jboss:resource-manager"); -prop.setProperty("paramName", "res-man-class"); -prop.setProperty("paramNum", "0"); - -return classTagValue(prop); -} - /** * Evaluates the body if at least one of the classes has an jboss:dvc tag, otherwise not. * --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/modules/jboss/src/META-INF xtags.xml
User: pathoss Date: 02/07/10 15:12:26 Modified:modules/jboss/src/META-INF xtags.xml Log: Applied patch 579235: JBoss resource-manager fails. Revision ChangesPath 1.4 +0 -5 xdoclet/modules/jboss/src/META-INF/xtags.xml Index: xtags.xml === RCS file: /cvsroot/xdoclet/xdoclet/modules/jboss/src/META-INF/xtags.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -w -r1.3 -r1.4 --- xtags.xml 10 Jul 2002 01:07:02 - 1.3 +++ xtags.xml 10 Jul 2002 22:12:26 - 1.4 @@ -263,11 +263,6 @@ - res-man-class - Define the class of the resource manager - true - - res-man-name Define the name of the resource manager. true --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] file: URLs in modules' build files
The various modules' build.xml contains ]> Does it need the file: prefix, or can I change them to just ../modules-common.xml? They still seem to build okay for me, and it stops Netbeans thinking there's an XML parse error... Apparently, file: makes it be interpreted (by design) as relative to the JVM's current directory; without it, it's relative to the document. Don't know if that's just Netbeans or more general, though I notice the ModulesGrandBuilder does a ant.setDir(module.getBaseDir()); at the start of building each one. Andrew. --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] Missing in one-to-many relationship (Possible JBossSubTask jbosscmp-jdbc.xml bug)
what version? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Philippe > Caya > Sent: 10. juli 2002 23:39 > To: [EMAIL PROTECTED] > Subject: [Xdoclet-devel] Missing in one-to-many > relationship (Possible JBossSubTask jbosscmp-jdbc.xml bug) > > > The following javadoc: > > /** > * Get the fills > * > * @ejb:interface-method view-type="local" > * > * @ejb:relation > *name="Orders-Fills" > *role-name="one-Order-has-many-Fills" > *target-role-name="one-Fill-belongs-to-one-Order" > *target-ejb="Fills" > *target-multiple="no" > * > * @jboss:target-relation > *fk-constaint="false" > *fk-column="ORDERID" > *related-pk-field="orderid" > * > */ >public abstract java.util.Set getFills(); > > /** > * Set the fills > * > * @ejb:interface-method view-type="local" > **/ >public abstract void setFills(java.util.Set fills); > > > Creates the following jbosscmp-jdbc.xml > > > > Orders-Fills > > > > one-Fill-belongs-to-one-Order > > > > > > one-Order-has-many-Fills > > > > > > > > Notice the missing key-fields on the "one-Order-has-many-Fills" > Running xDoclet with debug logging revealed that the relationship > is swaped > and that the the string representation of the RelationHolder is > relation: RelationHolder left=null.null > right=com.brockhousecooper.tw.ejb.beans.OrdersBean.java.util.Set > getFills() > The left side is null. Is this normal? > > Is this my fault or xDoclet's? > > Philippe > > > --- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > ___ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] file: URLs in modules' build files
It shouldn't make any difference if you change it. I've tried both, and both work in the console. Aslak > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew > Stevens > Sent: 11. juli 2002 00:47 > To: [EMAIL PROTECTED] > Subject: [Xdoclet-devel] file: URLs in modules' build files > > > The various modules' build.xml contains > > > ]> > > Does it need the file: prefix, or can I change them to just > ../modules-common.xml? They still seem to build okay for me, and > it stops > Netbeans thinking there's an XML parse error... Apparently, file: makes > it be interpreted (by design) as relative to the JVM's current directory; > without it, it's relative to the document. Don't know if that's just > Netbeans or more general, though I notice the ModulesGrandBuilder does a > ant.setDir(module.getBaseDir()); at the start of building each one. > > > Andrew. > > > --- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > ___ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] doc future
cc to the geeks > -Original Message- > From: Mathias Bogaert [mailto:[EMAIL PROTECTED]] > Sent: 11. juli 2002 09:23 > To: Aslak Hellesøy > Subject: Re: [Xdoclet-devel] XJavaDoc problem > > > I think the docs are a little messy right now. > > 1. the xtree is generated on every page (heavy), and pushes the right > content too much to the right (try 800x600, not that I'm using it ;-)) I know, it's bad. All content of the elements in blabla.xml xdocs should line-break to avoid too broad content. > 2. too many different layout styles Agree. > 3. not linked together > 4. no navigation on much pages 3,4: Agree, that's what I meant by "part of the site" > > I propose the following: > > 1. use the style of tigris (Maven uses this too) everywhere > 2. move the xtree back into a frame, OR use the maven documentation > navigation (have to investigate on this), OR build a web application with > SiteMesh (but this is not static) > 3. link everything together > I guess it all depends on the required effort. It's kind of like xjavadoc. The whole XDoclet team uses it, but only a few of us know the internals of it. -And that's okay. It should be the same way with the docs. We'll all write docs, but given the complexity of how they are generated and linked together, we can't expect more than one or two of us to master that process, you being one of them I think. Static pages is really a must. We can't force our large user base to either be online or have a web container up and running all the time. (I am such a person myself). As long as we (the whole team) don't have to worry about anything else than writing docs in a simple format, then any doc generation scheme will be OK I think. > I can put in some work for 2 days, but I'm off for vacation from 12th of > july till the 28th. > I think you're the one with the best overview of different doc mechanisms, so it's cool if you can come up with a better doc framework. But the rest of us should be able to continue writing docs while you're on holiday. > Mathias > > - Original Message - > From: "Aslak Hellesøy" <[EMAIL PROTECTED]> > To: "Mathias Bogaert" <[EMAIL PROTECTED]> > Sent: Wednesday, July 10, 2002 3:08 PM > Subject: RE: [Xdoclet-devel] XJavaDoc problem > > > > > > > > > -Original Message- > > > From: Mathias Bogaert [mailto:[EMAIL PROTECTED]] > > > Sent: 11. juli 2002 08:44 > > > To: Aslak Hellesøy > > > Subject: Re: [Xdoclet-devel] XJavaDoc problem > > > > > > > > > Thanks! > > > > > > Mathias > > > > > > BTW how do you feel about the current state of the documentation? > > > > > > > In general, usable. They look quite good too. > > > > TAG DOCS: > > The framework for generating tag docs is quite good. I think we should > > generate them as "part of" the site, > > so they too have the left nav-tree. Further, I think there should be a > > sub-node à la: > > Tag Documentation > > +--apache > >+--Class tags > >+--Method tags > > > > for easier navigation. There are already #anchors in the tag docs. > > > > TASK/SUBTASK DOCS > > Same comment about "part of" the site. Needs stylesheets. Could you do > that? > > I will do the remaining work with the generation part, based on a > discussion > > I had with Erik Hatcher a few weeks back about how to @tag > them. There are > > too many attributes in them right now. > > > > GENERAL PROSE DOCS > > I think there is still a bit to do here. Architecture has > changed quite a > > bit, and based on our knowledge about common questions, I think they can > > still be improved. We should look at the Velocity docs for inspiration. > When > > I was new to Velocity a few months back, I got the picture of how to use > it > > in no time! If we spend more time here, we'll spend less time later > > answering stupid questions. > > > > What's your feeling about the docs? > > > > Cheers, > > Aslak > > > > > - Original Message - > > > From: "Aslak Hellesøy" <[EMAIL PROTECTED]> > > > To: "Mathias Bogaert" <[EMAIL PROTECTED]>; > > > <[EMAIL PROTECTED]> > > > Sent: Wednesday, July 10, 2002 2:17 PM > > > Subject: RE: [Xdoclet-devel] XJavaDoc problem > > > > > > > > > > Should be OK now. > > > > > > > > Aslak > > > > > > > > > -Original Message- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > Mathias > > > > > Bogaert > > > > > Sent: 11. juli 2002 07:55 > > > > > To: [EMAIL PROTECTED] > > > > > Subject: [Xdoclet-devel] XJavaDoc problem > > > > > > > > > > > > > > > I think there is a problem with > > > > > http://cvs.xdoclet.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xja > > > > > vadoc/src/ > > > > > xjavadoc/XJavaDoc.java.diff?r1=1.44&r2=1.45 > > > > > > > > > > The thing is that when the a super class of a XClass does > not exist > on > > > the > > > > > classpath (as source or in a binary), I get a nullpointer. As I > > > > > have almost > > > > > no knowledge of XJavaDoc, I dunno how to fix this. When I put the > jar > > > with > > > > > the missing cl
RE: [Xdoclet-devel] XDocletGUI cvs broken?
A wise old hermit known only as =?us-ascii?Q?Aslak_Hellesoy?= <[EMAIL PROTECTED]> once said: > 1) Start on some design documents under xdoclet/xdocs where we can > start to > describe our ideas for the xtags architecture (and also Velocity). When > we agree on how to proceed, move to 2). > 2) Make a branch e.g. XTAGS_REFACTORING on the xdoclet module and start > moving over the xtags stuff from xdocletgui. This will have no impact > on the forthcoming XDoclet 1.2 release. > > Any thoughts on this? IMO we should concentrate on getting 1.2 ready first, before we worry about anything else (especially if we want to take any time over its design). It's not as if we're being swamped with complaints over on xdoclet-user that xdocletgui's broken... Andrew. --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS update: xdoclet/core/src/xdoclet/tagshandler AbstractProgramElementTagsHandler.java
User: rinkrank Date: 02/07/10 17:13:49 Modified:core/src/xdoclet/tagshandler AbstractProgramElementTagsHandler.java Log: Fixed bug [ 578820 ] ejbRemove() no RemoveException Revision ChangesPath 1.6 +7 -6 xdoclet/core/src/xdoclet/tagshandler/AbstractProgramElementTagsHandler.java Index: AbstractProgramElementTagsHandler.java === RCS file: /cvsroot/xdoclet/xdoclet/core/src/xdoclet/tagshandler/AbstractProgramElementTagsHandler.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -w -r1.5 -r1.6 --- AbstractProgramElementTagsHandler.java10 Jul 2002 18:29:12 - 1.5 +++ AbstractProgramElementTagsHandler.java11 Jul 2002 00:13:49 - 1.6 @@ -35,7 +35,7 @@ /** * @authorAra Abrahamian ([EMAIL PROTECTED]) * @created Oct 15, 2001 - * @version $Revision: 1.5 $ + * @version $Revision: 1.6 $ */ public abstract class AbstractProgramElementTagsHandler extends XDocletTagSupport { @@ -397,7 +397,7 @@ } if (executableMember == null && memberName == null) { -return ""; +exceptions = new XClass[0]; } if (memberName == null) { @@ -407,11 +407,12 @@ executableMember = getXExecutableMemberForMemberName(memberName, true, forType); // no member with the specified name found in class -if (executableMember == null) { -return ""; -} - +if (executableMember != null) { exceptions = executableMember.getThrownExceptions(); +} +else { +exceptions = new XClass[0]; +} } StringBuffer sbuf = new StringBuffer(); --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: [Xdoclet-devel] Missing in one-to-many relationship(Possible JBossSubTask jbosscmp-jdbc.xml bug)
Aslak Hellesøy wrote: >what version? > Sorry about the omission... JBoss 3.0 RC3 xDoclet checked out last week from the cvs (I'll run a diff in the morning to make sure it hasn't changed since) > > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of Philippe >>Caya >>Sent: 10. juli 2002 23:39 >>To: [EMAIL PROTECTED] >>Subject: [Xdoclet-devel] Missing in one-to-many >>relationship (Possible JBossSubTask jbosscmp-jdbc.xml bug) >> >> >>The following javadoc: >> >>/** >> * Get the fills >> * >> * @ejb:interface-method view-type="local" >> * >> * @ejb:relation >> *name="Orders-Fills" >> *role-name="one-Order-has-many-Fills" >> *target-role-name="one-Fill-belongs-to-one-Order" >> *target-ejb="Fills" >> *target-multiple="no" >> * >> * @jboss:target-relation >> *fk-constaint="false" >> *fk-column="ORDERID" >> *related-pk-field="orderid" >> * >> */ >> public abstract java.util.Set getFills(); >> >> /** >> * Set the fills >> * >> * @ejb:interface-method view-type="local" >> **/ >> public abstract void setFills(java.util.Set fills); >> >> >>Creates the following jbosscmp-jdbc.xml >> >> >> >> Orders-Fills >> >> >> >> one-Fill-belongs-to-one-Order >> >> >> >> >> >> one-Order-has-many-Fills >> >> >> >> >> >> >> >>Notice the missing key-fields on the "one-Order-has-many-Fills" >>Running xDoclet with debug logging revealed that the relationship >>is swaped >>and that the the string representation of the RelationHolder is >>relation: RelationHolder left=null.null >>right=com.brockhousecooper.tw.ejb.beans.OrdersBean.java.util.Set >>getFills() >>The left side is null. Is this normal? >> >>Is this my fault or xDoclet's? >> >>Philippe >> >> >> >> >> --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel