You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Bill Burton <bi...@progress.com> on 2002/02/12 23:05:31 UTC

[PATCH] DVSL: fixes and enhancements to site*.dvsl

Hello,

In attempting to use the the site.dvsl and site_printable.dvsl stylesheets
on a converted Ant User's Guide page, I found several issues for which
I've attached a patch for these files.  These fixes and enhancements are
generic in nature and not at all specific to Ant.

File: examples/velocitydocs/build.xml:
* Renamed toolbox attribute to toolboxfile to avoid a deprecation warning.

Files: src/stylesheet/site.dvsl and src/stylesheet/site_printable.dvsl:
* In site_printable.dvsl, renamed the $FontSizeCode variable to
$source-font-size for consistency with other variables.
* In site.dvsl, added $source-font-size and supporting <font> tag support.
* Added to the <section> element an optional "anchor" attribute.  For
instance:
    <section anchor="buildfile" name="Using Ant: Writing a Simple
Buildfile">
  translates to 
    <a name="buildfile">Using Ant: Writing a Simple Buildfile</a>
  If the anchor attribute isn't specified, the name attribute is used
instead thus keeping backward compatibility.
* Fixed colspan and rowspan support in the #match("td") and #match("th")
sections.  Now, the rowspan and colspan attributes are only output if a
value has been set.  This fixes some table formatting errors that showed
up in Mozilla 0.98 and IE 5.5.

With these changes, the existing documentation should format in the same
way it has previously.

-Bill

Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by Bill Burton <bi...@progress.com>.
Hello,

"Geir Magnusson Jr." wrote:
> 
> On 2/13/02 11:15 PM, "Bill Burton" <bi...@progress.com> wrote:
> 
> > Hello,
> >
> > "Geir Magnusson Jr." wrote:
> >>
> >> On 2/13/02 4:50 PM, "Bill Burton" <bi...@progress.com> wrote:
> >>>>  - And you can't blow away ${docs.dest} in the "clean" target as that is a
> >>>> CVS-ed directory along with the contents - we follow the sometimes
> >>>> frowned-upon approach of checking in the rendered .html so it comes
> >>>> included
> >>>> in nightly snapshots as well as being easy to cvs update out onto the
> >>>> jakarta site.
> >>>
> >>> Okay.  In 0.32 I didn't recall a populated docs directory.
> >>>
> >>> Maybe there should be a clean-docs target or similar that deletes just the
> >>> docs directories.
> >>
> >> I assume you mean contents
> >
> > Does it matter as the task will recreate them (docs and docs-print)
> > anyway?
> 
> In the current practice, yes - if you remove the directory, then I can't
> check in the updated docs...

I see.

> >
> > In thinking about this further, since the generated docs are in CVS, the
> > docs target should not overwrite anything in that directory.  Instead, the
> > docs and docs-print targets should output to the target directory.  A new
> > target in the build.xml, "dist" can then be used to delete docs and then
> > copy target/docs to docs.  If that sounds okay, I'll submit a patch.
> 
> That's not how I work - not that it matters much, but just to let you know.
> Updating the docs isn't a grandiose 'dist' type of thing.  If something
> changes, I simply
> 
>  $ ant docs
>   (go take a look to make sure ok)
>  $ cvs commit xdocs/foo.xml docs/foo.html
> 
> And then I'm done - I can update the website then...

Okay, that makes sense.

It only seemed like an issue because I've been testing various stuff
related to the docs and wanted to make sure I was starting from a clean
directory.  However, it seems the dependency checking logic inherited from
the <style> task is working fine so the target docs are only overwritten
if a source .xml or the .dvsl file has changed.  I guess I can also run
Ant with -Ddocs.dest=docs_test to use a different target directory.

> 
> > Longer term, it may be good to have a dist subirectory which would be
> > populated in an optimum manner for a binary distribution.
> 
> Yes
> 
> >
> > Also, there are lots of javadoc warnings because ant.jar isn't in the
> > <javadoc>'s classpath.  I can submit a patch for that at the same time.
> >
> 
> Yes

Okay, I'll submit a patch to fix this.

-Bill

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 11:15 PM, "Bill Burton" <bi...@progress.com> wrote:

