[Xdoclet-devel] Struts forms futures

2002-07-10 Thread Brian Topping

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

2002-07-10 Thread noreply

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?

2002-07-10 Thread "Bernard, Jérôme"








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

2002-07-10 Thread Konstantin Priblouda



> <[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

2002-07-10 Thread Jérôme BERNARD

> 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

2002-07-10 Thread Konstantin Priblouda


> 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?

2002-07-10 Thread Aslak Hellesøy

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

2002-07-10 Thread Jérôme BERNARD

> 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

2002-07-10 Thread Konstantin Priblouda


--- 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?

2002-07-10 Thread Konstantin Priblouda


--- 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

2002-07-10 Thread Boris Tamarkin
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

2002-07-10 Thread MNewcomb

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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Marcus Brito

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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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?

2002-07-10 Thread Aslak Hellesoy



> -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

2002-07-10 Thread Aslak Hellesøy
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

2002-07-10 Thread Aslak Helles?y

  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

2002-07-10 Thread noreply

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

2002-07-10 Thread noreply

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

2002-07-10 Thread noreply

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

2002-07-10 Thread noreply

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

2002-07-10 Thread noreply

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

2002-07-10 Thread noreply

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

2002-07-10 Thread noreply

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

2002-07-10 Thread Mathias Bogaert

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

2002-07-10 Thread Aslak Hellesøy

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

2002-07-10 Thread Mathias Bogaert

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

2002-07-10 Thread Aslak Helles?y

  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

2002-07-10 Thread Aslak Helles?y

  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

2002-07-10 Thread Aslak Helles?y

  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

2002-07-10 Thread Aslak Hellesøy

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

2002-07-10 Thread Aslak Helles?y

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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)

2002-07-10 Thread Philippe Caya

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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Mathias Bogaert

  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

2002-07-10 Thread Andrew Stevens

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)

2002-07-10 Thread Aslak Hellesøy

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

2002-07-10 Thread Aslak Hellesoy

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

2002-07-10 Thread Aslak Hellesøy

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?

2002-07-10 Thread Andrew Stevens

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

2002-07-10 Thread Aslak Helles?y

  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)

2002-07-10 Thread Philippe Caya

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