RE: [Xdoclet-devel] Doclipse
I've been busy on another project for a few weeks, so I'm just now getting
back to this e-mail...
Ultimately what I finally did was to ZIP them all up into the target
directory as part of the build. The specific filename is patterned as
follows: "${dist.dir}/${name}-doclipse-${version}.zip"
Now the question is how do I get the ZIP file to the SF file release area as
you suggested? Does that just automatically happen or is there something I
need to do in the build?
As for the XSLT question you had...I don't know. I've never had a need to
use multiple sources.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Andrew
> Stevens
> Sent: Wednesday, June 23, 2004 6:18 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Xdoclet-devel] Doclipse
>
>
> On Mon, 2004-06-21 at 20:04, Craig Walls wrote:
> > I just added this to the build. Right now, it just puts the
> Doclipse files
> > into the target/doclipse directory. Does anyone have any suggestions on
> > where they should ultimately reside? In a separate xdoclipse.zip file,
> > perhaps?
>
> If there's a whole bunch of them (I believe there's a file per module?),
> then a zip/tgz/jar is probably a good idea. We could either include
> that in with the docs, or just upload it to SF along with the other
> files and mention it in the docs somewhere. I'm inclined towards
> uploading it to the File Release area on SF; for one thing, they prefer
> that (the mirrors can help spread the load), plus it helps to boost our
> stats & ranking :-)
>
> While we're on the subject of XSLT, is it possible for an XSL to produce
> a single output file from a bunch of inputs? I've thought for a while
> now that it'd be useful if we could produce an external entity file, for
> Ant's javadoc task to include, which contained definitions of all the
> custom tags we use (based on the various xtags.xml contents)...
>
>
> Andrew.
>
>
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf Of Craig
> > > Walls
> > > Sent: Sunday, June 20, 2004 8:39 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [Xdoclet-devel] Doclipse
> > >
> > >
> > >
> > > Yeah...I thought about doing that, but I wrote the Doclipse XSLT very
> > > quickly during a lunch one day and just haven't had the time
> to make it a
> > > formal part of XDoclet's build. Good idea, though.
> > >
> > > If I free a few moments I'll try to slide it in later this week.
> > >
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] Behalf
> Of Andrew
> > > > Stevens
> > > > Sent: Saturday, June 19, 2004 6:19 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: [Xdoclet-devel] Doclipse
> > > >
> > > >
> > > > >From http://theserverside.com/news/thread.tss?thread_id=26625
> > > >
> > > > >XDoclet tags
> > > > >Posted By: Craig Walls on June 17, 2004 @ 09:08 PM in response to
> > > > >Message #126288 1 replies in this thread
> > > > >
> > > > >I just sent Cedric the Doclipse files for all of XDoclet 1.2.1's
> > > > >modules. In case you want to use them before he
> incorporates them into
> > > > >the next Doclipse release, you can find them here. The ZIP
> file also
> > > > >includes an XSLT file that I used to transform XDoclet's
> own xtags.xml
> > > > >files (used to generate XDoclet's documentation) into
> Doclipse files.
> > > >
> > > > How about adding this into the build, so when there's new versions
> > > > and/or xtags get changed it'll automatically generate the
> updated files
> > > > ready to drop into Doclipse? We could include them on the IDE
> > > > Integration page of the docs (the page with the IDEA live
> templates).
> > > >
> > > >
> > > > Andrew.
>
>
>
> ---
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> ___
> xdoclet-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] 1.2.2
Hi, I just saw that JSF patches got submitted. I will try to incorporate them at the weekend. So hold the release until then -- I think this will be a real goodie. Heiko --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
RE: [Xdoclet-devel] [XDoclet-JIRA] Created: (XDT-951) Java Server Faces Support
Markus, >Key: XDT-951 >Summary: Java Server Faces Support > Type: New Feature > Reporter: Markus Plattner are you interested in adding the missing bits and pieces? Heiko --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] Configuring Struts and Spring together with XDoclet
Dear All, I'm using XDoclet while developing for a project that uses Spring and Struts together. I've found a small problem with this configuration in the way that the Struts-Spring plugin ( http://struts.sourceforge.net/struts-spring/ - although now part of the main spring distribution) operates. I haven't found anything mentioning this on the user or dev archives, so am posting my problem and solution to you all here apologies if this is inappropriate. When I create my Struts action class (say com.cygnite.test.struts.TestAction), which has properties configured through Spring, the entry I need in my struts-config.xml is: . . while in the Spring configuration file, I need: The 2 problems are: 1. XDoclet's struts module doesn't let you override the "type" attribute for the action, allowing you to specify a different class to instantiate for the action. 2. The spring module doesn't support the "name" attribute, and always specifies an ID attribute - I'm not absolutely sure whether it's ok or not to have the ID attribute there as well, although it might be cleaner and clearer if it wasn't there in this situation. Both problems are easily fixed by making small changes to the .xdt files for each module. I don't know how you like patches to be applied, so I'm explaining the differences here. If appropriate, could someone point me in the right direction on how to make patch files for the project? 1. In the /xdoclet/modules/apache/struts/resources/struts_config_xml.xdt file: path="" type="" becomes: path="" type="" type="" adding the type parameter to the struts.action tag override the standard behaviour of taking the full class name, which still remains the default if no type attribute is specified. 2. Adding to the xtags.xml file for the struts module, inside the struts.action tag definition: type The class to instantiate for this action. Defaults to the current class, but can be overridden for certain uses, such as integration with Spring. false 3. In the / Replacing: id="" with: id="" name="" whch makes the "id" and "name" parameters optional (I couldn't see a way to make a conditional validation to make sure at least one of them was present) 4. Adding to the xtags.xml file for the spring module, inside the spring.bean tag definition (the definition for the ID attribute wasn't present in the xtags file for some reason): id ID for the bean. This should be unique within the spring configuration. Either this property, or the "name" property must be specified for each bean. false name Name for the bean. This property can be used in place of the "id" attribute, where the name being used contains characters that would be invalid as an XML ID attribute. false This certainly provides me with a solution, although there are a few enhancements to be made (in particular creating the validation of at least one of the ID or name attributes being present in the spring.bean tag). I hope this is an acceptable solution for the rest of the community? Steve.
AW: [Xdoclet-devel] [XDoclet-JIRA] Created: (XDT-951) Java Server Faces Support
Heiko, I'm working on it, but I had to implement our project needs first Markus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Rupp, Heiko Gesendet: Donnerstag, 8. Juli 2004 14:59 An: [EMAIL PROTECTED] Betreff: RE: [Xdoclet-devel] [XDoclet-JIRA] Created: (XDT-951) Java Server Faces Support Markus, >Key: XDT-951 >Summary: Java Server Faces Support > Type: New Feature > Reporter: Markus Plattner are you interested in adding the missing bits and pieces? Heiko --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: [Xdoclet-devel] Configuring Struts and Spring together with XDoclet
You're probably one of the few folks that is using XDoclet with both Spring and Struts. If this change works for you, I'm willing to commit it. Please open a enhancement request in JIRA and post a patch. Thanks, Matt On Jul 8, 2004, at 8:14 AM, [EMAIL PROTECTED] wrote: Dear All, I'm using XDoclet while developing for a project that uses Spring and Struts together. I've found a small problem with this configuration in the way that the Struts-Spring plugin ( http://struts.sourceforge.net/struts-spring/ - although now part of the main spring distribution) operates. I haven't found anything mentioning this on the user or dev archives, so am posting my problem and solution to you all here apologies if this is inappropriate. When I create my Struts action class (say com.cygnite.test.struts.TestAction), which has properties configured through Spring, the entry I need in my struts-config.xml is: . . while in the Spring configuration file, I need: The 2 problems are: 1. XDoclet's struts module doesn't let you override the "type" attribute for the action, allowing you to specify a different class to instantiate for the action. 2. The spring module doesn't support the "name" attribute, and always specifies an ID attribute - I'm not absolutely sure whether it's ok or not to have the ID attribute there as well, although it might be cleaner and clearer if it wasn't there in this situation. Both problems are easily fixed by making small changes to the .xdt files for each module. I don't know how you like patches to be applied, so I'm explaining the differences here. If appropriate, could someone point me in the right direction on how to make patch files for the project? 1. In the /xdoclet/modules/apache/struts/resources/struts_config_xml.xdt file: path="" type="" becomes: path="" type="" type="" adding the type parameter to the struts.action tag override the standard behaviour of taking the full class name, which still remains the default if no type attribute is specified. 2. Adding to the xtags.xml file for the struts module, inside the struts.action tag definition: type The class to instantiate for this action. Defaults to the current class, but can be overridden for certain uses, such as integration with Spring. false 3. In the / Replacing: id="" with: id="" name="" whch makes the "id" and "name" parameters optional (I couldn't see a way to make a conditional validation to make sure at least one of them was present) 4. Adding to the xtags.xml file for the spring module, inside the spring.bean tag definition (the definition for the ID attribute wasn't present in the xtags file for some reason): id ID for the bean. This should be unique within the spring configuration. Either this property, or the "name" property must be specified for each bean. false name Name for the bean. This property can be used in place of the "id" attribute, where the name being used contains characters that would be invalid as an XML ID attribute. false This certainly provides me with a solution, although there are a few enhancements to be made (in particular creating the validation of at least one of the ID or name attributes being present in the spring.bean tag). I hope this is an acceptable solution for the rest of the community? Steve. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Created: (XDT-952) Using XDoclet to configure when using Struts-Spring plugin
Message: A new issue has been created in JIRA. - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-952 Here is an overview of the issue: - Key: XDT-952 Summary: Using XDoclet to configure when using Struts-Spring plugin Type: Improvement Status: Open Priority: Minor Original Estimate: 1 day Time Spent: Unknown Remaining: 1 day Project: XDoclet Components: Apache Module Spring Module Assignee: xdoclet-devel (Use for new issues) Reporter: Steve Storey Created: Thu, 8 Jul 2004 10:34 AM Updated: Thu, 8 Jul 2004 10:34 AM Environment: Windows 2000, JDK 1.4, but change not reliant on specific platform, Description: Change to allow integration between Struts and Spring easier. At the moment, the struts module does not allow you to override the "type" attribute on the struts.action tag, which you need to do to configure Struts to use the Spring DelegatingActionProxy class so that struts actions can be wired up using Spring configuration. Additionally, the spring module does not allow configuration of the "name" attribute on a bean, and forces the "id" attribute to be used at all times. Simple changes to the .xdt files for each module are required to implement this change. I've made the changes and will supply the patches to implement this change. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Created: (XDT-953) hibernate-mapping_2_0.dtd missing unsaved-value attribute for version element
Message: A new issue has been created in JIRA. - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-953 Here is an overview of the issue: - Key: XDT-953 Summary: hibernate-mapping_2_0.dtd missing unsaved-value attribute for version element Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XDoclet Versions: 1.2.1 Assignee: xdoclet-devel (Use for new issues) Reporter: Ed Wentworth Created: Thu, 8 Jul 2004 10:59 AM Updated: Thu, 8 Jul 2004 10:59 AM Environment: jvm 1.4.2_04 Description: Cannot use @hibernate.version xdoclet tag because it will not validate the generated hibernate mapping file (hbm.xml). The issue is that the supplied dtd (hibernate-mapping_2_0.dtd) in the xdoclet.modules.hibernate.resources package does not have the 'unsaved-value' attribute for the version element. Since the xdoclet template will always generate the default value for this attribute even if it is not specified in the supplied tag, validation will always fail for the version tag. The fix (diff) could be RCS file: /cvsroot/xdoclet/xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd,v retrieving revision 1.1 diff -u -r1.1 hibernate-mapping_2_0.dtd --- modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd 7 Oct 2003 22:46:00 - 1.1 +++ modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd 8 Jul 2004 15:36:33 - @@ -93,9 +93,11 @@ - + + + - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Updated: (XDT-953) hibernate-mapping_2_0.dtd missing unsaved-value attribute for version element
The following issue has been updated: Updater: Ed Wentworth (mailto:[EMAIL PROTECTED]) Date: Thu, 8 Jul 2004 11:02 AM Comment: diff file for change Changes: Attachment changed to xdoc-mod-hib-res-hib-map20-dtd.diff - For a full history of the issue, see: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-953?page=history - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-953 Here is an overview of the issue: - Key: XDT-953 Summary: hibernate-mapping_2_0.dtd missing unsaved-value attribute for version element Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XDoclet Versions: 1.2.1 Assignee: xdoclet-devel (Use for new issues) Reporter: Ed Wentworth Created: Thu, 8 Jul 2004 10:59 AM Updated: Thu, 8 Jul 2004 11:02 AM Environment: jvm 1.4.2_04 Description: Cannot use @hibernate.version xdoclet tag because it will not validate the generated hibernate mapping file (hbm.xml). The issue is that the supplied dtd (hibernate-mapping_2_0.dtd) in the xdoclet.modules.hibernate.resources package does not have the 'unsaved-value' attribute for the version element. Since the xdoclet template will always generate the default value for this attribute even if it is not specified in the supplied tag, validation will always fail for the version tag. The fix (diff) could be RCS file: /cvsroot/xdoclet/xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd,v retrieving revision 1.1 diff -u -r1.1 hibernate-mapping_2_0.dtd --- modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd 7 Oct 2003 22:46:00 - 1.1 +++ modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd 8 Jul 2004 15:36:33 - @@ -93,9 +93,11 @@ - + + + - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Updated: (XDT-952) Using XDoclet to configure when using Struts-Spring plugin
The following issue has been updated: Updater: Steve Storey (mailto:[EMAIL PROTECTED]) Date: Thu, 8 Jul 2004 11:10 AM Comment: Patch file containing changes to the XDT files for the apache and spring modules. Also contains appropriate changes to the xtags.xml for each module to document the changed attributes. My first patch, so please check I've done it from the right place, etc. before committing! Changes: Attachment changed to patch.diff - For a full history of the issue, see: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-952?page=history - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-952 Here is an overview of the issue: - Key: XDT-952 Summary: Using XDoclet to configure when using Struts-Spring plugin Type: Improvement Status: Open Priority: Minor Original Estimate: 1 day Time Spent: Unknown Remaining: 1 day Project: XDoclet Components: Apache Module Spring Module Assignee: xdoclet-devel (Use for new issues) Reporter: Steve Storey Created: Thu, 8 Jul 2004 10:34 AM Updated: Thu, 8 Jul 2004 11:10 AM Environment: Windows 2000, JDK 1.4, but change not reliant on specific platform, Description: Change to allow integration between Struts and Spring easier. At the moment, the struts module does not allow you to override the "type" attribute on the struts.action tag, which you need to do to configure Struts to use the Spring DelegatingActionProxy class so that struts actions can be wired up using Spring configuration. Additionally, the spring module does not allow configuration of the "name" attribute on a bean, and forces the "id" attribute to be used at all times. Simple changes to the .xdt files for each module are required to implement this change. I've made the changes and will supply the patches to implement this change. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: [Xdoclet-devel] Configuring Struts and Spring together with XDoclet
Matt, Issue with attached patch file is here: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-952 Please check I've done the patch correctly, Steve. [EMAIL PROTECTED] wrote on 08/07/2004 15:46:26: > You're probably one of the few folks that is using XDoclet with both > Spring and Struts. If this change works for you, I'm willing to commit > it. Please open a enhancement request in JIRA and post a patch. >
[Xdoclet-devel] [XDoclet-JIRA] Assigned: (XDT-953) hibernate-mapping_2_0.dtd missing unsaved-value attribute for version element
Message: The following issue has been re-assigned. Assignee: Heiko W. Rupp (mailto:[EMAIL PROTECTED]) - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-953 Here is an overview of the issue: - Key: XDT-953 Summary: hibernate-mapping_2_0.dtd missing unsaved-value attribute for version element Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XDoclet Versions: 1.2.1 Assignee: Heiko W. Rupp Reporter: Ed Wentworth Created: Thu, 8 Jul 2004 10:59 AM Updated: Thu, 8 Jul 2004 11:26 AM Environment: jvm 1.4.2_04 Description: Cannot use @hibernate.version xdoclet tag because it will not validate the generated hibernate mapping file (hbm.xml). The issue is that the supplied dtd (hibernate-mapping_2_0.dtd) in the xdoclet.modules.hibernate.resources package does not have the 'unsaved-value' attribute for the version element. Since the xdoclet template will always generate the default value for this attribute even if it is not specified in the supplied tag, validation will always fail for the version tag. The fix (diff) could be RCS file: /cvsroot/xdoclet/xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd,v retrieving revision 1.1 diff -u -r1.1 hibernate-mapping_2_0.dtd --- modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd 7 Oct 2003 22:46:00 - 1.1 +++ modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd 8 Jul 2004 15:36:33 - @@ -93,9 +93,11 @@ - + + + - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] CVS: xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources hibernate-mapping_2_0.dtd,1.1,1.2
Update of /cvsroot/xdoclet/xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21439/xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources Modified Files: hibernate-mapping_2_0.dtd Log Message: Fix from XDT-953. Index: hibernate-mapping_2_0.dtd === RCS file: /cvsroot/xdoclet/xdoclet/modules/hibernate/src/xdoclet/modules/hibernate/resources/hibernate-mapping_2_0.dtd,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** hibernate-mapping_2_0.dtd 7 Oct 2003 22:46:00 - 1.1 --- hibernate-mapping_2_0.dtd 8 Jul 2004 16:08:25 - 1.2 *** *** 94,100 ! --- 94,102 ! + + --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Assigned: (XDT-952) Using XDoclet to configure when using Struts-Spring plugin
Message: The following issue has been re-assigned. Assignee: Matt Raible (mailto:[EMAIL PROTECTED]) - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-952 Here is an overview of the issue: - Key: XDT-952 Summary: Using XDoclet to configure when using Struts-Spring plugin Type: Improvement Status: Open Priority: Minor Original Estimate: 1 day Time Spent: Unknown Remaining: 1 day Project: XDoclet Components: Apache Module Spring Module Assignee: Matt Raible Reporter: Steve Storey Created: Thu, 8 Jul 2004 10:34 AM Updated: Thu, 8 Jul 2004 11:47 AM Environment: Windows 2000, JDK 1.4, but change not reliant on specific platform, Description: Change to allow integration between Struts and Spring easier. At the moment, the struts module does not allow you to override the "type" attribute on the struts.action tag, which you need to do to configure Struts to use the Spring DelegatingActionProxy class so that struts actions can be wired up using Spring configuration. Additionally, the spring module does not allow configuration of the "name" attribute on a bean, and forces the "id" attribute to be used at all times. Simple changes to the .xdt files for each module are required to implement this change. I've made the changes and will supply the patches to implement this change. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: [Xdoclet-devel] Bug fix for XJavaDoc - what happend to XJD-43?
Yes, I would love commit access but I'm afraid I wouldn't know what to
do with it. Before I get in too deep I think I'd need a course on how
this stuff works. I'd love to contribute I'm just afraid that there's
too much involved. The last couple of times I tried to build XDoclet
from a CVS checkout I got stumped. I recently got hung up on the
XDoclet2 project trying to just checkout and build the dang thing. I'll
tell you what. I'll shut my mouth for the time being, read up on Maven
(which appears to be your build tool of choice) and try to figure out
how to at least do checkouts and builds through CVS. If you or anyone
can help me along the way I'd appreciate it. But let me 1st try to get
my feet wet with that 1st step.
Clifton C. Craig, Software Engineer
Intelligent Computer Systems - A Division of GBG
2101 Embassy Drive
Lancaster, PA 17603
Phone: 717-295-7977 ext. 621
Fax: 717-295-7683
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Mathias Bogaert wrote:
Clifton,
XDoclet developers are very busy with other project. Would you like
CVS commit access?
Mathias Bogaert
On 07 Jul 2004, at 22:37, Clifton C. Craig wrote:
I submitted an Issue to Jira back in March regarding a bug in the
XJavadoc engine. (See below.) I did this after repeatedly submitting
the problem and the fix to the mailing list. There (in JIRA) I posted
the code to fix the bug. The fix was very simple.I also posted a
reminder to the developer list after hearing talk of the next release
of XDoclet and noticing the issue was still unresolved in JIRA. I was
sure it would make it into the next release but it somehow didn't
make the cut. What did I do wrong? I was really hoping that the issue
would be fixed so that I don't have to hack the Jar the way that I've
been doing. If I knew how I would upload the fix directly to the
repository myself. What can I do to get this issue resolved?
Clifton C. Craig, Software Engineer
Intelligent Computer Systems - A Division of GBG
2101 Embassy Drive
Lancaster, PA 17603
Phone: 717-295-7977 ext. 621
Fax: 717-295-7683
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Clifton C. Craig wrote:
Andrew,
I opened an issue in JIRA. I'm not sure exactly how to go about
uploading a patch. I know little about CVS and open-source
practices. I did, however, copy my patch as a comment in JIRA. I
patch is extremely simple and minor (literally 3 lines of code) and
would probably be nothing to an experienced developer to
incorporate. I do not mind doing the patch myself though. I'd just
need someone to walk me through it. It would be a great start at
learning this stuff.
Clifton C. Craig, Software Engineer
Intelligent Computer Systems - A Division of GBG
2101 Embassy Drive
Lancaster, PA 17603
Phone: 717-295-7977 ext. 621
Fax: 717-295-7683
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Andrew Stevens wrote:
On Fri, 2004-03-26 at 20:53, Clifton C. Craig wrote:
I'm still waiting for advice on this topic. Any takers?
Strange, I don't think I saw your original message. Oh well. Can you
open an issue in JIRA
(http://opensource.atlassian.com/projects/xdoclet/) and upload the fix
there? That way things don't get missed. Thanks.
Andrew.
Clifton C. Craig, Software Engineer
Intelligent Computer Systems - A Division of GBG
2101 Embassy Drive
Lancaster, PA 17603
Phone: 717-295-7977 ext. 621
Fax: 717-295-7683
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Clifton C. Craig wrote:
Hello,
I'm a newcomer and I have a simple bug fix for XJavaDoc. I found
that saving source files to another folder would cause truncation
of the source. What I noticed was the FileWriter in the save
method of xjavadoc.SourceClass was not being flushed like the
Writer returned from the _sourceFile member when a root directory
is not given. My modifications are only to the save method and
include two lines of code. The source to the revised save method
is as follows:
/**
* Saves the class at root dir rootDir. The actual java file is
derived from
* tha package name. If no root dir is specified, save where it
was loaded from
*
* @param rootDir the root directory.
* @return the relative fileName to which the file
was saved.
* @throws IOException if the file couldn't be saved
*/
public String save( File rootDir ) throws IOException
{
if( !isWriteable() )
{
throw new UnsupportedOperationException( "Can't save
classes that aren't parsed in AST mode (do
getXJavaDoc().setUseNodeParser(true) before parsing starts!)" );
}
if( getContainingClass() != null )
{
// inner class. can't save these.
throw new UnsupportedOperationException( "Can't save
inner classes" );
}
else if( rootDir != null )
{
String fileName = getFileName( getQualifiedName() );
File javaFile = new File( rootDir, fileName );
javaFile.getParentFile().mkdirs();
FileWriter fwtr = new FileWriter( javaFile );
print( fwtr );
[Xdoclet-devel] [XDoclet-JIRA] Commented: (XJD-43) Truncates source when saving to a different file
The following comment has been added to this issue: Author: Matt Raible Created: Thu, 8 Jul 2004 1:33 PM Body: If you can submit a patch for this - it'd be much easier for us to fix. See instructions on main page for how to do this: http://opensource.atlassian.com/projects/xdoclet/secure/Dashboard.jspa - View this comment: http://opensource.atlassian.com/projects/xdoclet/browse/XJD-43?page=comments#action_14208 - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XJD-43 Here is an overview of the issue: - Key: XJD-43 Summary: Truncates source when saving to a different file Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XJavaDoc Versions: 1.0.1 1.0.2 Assignee: xdoclet-devel (Use for new issues) Reporter: Clifton C. Craig Created: Mon, 29 Mar 2004 7:55 AM Updated: Thu, 8 Jul 2004 1:33 PM Environment: API for SourceClass Description: The xjavadoc.SourceClass class has a bug that prevents you from saving modified source to a separate folder. The save() method in this class neglects to cache and flush the file writer when a root directory parameter is passed in. The flush is performed on a separate PrintWriter when a root directory is not passed in. This fix a very simple. I have a modified copy on my PC with the fix, which includes 3 extra lines of source. One to cache the FileWriter object into a local variable, and two more to flush and close the writer. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Updated: (XJD-43) Truncates source when saving to a different file
The following issue has been updated: Updater: Matt Raible (mailto:[EMAIL PROTECTED]) Date: Thu, 8 Jul 2004 1:39 PM Comment: This seems to be the patch you're looking for. I could commit it, but I want to verify with other devs that it's OK. Changes: Attachment changed to SourceClass.java.patch - For a full history of the issue, see: http://opensource.atlassian.com/projects/xdoclet/browse/XJD-43?page=history - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XJD-43 Here is an overview of the issue: - Key: XJD-43 Summary: Truncates source when saving to a different file Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XJavaDoc Versions: 1.0.1 1.0.2 Assignee: xdoclet-devel (Use for new issues) Reporter: Clifton C. Craig Created: Mon, 29 Mar 2004 7:55 AM Updated: Thu, 8 Jul 2004 1:39 PM Environment: API for SourceClass Description: The xjavadoc.SourceClass class has a bug that prevents you from saving modified source to a separate folder. The save() method in this class neglects to cache and flush the file writer when a root directory parameter is passed in. The flush is performed on a separate PrintWriter when a root directory is not passed in. This fix a very simple. I have a modified copy on my PC with the fix, which includes 3 extra lines of source. One to cache the FileWriter object into a local variable, and two more to flush and close the writer. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