> Hello,
> 
> "Geir Magnusson Jr." wrote:
>> 
>> On 2/13/02 4:50 PM, "Bill Burton" <bi...@progress.com> wrote:
>>>>  - And you can't blow away ${docs.dest} in the "clean" target as that is a
>>>> CVS-ed directory along with the contents - we follow the sometimes
>>>> frowned-upon approach of checking in the rendered .html so it comes
>>>> included
>>>> in nightly snapshots as well as being easy to cvs update out onto the
>>>> jakarta site.
>>> 
>>> Okay.  In 0.32 I didn't recall a populated docs directory.
>>> 
>>> Maybe there should be a clean-docs target or similar that deletes just the
>>> docs directories.
>> 
>> I assume you mean contents
> 
> Does it matter as the task will recreate them (docs and docs-print)
> anyway?

In the current practice, yes - if you remove the directory, then I can't
check in the updated docs...

> 
> In thinking about this further, since the generated docs are in CVS, the
> docs target should not overwrite anything in that directory.  Instead, the
> docs and docs-print targets should output to the target directory.  A new
> target in the build.xml, "dist" can then be used to delete docs and then
> copy target/docs to docs.  If that sounds okay, I'll submit a patch.

That's not how I work - not that it matters much, but just to let you know.
Updating the docs isn't a grandiose 'dist' type of thing.  If something
changes, I simply

 $ ant docs
  (go take a look to make sure ok)
 $ cvs commit xdocs/foo.xml docs/foo.html

And then I'm done - I can update the website then...

 
> Longer term, it may be good to have a dist subirectory which would be
> populated in an optimum manner for a binary distribution.

Yes

> 
> Also, there are lots of javadoc warnings because ant.jar isn't in the
> <javadoc>'s classpath.  I can submit a patch for that at the same time.
> 

Yes

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++... 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by Bill Burton <bi...@progress.com>.
Hello,

"Geir Magnusson Jr." wrote:
> 
> On 2/13/02 4:50 PM, "Bill Burton" <bi...@progress.com> wrote:
> >>  - And you can't blow away ${docs.dest} in the "clean" target as that is a
> >> CVS-ed directory along with the contents - we follow the sometimes
> >> frowned-upon approach of checking in the rendered .html so it comes included
> >> in nightly snapshots as well as being easy to cvs update out onto the
> >> jakarta site.
> >
> > Okay.  In 0.32 I didn't recall a populated docs directory.
> >
> > Maybe there should be a clean-docs target or similar that deletes just the
> > docs directories.
> 
> I assume you mean contents

Does it matter as the task will recreate them (docs and docs-print)
anyway?

In thinking about this further, since the generated docs are in CVS, the
docs target should not overwrite anything in that directory.  Instead, the
docs and docs-print targets should output to the target directory.  A new
target in the build.xml, "dist" can then be used to delete docs and then
copy target/docs to docs.  If that sounds okay, I'll submit a patch.

Longer term, it may be good to have a dist subirectory which would be
populated in an optimum manner for a binary distribution.

Also, there are lots of javadoc warnings because ant.jar isn't in the
<javadoc>'s classpath.  I can submit a patch for that at the same time.

-Bill

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 4:50 PM, "Bill Burton" <bi...@progress.com> wrote:

> Hello,
> 
> "Geir Magnusson Jr." wrote:
>> Thanks, but you don't have to do this specially.  My mailer problem are my
>> mailer problems.
>> 
>> Comments :
>> 
>> 1) velocity-build-dvsl.patch (patching build.xml for dvsl) :
>> 
>>  - why didn't you like the descriptions?
> 
> I had no problem with them at all.  However in Ant, any target with a
> description attribute shows up under the Main targets section when running
> ant -projecthelp.  Targets without descriptions show up under the
> Subtargets section.  After applying my patch ant -projecthelp will look
> like this:
> 
> Buildfile: build.xml
> Default target:
> 
> jar             Creates jar file
> 
> Main targets:
> 
> all             Clean, build jar, generate docs and javadocs
> clean           Clean build and distribution directories
> compile         Compile
> compile-tests   Compile Testcases
> docs            Generate documentation
> docs-printable  Generate printable documentation
> install-jar     Installs .jar file in ${lib.repo}
> jar             Creates jar file
> javadocs        Create Javadoc documentation
> test            Run all unit tests
> 
> Subtargets:
> 
> docs-init
> init
> prepare
> static
> test.transform
> 
> In the current build.xml, the init, prepare and static targets all show up
> under the Main targets section. It didn't seem to me anyone should run
> these targets directly so by removing the description attribute from each
> of them, the target droped into the Subtargets section.  Conversely, the
> docs, docs-printable and jar targets didn't have descriptions so I added
> descriptions making these targets move up to the Main targets section
> where they show be.
> 

