You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/03/16 22:59:25 UTC
Site plugin feature of using Velocity
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it but
there are a couple options.
1) Use Velocity to process the pages before going to the respective
doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of model
I like the Velocity option, not sure if being on by default or not is
good. When there is a parse error I'm currently just rendering the
original document as is where you can see a warning and the full
error in debug mode. This is for 2.0 so it is a new feature but would
allow some cool stuff with.
Jason.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 16 Mar 07, at 8:00 PM 16 Mar 07, Wendy Smoak wrote:
> On 3/16/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> I'm leaning toward being on by default and letting people fully
>> utilize Velocity anywhere they like.
>
> If Velocity is involved, please make sure the EscapeTool is available
> so you can convince it *not* to process certain expressions.
I'm using the existing code to create the context which puts a whole
bunch of things in the context, among them the escape tool.
> This is
> a current problem in the archetype plugin. It's a one-line addition
> there, I just haven't figured out how to test it so I haven't added
> it.
>
> Would this make it possible to easily replace the templates for, say,
> the source-repository.html or team-list.html page?
I wouldn't say replace it but you could come up with your own new
reports based on any information in the project.
Jason.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/16/07, Jason van Zyl <ja...@maven.org> wrote:
> I'm leaning toward being on by default and letting people fully
> utilize Velocity anywhere they like.
If Velocity is involved, please make sure the EscapeTool is available
so you can convince it *not* to process certain expressions. This is
a current problem in the archetype plugin. It's a one-line addition
there, I just haven't figured out how to test it so I haven't added
it.
Would this make it possible to easily replace the templates for, say,
the source-repository.html or team-list.html page?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 18 Mar 07, at 12:23 AM 18 Mar 07, Brett Porter wrote:
>
> On 18/03/2007, at 11:29 AM, Jason van Zyl wrote:
>
>>>
>>> Wouldn't documents like:
>>> src/site/apt/guides/getting-started/index.apt
>>> have the ${pom.name} expressions (which are meant to be
>>> expressions) populated with the value?
>>
>> Wouldn't break them, they would render just interpolate the value.
>> So, yes, you would have to escape that value or use a literal block.
>
> Right, as far as I'm concerned that's breaking something :)
>
Yes, but this is 2.0 of the plugin so breaking your documents would
be a new feature :-)
>>
>> I'm going to pretend I didn't hear the word Jelly. La la la la,
>> dum dee do.
>>
>> Did we really process documents through Jelly? We were really on
>> crack. But James was on crack first, so it's not all our fault.
>
> Yeah, I think we did. Or at least there was those jsl reports. I'm
> not suggesting we actually go and do it now, but it might have been
> a useful migration path at one point :)
>
>>
>> Ultimately I think it would be good if people could configure
>> filter input streams and chain them and then you can really have
>> whatever you want. Unfortunately velocity doesn't expose stream
>> processing. Not yet anyway.
>
> Agreed.
>
>>
>> I will figure out something there then with that.
>
> Cool, thanks.
>
> The campaign for no-more-alphas seems to be going well. :)
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Brett Porter <br...@apache.org>.
On 18/03/2007, at 11:29 AM, Jason van Zyl wrote:
>>
>> Wouldn't documents like:
>> src/site/apt/guides/getting-started/index.apt
>> have the ${pom.name} expressions (which are meant to be
>> expressions) populated with the value?
>
> Wouldn't break them, they would render just interpolate the value.
> So, yes, you would have to escape that value or use a literal block.
Right, as far as I'm concerned that's breaking something :)
>
> I'm going to pretend I didn't hear the word Jelly. La la la la, dum
> dee do.
>
> Did we really process documents through Jelly? We were really on
> crack. But James was on crack first, so it's not all our fault.
Yeah, I think we did. Or at least there was those jsl reports. I'm
not suggesting we actually go and do it now, but it might have been a
useful migration path at one point :)
>
> Ultimately I think it would be good if people could configure
> filter input streams and chain them and then you can really have
> whatever you want. Unfortunately velocity doesn't expose stream
> processing. Not yet anyway.
Agreed.
>
> I will figure out something there then with that.
Cool, thanks.
The campaign for no-more-alphas seems to be going well. :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Mar 07, at 7:06 PM 17 Mar 07, Brett Porter wrote:
>
> On 18/03/2007, at 9:56 AM, Jason van Zyl wrote:
>
>>
>> On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:
>>
>>> What about anything with a .vm extension?
>>>
>>> download.apt.vm gets processed as vm first, then apt. We can do
>>> that in Doxia with zero-configuration.
>>>
>>> I really don't want it on by default, because it'll break
>>> existing documents
>>
>> It won't break any existing documents. If it doesn't parse it just
>> goes back to processing the raw document.
>
> Wouldn't documents like:
> src/site/apt/guides/getting-started/index.apt
> have the ${pom.name} expressions (which are meant to be
> expressions) populated with the value?
Wouldn't break them, they would render just interpolate the value.
So, yes, you would have to escape that value or use a literal block.
>
>>
>>> , and I can see situations where we might want to facilitate
>>> different processors.
>>
>> Sure, I'll ponder this a bit more. I don't want it to cause any
>> problems, but zero configuration. What kind of other processors
>> are you thinking about?
>
> Not that I particularly want to do it now, but this could have been
> a useful way to support some of the maven1 docs that used jelly.
I'm going to pretend I didn't hear the word Jelly. La la la la, dum
dee do.
Did we really process documents through Jelly? We were really on
crack. But James was on crack first, so it's not all our fault.
Ultimately I think it would be good if people could configure filter
input streams and chain them and then you can really have whatever
you want. Unfortunately velocity doesn't expose stream processing.
Not yet anyway.
> But I guess it would allow using other templating solutions if they
> are a skillset the team already has.
>
> I'm not sure it's that important, but it seems simple and useful to
> make it extensible in that way.
>
>>
>> Maybe we could make a configuration and allow the options to be
>> configured from the site.xml.
>
> Yeah, I think pushing site plugin configuration in general into
> there when it's related to rendering is a good idea.
>
I will figure out something there then with that.
Jason.
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Brett Porter <br...@apache.org>.
On 18/03/2007, at 9:56 AM, Jason van Zyl wrote:
>
> On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:
>
>> What about anything with a .vm extension?
>>
>> download.apt.vm gets processed as vm first, then apt. We can do
>> that in Doxia with zero-configuration.
>>
>> I really don't want it on by default, because it'll break existing
>> documents
>
> It won't break any existing documents. If it doesn't parse it just
> goes back to processing the raw document.
Wouldn't documents like:
src/site/apt/guides/getting-started/index.apt
have the ${pom.name} expressions (which are meant to be expressions)
populated with the value?
>
>> , and I can see situations where we might want to facilitate
>> different processors.
>
> Sure, I'll ponder this a bit more. I don't want it to cause any
> problems, but zero configuration. What kind of other processors are
> you thinking about?
Not that I particularly want to do it now, but this could have been a
useful way to support some of the maven1 docs that used jelly. But I
guess it would allow using other templating solutions if they are a
skillset the team already has.
I'm not sure it's that important, but it seems simple and useful to
make it extensible in that way.
>
> Maybe we could make a configuration and allow the options to be
> configured from the site.xml.
Yeah, I think pushing site plugin configuration in general into there
when it's related to rendering is a good idea.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:
> What about anything with a .vm extension?
>
> download.apt.vm gets processed as vm first, then apt. We can do
> that in Doxia with zero-configuration.
>
> I really don't want it on by default, because it'll break existing
> documents
It won't break any existing documents. If it doesn't parse it just
goes back to processing the raw document.
> , and I can see situations where we might want to facilitate
> different processors.
Sure, I'll ponder this a bit more. I don't want it to cause any
problems, but zero configuration. What kind of other processors are
you thinking about?
Maybe we could make a configuration and allow the options to be
configured from the site.xml.
Jason.
>
> - Brett
>
> On 18/03/2007, at 3:35 AM, Jason van Zyl wrote:
>
>>
>> On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:
>>
>>> Could this velocity pre-processor just be a plugin that gets run
>>> in the
>>> pre-site phase - unrelated to doxia?
>>>
>>
>> It could and that's what the velocity people seem to be doing on
>> their site, but I would really like to not have to configure
>> anything.
>>
>> I would like it to be useful generally, but if people object to it
>> being on by default (but for static site generation who cares),
>> then maybe a directory structure that gets processed by velocity.
>> But then you end up with a bunch of different directories. What I
>> did was process it with Velocity and if that attempt fails with a
>> parsing error just fall back to processing the raw document.
>>
>> I want zero configuration, and it just work. I'll do any grunt
>> work to make that possible.
>>
>> Jason.
>>
>>> Eric
>>>
>>> On 3/17/07, Jason van Zyl <ja...@maven.org> wrote:
>>>>
>>>>
>>>> On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
>>>>
>>>> > You've lost me, sorry. What type of page are you trying to
>>>> create?
>>>> >
>>>>
>>>> Any page, Velocity will be used to render any of the pages. It
>>>> would
>>>> just work anywhere in the site.
>>>>
>>>> > I can see how this makes it possible to make lightweight
>>>> reports. I
>>>> > don't see how it's useful in most documentation. I would think
>>>> the
>>>> > former would naturally be in a separate section somewhere, as
>>>> > opposed to having to specify pages.
>>>> >
>>>> > I think what Emmanuel was saying was that making everything
>>>> > velocity would mean stuff that had things that looked like
>>>> > expressions now would end up different (you are trying to
>>>> explain $
>>>> > {project.build.directory} instead of substitute it).
>>>>
>>>> That's really easy to escape, and we can tell people it's a
>>>> Velocity
>>>> document and it's well documented. I think that would be easier
>>>> then
>>>> juggling pages around to be rendered as it will be the case
>>>> where you
>>>> want the literal ${project.build.directory} and interpolate some
>>>> other project information. This is always the case with Velocity
>>>> documents which is why there are escaping tools, #macros, and the
>>>> actual escaping characters.
>>>>
>>>> Jason.
>>>>
>>>> >
>>>> > - Brett
>>>> >
>>>> > On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
>>>> >
>>>> >>
>>>> >> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
>>>> >>
>>>> >>> I think I'd like the option to, but not every time. Maybe it
>>>> >>> belongs closer to the reporting infrastructure (the download
>>>> >>> pages are more like the SCM/mail list types of pages).
>>>> >>>
>>>> >>> Maybe that's the real future of those types of pages - the
>>>> >>> ability to write simple velocity pages that get processed to
>>>> spit
>>>> >>> out apt that gets added to the list of docs to generate. Rather
>>>> >>> than affecting the APT itself, it is a step before
>>>> >>>
>>>> >>> WDYT?
>>>> >>>
>>>> >>
>>>> >> I'm not sure what you mean, not everytime. I think if you
>>>> turn it
>>>> >> on you wouldn't want to have to specify what pages you want
>>>> to be
>>>> >> interpolated. I think that would be inconvenient. And though it
>>>> >> doesn't fully stream now it will so it will actually be faster
>>>> >> then the current site plugin. So the performance will be higher
>>>> >> once it streams instead of collecting the page content in memory
>>>> >> to process it. So speed is not going to be an issue and it's not
>>>> >> really noticeable right now.
>>>> >>
>>>> >> This is only for sites and would be very handy. For example
>>>> would
>>>> >> then be able to make new types of reports and share them. They
>>>> >> just pop them into their site structure (and move toward being
>>>> >> packaged up as reports) and they will render with their project
>>>> >> information.
>>>> >>
>>>> >> I'm leaning toward being on by default and letting people fully
>>>> >> utilize Velocity anywhere they like.
>>>> >>
>>>> >> Jason.
>>>> >>
>>>> >>> - Brett
>>>> >>>
>>>> >>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Jason van Zyl a écrit :
>>>> >>>>> Hi,
>>>> >>>>> Do you think people would like to use Velocity for the
>>>> pages of
>>>> >>>>> documentation regardless of format. I've hooked it in to
>>>> try it
>>>> >>>>> but there are a couple options.
>>>> >>>>> 1) Use Velocity to process the pages before going to the
>>>> >>>>> respective doxia parser
>>>> >>>>> 2) Make 1) optional
>>>> >>>>> 3) Just interpolate the documents like we do the XML forms of
>>>> >>>>> model
>>>> >>>>
>>>> >>>> We can't interpolate every time. Sometimes, we need to
>>>> >>>> interpolate ${project.*} and sometimes not in dox
>>>> >>>>
>>>> >>>> Emmanuel
>>>> >>>>
>>>> >>>>> I like the Velocity option, not sure if being on by
>>>> default or
>>>> >>>>> not is good. When there is a parse error I'm currently just
>>>> >>>>> rendering the original document as is where you can see a
>>>> >>>>> warning and the full error in debug mode. This is for 2.0
>>>> so it
>>>> >>>>> is a new feature but would allow some cool stuff with.
>>>> >>>>> Jason.
>>>> >>>>>
>>>> ------------------------------------------------------------------
>>>> >>>>> ---
>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> -------------------------------------------------------------------
>>>> >>>> --
>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> >>>
>>>> >>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> >>> -
>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> -------------------------------------------------------------------
>>>> --
>>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>>> >
>>>> >
>>>> -------------------------------------------------------------------
>>>> --
>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>> >
>>>> >
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Eric Redmond
>>> http://codehaus.org/~eredmond
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Brett Porter <br...@apache.org>.
What about anything with a .vm extension?
download.apt.vm gets processed as vm first, then apt. We can do that
in Doxia with zero-configuration.
I really don't want it on by default, because it'll break existing
documents, and I can see situations where we might want to facilitate
different processors.
- Brett
On 18/03/2007, at 3:35 AM, Jason van Zyl wrote:
>
> On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:
>
>> Could this velocity pre-processor just be a plugin that gets run
>> in the
>> pre-site phase - unrelated to doxia?
>>
>
> It could and that's what the velocity people seem to be doing on
> their site, but I would really like to not have to configure anything.
>
> I would like it to be useful generally, but if people object to it
> being on by default (but for static site generation who cares),
> then maybe a directory structure that gets processed by velocity.
> But then you end up with a bunch of different directories. What I
> did was process it with Velocity and if that attempt fails with a
> parsing error just fall back to processing the raw document.
>
> I want zero configuration, and it just work. I'll do any grunt work
> to make that possible.
>
> Jason.
>
>> Eric
>>
>> On 3/17/07, Jason van Zyl <ja...@maven.org> wrote:
>>>
>>>
>>> On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
>>>
>>> > You've lost me, sorry. What type of page are you trying to create?
>>> >
>>>
>>> Any page, Velocity will be used to render any of the pages. It would
>>> just work anywhere in the site.
>>>
>>> > I can see how this makes it possible to make lightweight
>>> reports. I
>>> > don't see how it's useful in most documentation. I would think the
>>> > former would naturally be in a separate section somewhere, as
>>> > opposed to having to specify pages.
>>> >
>>> > I think what Emmanuel was saying was that making everything
>>> > velocity would mean stuff that had things that looked like
>>> > expressions now would end up different (you are trying to
>>> explain $
>>> > {project.build.directory} instead of substitute it).
>>>
>>> That's really easy to escape, and we can tell people it's a Velocity
>>> document and it's well documented. I think that would be easier then
>>> juggling pages around to be rendered as it will be the case where
>>> you
>>> want the literal ${project.build.directory} and interpolate some
>>> other project information. This is always the case with Velocity
>>> documents which is why there are escaping tools, #macros, and the
>>> actual escaping characters.
>>>
>>> Jason.
>>>
>>> >
>>> > - Brett
>>> >
>>> > On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
>>> >
>>> >>
>>> >> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
>>> >>
>>> >>> I think I'd like the option to, but not every time. Maybe it
>>> >>> belongs closer to the reporting infrastructure (the download
>>> >>> pages are more like the SCM/mail list types of pages).
>>> >>>
>>> >>> Maybe that's the real future of those types of pages - the
>>> >>> ability to write simple velocity pages that get processed to
>>> spit
>>> >>> out apt that gets added to the list of docs to generate. Rather
>>> >>> than affecting the APT itself, it is a step before
>>> >>>
>>> >>> WDYT?
>>> >>>
>>> >>
>>> >> I'm not sure what you mean, not everytime. I think if you turn it
>>> >> on you wouldn't want to have to specify what pages you want to be
>>> >> interpolated. I think that would be inconvenient. And though it
>>> >> doesn't fully stream now it will so it will actually be faster
>>> >> then the current site plugin. So the performance will be higher
>>> >> once it streams instead of collecting the page content in memory
>>> >> to process it. So speed is not going to be an issue and it's not
>>> >> really noticeable right now.
>>> >>
>>> >> This is only for sites and would be very handy. For example would
>>> >> then be able to make new types of reports and share them. They
>>> >> just pop them into their site structure (and move toward being
>>> >> packaged up as reports) and they will render with their project
>>> >> information.
>>> >>
>>> >> I'm leaning toward being on by default and letting people fully
>>> >> utilize Velocity anywhere they like.
>>> >>
>>> >> Jason.
>>> >>
>>> >>> - Brett
>>> >>>
>>> >>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Jason van Zyl a écrit :
>>> >>>>> Hi,
>>> >>>>> Do you think people would like to use Velocity for the
>>> pages of
>>> >>>>> documentation regardless of format. I've hooked it in to
>>> try it
>>> >>>>> but there are a couple options.
>>> >>>>> 1) Use Velocity to process the pages before going to the
>>> >>>>> respective doxia parser
>>> >>>>> 2) Make 1) optional
>>> >>>>> 3) Just interpolate the documents like we do the XML forms of
>>> >>>>> model
>>> >>>>
>>> >>>> We can't interpolate every time. Sometimes, we need to
>>> >>>> interpolate ${project.*} and sometimes not in dox
>>> >>>>
>>> >>>> Emmanuel
>>> >>>>
>>> >>>>> I like the Velocity option, not sure if being on by default or
>>> >>>>> not is good. When there is a parse error I'm currently just
>>> >>>>> rendering the original document as is where you can see a
>>> >>>>> warning and the full error in debug mode. This is for 2.0
>>> so it
>>> >>>>> is a new feature but would allow some cool stuff with.
>>> >>>>> Jason.
>>> >>>>>
>>> ------------------------------------------------------------------
>>> >>>>> ---
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>>>
>>> >>>>
>>> >>>>
>>> -------------------------------------------------------------------
>>> >>>> --
>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>>
>>> >>>
>>> --------------------------------------------------------------------
>>> >>> -
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> --------------------------------------------------------------------
>>> -
>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>> --------------------------------------------------------------------
>>> -
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> Eric Redmond
>> http://codehaus.org/~eredmond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:
> Could this velocity pre-processor just be a plugin that gets run in
> the
> pre-site phase - unrelated to doxia?
>
It could and that's what the velocity people seem to be doing on
their site, but I would really like to not have to configure anything.
I would like it to be useful generally, but if people object to it
being on by default (but for static site generation who cares), then
maybe a directory structure that gets processed by velocity. But then
you end up with a bunch of different directories. What I did was
process it with Velocity and if that attempt fails with a parsing
error just fall back to processing the raw document.
I want zero configuration, and it just work. I'll do any grunt work
to make that possible.
Jason.
> Eric
>
> On 3/17/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
>>
>> > You've lost me, sorry. What type of page are you trying to create?
>> >
>>
>> Any page, Velocity will be used to render any of the pages. It would
>> just work anywhere in the site.
>>
>> > I can see how this makes it possible to make lightweight reports. I
>> > don't see how it's useful in most documentation. I would think the
>> > former would naturally be in a separate section somewhere, as
>> > opposed to having to specify pages.
>> >
>> > I think what Emmanuel was saying was that making everything
>> > velocity would mean stuff that had things that looked like
>> > expressions now would end up different (you are trying to explain $
>> > {project.build.directory} instead of substitute it).
>>
>> That's really easy to escape, and we can tell people it's a Velocity
>> document and it's well documented. I think that would be easier then
>> juggling pages around to be rendered as it will be the case where you
>> want the literal ${project.build.directory} and interpolate some
>> other project information. This is always the case with Velocity
>> documents which is why there are escaping tools, #macros, and the
>> actual escaping characters.
>>
>> Jason.
>>
>> >
>> > - Brett
>> >
>> > On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
>> >
>> >>
>> >> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
>> >>
>> >>> I think I'd like the option to, but not every time. Maybe it
>> >>> belongs closer to the reporting infrastructure (the download
>> >>> pages are more like the SCM/mail list types of pages).
>> >>>
>> >>> Maybe that's the real future of those types of pages - the
>> >>> ability to write simple velocity pages that get processed to spit
>> >>> out apt that gets added to the list of docs to generate. Rather
>> >>> than affecting the APT itself, it is a step before
>> >>>
>> >>> WDYT?
>> >>>
>> >>
>> >> I'm not sure what you mean, not everytime. I think if you turn it
>> >> on you wouldn't want to have to specify what pages you want to be
>> >> interpolated. I think that would be inconvenient. And though it
>> >> doesn't fully stream now it will so it will actually be faster
>> >> then the current site plugin. So the performance will be higher
>> >> once it streams instead of collecting the page content in memory
>> >> to process it. So speed is not going to be an issue and it's not
>> >> really noticeable right now.
>> >>
>> >> This is only for sites and would be very handy. For example would
>> >> then be able to make new types of reports and share them. They
>> >> just pop them into their site structure (and move toward being
>> >> packaged up as reports) and they will render with their project
>> >> information.
>> >>
>> >> I'm leaning toward being on by default and letting people fully
>> >> utilize Velocity anywhere they like.
>> >>
>> >> Jason.
>> >>
>> >>> - Brett
>> >>>
>> >>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>> >>>
>> >>>>
>> >>>>
>> >>>> Jason van Zyl a écrit :
>> >>>>> Hi,
>> >>>>> Do you think people would like to use Velocity for the pages of
>> >>>>> documentation regardless of format. I've hooked it in to try it
>> >>>>> but there are a couple options.
>> >>>>> 1) Use Velocity to process the pages before going to the
>> >>>>> respective doxia parser
>> >>>>> 2) Make 1) optional
>> >>>>> 3) Just interpolate the documents like we do the XML forms of
>> >>>>> model
>> >>>>
>> >>>> We can't interpolate every time. Sometimes, we need to
>> >>>> interpolate ${project.*} and sometimes not in dox
>> >>>>
>> >>>> Emmanuel
>> >>>>
>> >>>>> I like the Velocity option, not sure if being on by default or
>> >>>>> not is good. When there is a parse error I'm currently just
>> >>>>> rendering the original document as is where you can see a
>> >>>>> warning and the full error in debug mode. This is for 2.0 so it
>> >>>>> is a new feature but would allow some cool stuff with.
>> >>>>> Jason.
>> >>>>>
>> ------------------------------------------------------------------
>> >>>>> ---
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>
>> >>>>
>> >>>>
>> -------------------------------------------------------------------
>> >>>> --
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> Eric Redmond
> http://codehaus.org/~eredmond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Eric Redmond <er...@gmail.com>.
Could this velocity pre-processor just be a plugin that gets run in the
pre-site phase - unrelated to doxia?
Eric
On 3/17/07, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
>
> > You've lost me, sorry. What type of page are you trying to create?
> >
>
> Any page, Velocity will be used to render any of the pages. It would
> just work anywhere in the site.
>
> > I can see how this makes it possible to make lightweight reports. I
> > don't see how it's useful in most documentation. I would think the
> > former would naturally be in a separate section somewhere, as
> > opposed to having to specify pages.
> >
> > I think what Emmanuel was saying was that making everything
> > velocity would mean stuff that had things that looked like
> > expressions now would end up different (you are trying to explain $
> > {project.build.directory} instead of substitute it).
>
> That's really easy to escape, and we can tell people it's a Velocity
> document and it's well documented. I think that would be easier then
> juggling pages around to be rendered as it will be the case where you
> want the literal ${project.build.directory} and interpolate some
> other project information. This is always the case with Velocity
> documents which is why there are escaping tools, #macros, and the
> actual escaping characters.
>
> Jason.
>
> >
> > - Brett
> >
> > On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
> >
> >>
> >> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
> >>
> >>> I think I'd like the option to, but not every time. Maybe it
> >>> belongs closer to the reporting infrastructure (the download
> >>> pages are more like the SCM/mail list types of pages).
> >>>
> >>> Maybe that's the real future of those types of pages - the
> >>> ability to write simple velocity pages that get processed to spit
> >>> out apt that gets added to the list of docs to generate. Rather
> >>> than affecting the APT itself, it is a step before
> >>>
> >>> WDYT?
> >>>
> >>
> >> I'm not sure what you mean, not everytime. I think if you turn it
> >> on you wouldn't want to have to specify what pages you want to be
> >> interpolated. I think that would be inconvenient. And though it
> >> doesn't fully stream now it will so it will actually be faster
> >> then the current site plugin. So the performance will be higher
> >> once it streams instead of collecting the page content in memory
> >> to process it. So speed is not going to be an issue and it's not
> >> really noticeable right now.
> >>
> >> This is only for sites and would be very handy. For example would
> >> then be able to make new types of reports and share them. They
> >> just pop them into their site structure (and move toward being
> >> packaged up as reports) and they will render with their project
> >> information.
> >>
> >> I'm leaning toward being on by default and letting people fully
> >> utilize Velocity anywhere they like.
> >>
> >> Jason.
> >>
> >>> - Brett
> >>>
> >>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
> >>>
> >>>>
> >>>>
> >>>> Jason van Zyl a écrit :
> >>>>> Hi,
> >>>>> Do you think people would like to use Velocity for the pages of
> >>>>> documentation regardless of format. I've hooked it in to try it
> >>>>> but there are a couple options.
> >>>>> 1) Use Velocity to process the pages before going to the
> >>>>> respective doxia parser
> >>>>> 2) Make 1) optional
> >>>>> 3) Just interpolate the documents like we do the XML forms of
> >>>>> model
> >>>>
> >>>> We can't interpolate every time. Sometimes, we need to
> >>>> interpolate ${project.*} and sometimes not in dox
> >>>>
> >>>> Emmanuel
> >>>>
> >>>>> I like the Velocity option, not sure if being on by default or
> >>>>> not is good. When there is a parse error I'm currently just
> >>>>> rendering the original document as is where you can see a
> >>>>> warning and the full error in debug mode. This is for 2.0 so it
> >>>>> is a new feature but would allow some cool stuff with.
> >>>>> Jason.
> >>>>> ------------------------------------------------------------------
> >>>>> ---
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
> You've lost me, sorry. What type of page are you trying to create?
>
Any page, Velocity will be used to render any of the pages. It would
just work anywhere in the site.
> I can see how this makes it possible to make lightweight reports. I
> don't see how it's useful in most documentation. I would think the
> former would naturally be in a separate section somewhere, as
> opposed to having to specify pages.
>
> I think what Emmanuel was saying was that making everything
> velocity would mean stuff that had things that looked like
> expressions now would end up different (you are trying to explain $
> {project.build.directory} instead of substitute it).
That's really easy to escape, and we can tell people it's a Velocity
document and it's well documented. I think that would be easier then
juggling pages around to be rendered as it will be the case where you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.
Jason.
>
> - Brett
>
> On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
>
>>
>> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
>>
>>> I think I'd like the option to, but not every time. Maybe it
>>> belongs closer to the reporting infrastructure (the download
>>> pages are more like the SCM/mail list types of pages).
>>>
>>> Maybe that's the real future of those types of pages - the
>>> ability to write simple velocity pages that get processed to spit
>>> out apt that gets added to the list of docs to generate. Rather
>>> than affecting the APT itself, it is a step before
>>>
>>> WDYT?
>>>
>>
>> I'm not sure what you mean, not everytime. I think if you turn it
>> on you wouldn't want to have to specify what pages you want to be
>> interpolated. I think that would be inconvenient. And though it
>> doesn't fully stream now it will so it will actually be faster
>> then the current site plugin. So the performance will be higher
>> once it streams instead of collecting the page content in memory
>> to process it. So speed is not going to be an issue and it's not
>> really noticeable right now.
>>
>> This is only for sites and would be very handy. For example would
>> then be able to make new types of reports and share them. They
>> just pop them into their site structure (and move toward being
>> packaged up as reports) and they will render with their project
>> information.
>>
>> I'm leaning toward being on by default and letting people fully
>> utilize Velocity anywhere they like.
>>
>> Jason.
>>
>>> - Brett
>>>
>>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>>>
>>>>
>>>>
>>>> Jason van Zyl a écrit :
>>>>> Hi,
>>>>> Do you think people would like to use Velocity for the pages of
>>>>> documentation regardless of format. I've hooked it in to try it
>>>>> but there are a couple options.
>>>>> 1) Use Velocity to process the pages before going to the
>>>>> respective doxia parser
>>>>> 2) Make 1) optional
>>>>> 3) Just interpolate the documents like we do the XML forms of
>>>>> model
>>>>
>>>> We can't interpolate every time. Sometimes, we need to
>>>> interpolate ${project.*} and sometimes not in dox
>>>>
>>>> Emmanuel
>>>>
>>>>> I like the Velocity option, not sure if being on by default or
>>>>> not is good. When there is a parse error I'm currently just
>>>>> rendering the original document as is where you can see a
>>>>> warning and the full error in debug mode. This is for 2.0 so it
>>>>> is a new feature but would allow some cool stuff with.
>>>>> Jason.
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Brett Porter <br...@apache.org>.
You've lost me, sorry. What type of page are you trying to create?
I can see how this makes it possible to make lightweight reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as opposed
to having to specify pages.
I think what Emmanuel was saying was that making everything velocity
would mean stuff that had things that looked like expressions now
would end up different (you are trying to explain $
{project.build.directory} instead of substitute it).
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
>
> On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
>
>> I think I'd like the option to, but not every time. Maybe it
>> belongs closer to the reporting infrastructure (the download pages
>> are more like the SCM/mail list types of pages).
>>
>> Maybe that's the real future of those types of pages - the ability
>> to write simple velocity pages that get processed to spit out apt
>> that gets added to the list of docs to generate. Rather than
>> affecting the APT itself, it is a step before
>>
>> WDYT?
>>
>
> I'm not sure what you mean, not everytime. I think if you turn it
> on you wouldn't want to have to specify what pages you want to be
> interpolated. I think that would be inconvenient. And though it
> doesn't fully stream now it will so it will actually be faster then
> the current site plugin. So the performance will be higher once it
> streams instead of collecting the page content in memory to process
> it. So speed is not going to be an issue and it's not really
> noticeable right now.
>
> This is only for sites and would be very handy. For example would
> then be able to make new types of reports and share them. They just
> pop them into their site structure (and move toward being packaged
> up as reports) and they will render with their project information.
>
> I'm leaning toward being on by default and letting people fully
> utilize Velocity anywhere they like.
>
> Jason.
>
>> - Brett
>>
>> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>>
>>>
>>>
>>> Jason van Zyl a écrit :
>>>> Hi,
>>>> Do you think people would like to use Velocity for the pages of
>>>> documentation regardless of format. I've hooked it in to try it
>>>> but there are a couple options.
>>>> 1) Use Velocity to process the pages before going to the
>>>> respective doxia parser
>>>> 2) Make 1) optional
>>>> 3) Just interpolate the documents like we do the XML forms of model
>>>
>>> We can't interpolate every time. Sometimes, we need to
>>> interpolate ${project.*} and sometimes not in dox
>>>
>>> Emmanuel
>>>
>>>> I like the Velocity option, not sure if being on by default or
>>>> not is good. When there is a parse error I'm currently just
>>>> rendering the original document as is where you can see a
>>>> warning and the full error in debug mode. This is for 2.0 so it
>>>> is a new feature but would allow some cool stuff with.
>>>> Jason.
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
> I think I'd like the option to, but not every time. Maybe it
> belongs closer to the reporting infrastructure (the download pages
> are more like the SCM/mail list types of pages).
>
> Maybe that's the real future of those types of pages - the ability
> to write simple velocity pages that get processed to spit out apt
> that gets added to the list of docs to generate. Rather than
> affecting the APT itself, it is a step before
>
> WDYT?
>
I'm not sure what you mean, not everytime. I think if you turn it on
you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster then
the current site plugin. So the performance will be higher once it
streams instead of collecting the page content in memory to process
it. So speed is not going to be an issue and it's not really
noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They just
pop them into their site structure (and move toward being packaged up
as reports) and they will render with their project information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
> - Brett
>
> On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>
>>
>>
>> Jason van Zyl a écrit :
>>> Hi,
>>> Do you think people would like to use Velocity for the pages of
>>> documentation regardless of format. I've hooked it in to try it
>>> but there are a couple options.
>>> 1) Use Velocity to process the pages before going to the
>>> respective doxia parser
>>> 2) Make 1) optional
>>> 3) Just interpolate the documents like we do the XML forms of model
>>
>> We can't interpolate every time. Sometimes, we need to interpolate
>> ${project.*} and sometimes not in dox
>>
>> Emmanuel
>>
>>> I like the Velocity option, not sure if being on by default or
>>> not is good. When there is a parse error I'm currently just
>>> rendering the original document as is where you can see a warning
>>> and the full error in debug mode. This is for 2.0 so it is a new
>>> feature but would allow some cool stuff with.
>>> Jason.
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Brett Porter <br...@apache.org>.
I think I'd like the option to, but not every time. Maybe it belongs
closer to the reporting infrastructure (the download pages are more
like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the ability to
write simple velocity pages that get processed to spit out apt that
gets added to the list of docs to generate. Rather than affecting the
APT itself, it is a step before
WDYT?
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
>
>
> Jason van Zyl a écrit :
>> Hi,
>> Do you think people would like to use Velocity for the pages of
>> documentation regardless of format. I've hooked it in to try it
>> but there are a couple options.
>> 1) Use Velocity to process the pages before going to the
>> respective doxia parser
>> 2) Make 1) optional
>> 3) Just interpolate the documents like we do the XML forms of model
>
> We can't interpolate every time. Sometimes, we need to interpolate $
> {project.*} and sometimes not in dox
>
> Emmanuel
>
>> I like the Velocity option, not sure if being on by default or not
>> is good. When there is a parse error I'm currently just rendering
>> the original document as is where you can see a warning and the
>> full error in debug mode. This is for 2.0 so it is a new feature
>> but would allow some cool stuff with.
>> Jason.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Jason van Zyl <ja...@maven.org>.
On 16 Mar 07, at 6:09 PM 16 Mar 07, Emmanuel Venisse wrote:
>
>
> Jason van Zyl a écrit :
>> Hi,
>> Do you think people would like to use Velocity for the pages of
>> documentation regardless of format. I've hooked it in to try it
>> but there are a couple options.
>> 1) Use Velocity to process the pages before going to the
>> respective doxia parser
>> 2) Make 1) optional
>> 3) Just interpolate the documents like we do the XML forms of model
>
> We can't interpolate every time. Sometimes, we need to interpolate $
> {project.*} and sometimes not in dox
>
Sorry, I don't really understand.
Not sure what you mean in that you can't interpolate everytime. The
decorator is still processed by Velocity, I mean the individual APT/
XDoc documents.
Jason.
> Emmanuel
>
>> I like the Velocity option, not sure if being on by default or not
>> is good. When there is a parse error I'm currently just rendering
>> the original document as is where you can see a warning and the
>> full error in debug mode. This is for 2.0 so it is a new feature
>> but would allow some cool stuff with.
>> Jason.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin feature of using Velocity
Posted by Emmanuel Venisse <em...@venisse.net>.
Jason van Zyl a écrit :
> Hi,
>
> Do you think people would like to use Velocity for the pages of
> documentation regardless of format. I've hooked it in to try it but
> there are a couple options.
>
> 1) Use Velocity to process the pages before going to the respective
> doxia parser
> 2) Make 1) optional
> 3) Just interpolate the documents like we do the XML forms of model
We can't interpolate every time. Sometimes, we need to interpolate ${project.*} and sometimes not in dox
Emmanuel
>
> I like the Velocity option, not sure if being on by default or not is
> good. When there is a parse error I'm currently just rendering the
> original document as is where you can see a warning and the full error
> in debug mode. This is for 2.0 so it is a new feature but would allow
> some cool stuff with.
>
> Jason.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org