Yep. Sounds good.

>>  - And you can't blow away ${docs.dest} in the "clean" target as that is a
>> CVS-ed directory along with the contents - we follow the sometimes
>> frowned-upon approach of checking in the rendered .html so it comes included
>> in nightly snapshots as well as being easy to cvs update out onto the
>> jakarta site.
> 
> Okay.  In 0.32 I didn't recall a populated docs directory.
> 
> Maybe there should be a clean-docs target or similar that deletes just the
> docs directories.

I assume you mean contents

> 
>>  - We can commit w/o the delete of the ${docs.dest} if you want.
> 
> Sounds good.  
> 
>> 2) stylesheets patch :  Committed.
> 
> Thanks!
> 
> -Bill
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++... 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by Bill Burton <bi...@progress.com>.
Hello,

"Geir Magnusson Jr." wrote:
> Thanks, but you don't have to do this specially.  My mailer problem are my
> mailer problems.
> 
> Comments :
> 
> 1) velocity-build-dvsl.patch (patching build.xml for dvsl) :
> 
>  - why didn't you like the descriptions?

I had no problem with them at all.  However in Ant, any target with a
description attribute shows up under the Main targets section when running
ant -projecthelp.  Targets without descriptions show up under the
Subtargets section.  After applying my patch ant -projecthelp will look
like this:

Buildfile: build.xml
Default target:

 jar             Creates jar file

Main targets:

 all             Clean, build jar, generate docs and javadocs
 clean           Clean build and distribution directories
 compile         Compile
 compile-tests   Compile Testcases
 docs            Generate documentation
 docs-printable  Generate printable documentation
 install-jar     Installs .jar file in ${lib.repo}
 jar             Creates jar file
 javadocs        Create Javadoc documentation
 test            Run all unit tests

Subtargets:

 docs-init
 init
 prepare
 static
 test.transform

In the current build.xml, the init, prepare and static targets all show up
under the Main targets section. It didn't seem to me anyone should run
these targets directly so by removing the description attribute from each
of them, the target droped into the Subtargets section.  Conversely, the
docs, docs-printable and jar targets didn't have descriptions so I added
descriptions making these targets move up to the Main targets section
where they show be.

>  - And you can't blow away ${docs.dest} in the "clean" target as that is a
> CVS-ed directory along with the contents - we follow the sometimes
> frowned-upon approach of checking in the rendered .html so it comes included
> in nightly snapshots as well as being easy to cvs update out onto the
> jakarta site.

Okay.  In 0.32 I didn't recall a populated docs directory. 

Maybe there should be a clean-docs target or similar that deletes just the
docs directories.

>  - We can commit w/o the delete of the ${docs.dest} if you want.

Sounds good.  

> 2) stylesheets patch :  Committed.

Thanks!

-Bill

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 11:07 PM, "Bill Burton" <bi...@progress.com> wrote:

> Bill Burton wrote:
>> 
>> Hello Geir,
>> 
>> Both patches are attached.
> 
> And they showed up as text again :( .  I don't have .patch files
> associated with anything.
> 
> Attached is a .zip file.

:)

Thanks, but you don't have to do this specially.  My mailer problem are my
mailer problems.

Comments :

1) velocity-build-dvsl.patch (patching build.xml for dvsl) :

 - why didn't you like the descriptions?

 - And you can't blow away ${docs.dest} in the "clean" target as that is a
CVS-ed directory along with the contents - we follow the sometimes
frowned-upon approach of checking in the rendered .html so it comes included
in nightly snapshots as well as being easy to cvs update out onto the
jakarta site.

 - We can commit w/o the delete of the ${docs.dest} if you want.

2) stylesheets patch :  Committed.

geir
 

-- 
Geir Magnusson Jr.                       geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by Bill Burton <bi...@progress.com>.
Bill Burton wrote:
> 
> Hello Geir,
> 
> Both patches are attached.

And they showed up as text again :( .  I don't have .patch files
associated with anything.

Attached is a .zip file.

-Bill

> 
> -Bill
> 
> "Geir Magnusson Jr." wrote:
> > I'm using entourage for the Mac (from MSFT) and can't find a way to tell it
> > to not inline text attachments. Apparently MSFT know I will never need to be
> > able to control that, apparently...
> >
> > Thx
> >
> > geir
> > --

Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 10:37 PM, "Bill Burton" <bi...@progress.com> wrote:

> Hello Geir,
> 
> Both patches are attached.
> 
>

Thanks, but they too came inline.  Don't worry - I'll deal or switch
mailers... I don't want to switch though :)

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting

Age and treachery will always triumph over youth and talent


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by Bill Burton <bi...@progress.com>.
Hello Geir,

Both patches are attached.

-Bill

"Geir Magnusson Jr." wrote:
> I'm using entourage for the Mac (from MSFT) and can't find a way to tell it
> to not inline text attachments. Apparently MSFT know I will never need to be
> able to control that, apparently...
> 
> Thx
> 
> geir
> --
> Geir Magnusson Jr.                                     geirm@optonline.net
> System and Software Consulting
> Be a giant.  Take giant steps.  Do giant things...

Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 10:01 PM, "Bill Burton" <bi...@progress.com> wrote:

> Hello Geir,
> 
> "Geir Magnusson Jr." wrote:
>> 
>> Woo woo.
>> 
>> Thanks.  Will apply (with the other one outstanding) this eve.
>> 
>> Can you make them attachments next time? (Or did you and is my mailer wacky?
>> )
> 
> All my patches have been attachements.  Because I've used a .txt suffix
> and I'm running on Windows, the file is attached using a MIME type of
> text/plain.  I do this so anyone who's interested can look at the patch
> inline with the message.

Hm.

> 
> If you're using Netscape 4, you can click on the paperclip icon at the top
> to show the attached files. Then you can right click and save.  I would
> hope whatever MUA you're using has similar functionality.  If not, I can
> resend with a .patch suffix which will have an unknown MIME type and
> should show up as an attachement in your MUA.

I'm using entourage for the Mac (from MSFT) and can't find a way to tell it
to not inline text attachments. Apparently MSFT know I will never need to be
able to control that, apparently...

Thx

geir
-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by Bill Burton <bi...@progress.com>.
Hello Geir,

"Geir Magnusson Jr." wrote:
> 
> Woo woo.
> 
> Thanks.  Will apply (with the other one outstanding) this eve.
> 
> Can you make them attachments next time? (Or did you and is my mailer wacky?
> )

All my patches have been attachements.  Because I've used a .txt suffix
and I'm running on Windows, the file is attached using a MIME type of
text/plain.  I do this so anyone who's interested can look at the patch
inline with the message.

If you're using Netscape 4, you can click on the paperclip icon at the top
to show the attached files. Then you can right click and save.  I would
hope whatever MUA you're using has similar functionality.  If not, I can
resend with a .patch suffix which will have an unknown MIME type and
should show up as an attachement in your MUA.

-Bill

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] DVSL: fixes and enhancements to site*.dvsl

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Woo woo.

Thanks.  Will apply (with the other one outstanding) this eve.

Can you make them attachments next time? (Or did you and is my mailer wacky?
)

geir

On 2/12/02 5:05 PM, "Bill Burton" <bi...@progress.com> wrote:

> Hello,
> 
> In attempting to use the the site.dvsl and site_printable.dvsl stylesheets
> on a converted Ant User's Guide page, I found several issues for which
> I've attached a patch for these files.  These fixes and enhancements are
> generic in nature and not at all specific to Ant.
> 
> File: examples/velocitydocs/build.xml:
> * Renamed toolbox attribute to toolboxfile to avoid a deprecation warning.
> 

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
POC lives!


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>