You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Henri Yandell <fl...@gmail.com> on 2006/02/23 20:11:25 UTC
DVSL - ever released?
A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
the Maven repository; there are no tags in SVN and there's been no
release on the site. I took a quick look and he's right; it's not a
cvs2svn issue as there were no tags in CVS either.
Is the 0.45 jar an unofficial rogue one?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Henri Yandell <fl...@gmail.com>.
Not continuing it Robert, just fixing so that those who are using DVSL
can easily get the source code to the jar they're tied to. Other than
that, my only interest is in how to stop jars being unofficially
released via ibiblio.
Hen
On 4/7/06, Robert Koberg <ro...@koberg.com> wrote:
>
> Sorry, this is extremely lame. Why continue with something that sucks?
>
> Nathan Bubna wrote:
> > Thanks, Henri!
> >
> > On 4/7/06, Henri Yandell <fl...@gmail.com> wrote:
> >> Done. I used the timestamp of the files inside the jars to look up the
> >> most likely revision in SVN.
> >>
> >> 0.45 - r72419
> >> 0.43 - r72400
> >> 0.40 - r72359
> >> 0.31 - r72329
> >>
> >> http://svn.apache.org/viewcvs.cgi/jakarta/velocity/dvsl/tags/
> >>
> >> Hen
> >>
> >> On 3/31/06, Henri Yandell <fl...@gmail.com> wrote:
> >>> Anyone mind if I retroactively create a tag in SVN to point to the
> >>> revision the 0.45 jar was built from?
> >>>
> >>> I'll try to figure out the other releases too.
> >>>
> >>> Hen
> >>>
> >>> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> >>>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> >>>> the Maven repository; there are no tags in SVN and there's been no
> >>>> release on the site. I took a quick look and he's right; it's not a
> >>>> cvs2svn issue as there were no tags in CVS either.
> >>>>
> >>>> Is the 0.45 jar an unofficial rogue one?
> >>>>
> >>>> Hen
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Sorry, this is extremely lame. Why continue with something that sucks?
Nathan Bubna wrote:
> Thanks, Henri!
>
> On 4/7/06, Henri Yandell <fl...@gmail.com> wrote:
>> Done. I used the timestamp of the files inside the jars to look up the
>> most likely revision in SVN.
>>
>> 0.45 - r72419
>> 0.43 - r72400
>> 0.40 - r72359
>> 0.31 - r72329
>>
>> http://svn.apache.org/viewcvs.cgi/jakarta/velocity/dvsl/tags/
>>
>> Hen
>>
>> On 3/31/06, Henri Yandell <fl...@gmail.com> wrote:
>>> Anyone mind if I retroactively create a tag in SVN to point to the
>>> revision the 0.45 jar was built from?
>>>
>>> I'll try to figure out the other releases too.
>>>
>>> Hen
>>>
>>> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
>>>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>>>> the Maven repository; there are no tags in SVN and there's been no
>>>> release on the site. I took a quick look and he's right; it's not a
>>>> cvs2svn issue as there were no tags in CVS either.
>>>>
>>>> Is the 0.45 jar an unofficial rogue one?
>>>>
>>>> Hen
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Nathan Bubna <nb...@gmail.com>.
Thanks, Henri!
On 4/7/06, Henri Yandell <fl...@gmail.com> wrote:
> Done. I used the timestamp of the files inside the jars to look up the
> most likely revision in SVN.
>
> 0.45 - r72419
> 0.43 - r72400
> 0.40 - r72359
> 0.31 - r72329
>
> http://svn.apache.org/viewcvs.cgi/jakarta/velocity/dvsl/tags/
>
> Hen
>
> On 3/31/06, Henri Yandell <fl...@gmail.com> wrote:
> > Anyone mind if I retroactively create a tag in SVN to point to the
> > revision the 0.45 jar was built from?
> >
> > I'll try to figure out the other releases too.
> >
> > Hen
> >
> > On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> > > A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> > > the Maven repository; there are no tags in SVN and there's been no
> > > release on the site. I took a quick look and he's right; it's not a
> > > cvs2svn issue as there were no tags in CVS either.
> > >
> > > Is the 0.45 jar an unofficial rogue one?
> > >
> > > Hen
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Henri Yandell <fl...@gmail.com>.
Done. I used the timestamp of the files inside the jars to look up the
most likely revision in SVN.
0.45 - r72419
0.43 - r72400
0.40 - r72359
0.31 - r72329
http://svn.apache.org/viewcvs.cgi/jakarta/velocity/dvsl/tags/
Hen
On 3/31/06, Henri Yandell <fl...@gmail.com> wrote:
> Anyone mind if I retroactively create a tag in SVN to point to the
> revision the 0.45 jar was built from?
>
> I'll try to figure out the other releases too.
>
> Hen
>
> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> > A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> > the Maven repository; there are no tags in SVN and there's been no
> > release on the site. I took a quick look and he's right; it's not a
> > cvs2svn issue as there were no tags in CVS either.
> >
> > Is the 0.45 jar an unofficial rogue one?
> >
> > Hen
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks, Henri.
WILL
On 4/1/06, Nathan Bubna <nb...@gmail.com> wrote:
> Sounds good to me.
>
> On 3/31/06, Henri Yandell <fl...@gmail.com> wrote:
> > Anyone mind if I retroactively create a tag in SVN to point to the
> > revision the 0.45 jar was built from?
> >
> > I'll try to figure out the other releases too.
> >
> > Hen
> >
> > On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> > > A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> > > the Maven repository; there are no tags in SVN and there's been no
> > > release on the site. I took a quick look and he's right; it's not a
> > > cvs2svn issue as there were no tags in CVS either.
> > >
> > > Is the 0.45 jar an unofficial rogue one?
> > >
> > > Hen
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Nathan Bubna <nb...@gmail.com>.
Sounds good to me.
On 3/31/06, Henri Yandell <fl...@gmail.com> wrote:
> Anyone mind if I retroactively create a tag in SVN to point to the
> revision the 0.45 jar was built from?
>
> I'll try to figure out the other releases too.
>
> Hen
>
> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> > A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> > the Maven repository; there are no tags in SVN and there's been no
> > release on the site. I took a quick look and he's right; it's not a
> > cvs2svn issue as there were no tags in CVS either.
> >
> > Is the 0.45 jar an unofficial rogue one?
> >
> > Hen
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Henri Yandell <fl...@gmail.com>.
Anyone mind if I retroactively create a tag in SVN to point to the
revision the 0.45 jar was built from?
I'll try to figure out the other releases too.
Hen
On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> the Maven repository; there are no tags in SVN and there's been no
> release on the site. I took a quick look and he's right; it's not a
> cvs2svn issue as there were no tags in CVS either.
>
> Is the 0.45 jar an unofficial rogue one?
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Bubna wrote:
> i'm not especially familiar with DVSL, but here's what little i can
> say... DVSL has yet to reach 1.0, and honestly, i'm not sure it ever
> will unless it finds a champion. I think it has promise, but since
> Geir stopped working on it, it really hasn't moved. i'm a little
> surprised that he (or whoever it was that built the 0.45 version)
> didn't tag that in CVS, but i would venture to guess that only minor
> bug fixes (at most) have happened since then and that Geir
> semi-arbitrarily chose to call a particular build a 0.45 "release".
Well, I don't think I would have pulled 0.45 out of the air, but I can't
really remember. I am surprised that it isn't tagged though. We should
do that and do an official 0.5 release.
geir
>
> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>> the Maven repository; there are no tags in SVN and there's been no
>> release on the site. I took a quick look and he's right; it's not a
>> cvs2svn issue as there were no tags in CVS either.
>>
>> Is the 0.45 jar an unofficial rogue one?
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
It's cool :)
Will Glass-Husain wrote:
> I agree with Nathan. It's a bit of an orphan at the moment.
>
> Actually, there's a critical bug on this...
> https://issues.apache.org/jira/browse/VELOCITY-413
>
> That notes DVSL doesn't appear to work with upcoming Velocity 1.5
> release. Possibly this is now working since we've fixed a few
> backwards-compatibily bugs in Velocity core.
>
> I was planning on diving into this at some point, but I'm not enthused
> about supporting something I've never used.
>
> WILL
>
> ----- Original Message ----- From: "Nathan Bubna" <nb...@gmail.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Thursday, February 23, 2006 11:33 AM
> Subject: Re: DVSL - ever released?
>
>
> i'm not especially familiar with DVSL, but here's what little i can
> say... DVSL has yet to reach 1.0, and honestly, i'm not sure it ever
> will unless it finds a champion. I think it has promise, but since
> Geir stopped working on it, it really hasn't moved. i'm a little
> surprised that he (or whoever it was that built the 0.45 version)
> didn't tag that in CVS, but i would venture to guess that only minor
> bug fixes (at most) have happened since then and that Geir
> semi-arbitrarily chose to call a particular build a 0.45 "release".
>
> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>> the Maven repository; there are no tags in SVN and there's been no
>> release on the site. I took a quick look and he's right; it's not a
>> cvs2svn issue as there were no tags in CVS either.
>>
>> Is the 0.45 jar an unofficial rogue one?
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Will Glass-Husain <wg...@forio.com>.
I agree with Nathan. It's a bit of an orphan at the moment.
Actually, there's a critical bug on this...
https://issues.apache.org/jira/browse/VELOCITY-413
That notes DVSL doesn't appear to work with upcoming Velocity 1.5 release.
Possibly this is now working since we've fixed a few backwards-compatibily
bugs in Velocity core.
I was planning on diving into this at some point, but I'm not enthused about
supporting something I've never used.
WILL
----- Original Message -----
From: "Nathan Bubna" <nb...@gmail.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Thursday, February 23, 2006 11:33 AM
Subject: Re: DVSL - ever released?
i'm not especially familiar with DVSL, but here's what little i can
say... DVSL has yet to reach 1.0, and honestly, i'm not sure it ever
will unless it finds a champion. I think it has promise, but since
Geir stopped working on it, it really hasn't moved. i'm a little
surprised that he (or whoever it was that built the 0.45 version)
didn't tag that in CVS, but i would venture to guess that only minor
bug fixes (at most) have happened since then and that Geir
semi-arbitrarily chose to call a particular build a 0.45 "release".
On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> the Maven repository; there are no tags in SVN and there's been no
> release on the site. I took a quick look and he's right; it's not a
> cvs2svn issue as there were no tags in CVS either.
>
> Is the 0.45 jar an unofficial rogue one?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Nathan Bubna <nb...@gmail.com>.
i'm not especially familiar with DVSL, but here's what little i can
say... DVSL has yet to reach 1.0, and honestly, i'm not sure it ever
will unless it finds a champion. I think it has promise, but since
Geir stopped working on it, it really hasn't moved. i'm a little
surprised that he (or whoever it was that built the 0.45 version)
didn't tag that in CVS, but i would venture to guess that only minor
bug fixes (at most) have happened since then and that Geir
semi-arbitrarily chose to call a particular build a 0.45 "release".
On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> the Maven repository; there are no tags in SVN and there's been no
> release on the site. I took a quick look and he's right; it's not a
> cvs2svn issue as there were no tags in CVS either.
>
> Is the 0.45 jar an unofficial rogue one?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Serge Knystautas wrote:
> On 2/27/06, Jonathan Revusky <re...@wanadoo.es> wrote:
>
>>Let's suppose that, contrary to fact, the release you mention had a
>>corresponding CVS tag. Do you think that the people (if there really are
>>any) relying on DVSL would be in a _significantly_ better position?
>
>
> Yes. Think of this like insurance.
Not having a tag in this instance is not like not having insurance. It's
more like you have taken out insurance (you have a code repository after
all) but you have bad filing procedures, so that when you need a copy of
the insurance policy, you have to tear your office apart to find it.
(Though you eventually do find it.)
The point I'm making though is not over whether it's good to have good
process. Of course it's better not to be sloppy about these things.
The point I'm making has to do with something that everybody with a
grain of common sense knows or at least intuits: there are first-order
and second-order problems and if you don't address the first-order
problems, the second-order ones are basically irrelevant.
As an example, let's say that, on a doctor's visit, I am informed of 2
things.
1. I have an advanced cancer that is usually terminal. Certainly,
without aggressive treatment, I will be dead in a matter of months.
2. I have high cholesterol.
Let's suppose my physician concentrates on the second problem and
ignores the first one. He spends the entire visit outlining a low fat
diet that I should follow.
This doesn't make any sense, right? If I'm not going to get any
treatment for the cancer, I may as well eat all the fatty foods I feel
like in the limited time I have remaining, right? The more generalized
point is that the the presence of the first-order problem of the
advanced cancer basically renders the second-order problem, the
cholesterol, irrelevant.
Similarly, a business that has no customers, because they do not have a
product or service anybody wants to buy, has a first order problem. They
may also have some issues with somewhat sloppy accounting procedures.
However, even introducing the best accounting procedures will not
resolve their first order problem. Similarly to the doctor in the
previous case, a business consultant who is obsessed with correct
accounting procedures might only concentrate on that, and not even
mention the first-order problem, which is that nobody is buying the
company's products. And that problem will inevitably lead to bankruptcy
irrespectively of how good the company's accounting procedures are.
This whole DVSL situation suffers from a major A-1-A first order problem
and that is its complete abandonment in a totally half-baked state. (Did
anybody miss the fact that Geir dodged Robert Koberg's question about
namespaces? AFAICS, DVSL simply punts on namespaces. I guess Geir was
reluctant to answer that question forthrightly since it reflects
terribly on the thing.)
Well, it's not just that DVSL is unmaintained and unsupported, it's that
there is a lack of clarity there about this. If you really do want to
encourage somebody to pick up the project and do something with it,
maybe the web page should say something like: "Hi, I'm an abandoned
project looking to be adopted. If you are interested, here is what
should you do." However, the main DVSL page does not forthrightly
disclose the state of the project, but rather, even suggests to the
reader that there is some active development going on. That strikes me
as quite problematic.
> You are correct to reason that it
> is *much* better to be healthy or to not crash your car. And I agree
> with you that most people do believe that the ASF projects don't crash
> their cars as often as SF projects.
>
> But when they crash, that insurance of a CVS tag was pretty darn
> useful and puts you well ahead of the person without the insurance...
I would dispute the "well ahead" part. With a completely unmaintained
abandoned product, if there is nobody to whom I can even to ask any
questions about the code, it is not typically going to be very practical
to do much with it. It would make much more sense just to opt for some
actively maintained and supported alternative.
Now, for example, in the case of FreeMarker, anybody can include a
freemarker.jar file with their product if they want. They may or may not
be clear about which version this is; we have no control over that.
However, we do have a disposition now where there is a main() method you
can run from the command-line like:
java -jar freemarker.jar
and it outputs the version of the library. If it tells you that this is
version 2.2.3, say, you could go download that off sourceforge. And then
you'll have the exact source corresponding to that .jar. (Unless this is
a kind of "rogue" .jar file that somebody put up with some of their own
custom changes, and, though not likely, that's within the range of the
possible, but again, we don't really have control over this...) And yes,
we also have a tag in CVS corresponding to the release.
But actually, my own willingness to answer questions and have dialogue
about the FreeMarker 2.2.x code would be fairly limited. (We're about to
release version 2.3.5 BTW.) I would pretty much encourage anybody to
grab the latest code and we could continue a dialogue from there.
But really, surely you see that being an abandoned project with some
extra CVS tags is not going to be a great improvement. It's like being
somebody in the last stages of a terminal cancer who has a very good
blood cholesterol level. It's really a big "so what!"
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
blog http://freemarker.blogspot.com/
>
> --
> Serge Knystautas
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Serge Knystautas <sk...@gmail.com>.
On 2/27/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> Let's suppose that, contrary to fact, the release you mention had a
> corresponding CVS tag. Do you think that the people (if there really are
> any) relying on DVSL would be in a _significantly_ better position?
Yes. Think of this like insurance. You are correct to reason that it
is *much* better to be healthy or to not crash your car. And I agree
with you that most people do believe that the ASF projects don't crash
their cars as often as SF projects.
But when they crash, that insurance of a CVS tag was pretty darn
useful and puts you well ahead of the person without the insurance...
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Nathan Bubna" <nb...@gmail.com> writes:
>My only concern is that when Geir and Gabriel started VelocityTools,
>they decided to develop most of the documentation with Geir's new DVSL
>tool. :) It's worked great, but abandoning DVSL means reformatting
>the docs for some other tool. it might honestly be less effort to
>spruce up DVSL a bit in the short term. but then there's that whole
>long term thing....
>any great ideas for a new doc tool? anyone know much about APT?
Or Doxia? Considering the fact that Doxia comes out of the same corner
as the xdoc/Anakia idea, it is probably as future safe. ==:-)
Personally, if I do have to do new docs for code, I try to stick with
well established standards. Which seem to be Docbook these days (which
was not invented at the ASF...).
If it is DVSL, it should be renderable with Maven in no time. The
whole Velocity doc is driven in the same way and builds fine using
Maven. And if you are into pain, it should be possible to use XSLT to
convert the docs into web pages. :-)
Ah, I forgot, they deprecated xdoc in m2 in favor of doxia.
Best regards
Henning
P.S.: Sorry Geir if I stepped on your toes here, I know that you were
heavily involved with DVSL/Anakia and xdoc, but the whole thing has
proven to be such a PITA and is IMHO is the reason that most Maven
driven project sites are either empty or simply provide a link to an
external site for documentation.
>On 3/5/06, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
>> "Henri Yandell" <fl...@gmail.com> writes:
>>
>> [Gee, I wandered of for some time, then went on holidays and what do I
>> find when I return here? Yet _another_ "my templating engine is better
>> than your templating engine" thread featuring the incomparable talents
>> of Mr. Jonathan Revusky and Mr. Daniel Dekany (sp?) Can we all please
>> grow up at some point? Didn't we rehash the "my error reporting is
>> better than your error reporting" and "my macros are better than your
>> macros" to death? How about "my user base is bigger than your user
>> base?"]
>>
>> >None of the above means we should treat a release any less though;
>> >interested in hearing from the velocity guys when a DVSL 0.46 jar will
>> >be released to iBiblio properly.
>>
>> Actually, when I was browsing this thread, I was thinking about
>> calling a vote "who is still interested in maintaining DVSL?" and if
>> noone shows up, mothballing it on archives. Even maven uses a
>> different processor these days as far as I can see. Any opinions about
>> that?
>>
>> Best regards
>> Henning
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>>
>> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
>> Linux, Java, perl, Solaris -- Consulting, Training, Development
>>
>> Social behaviour: Bavarians can be extremely egalitarian and folksy.
>> -- http://en.wikipedia.org/wiki/Bavaria
>> Most Franconians do not like to be called Bavarians.
>> -- http://en.wikipedia.org/wiki/Franconia
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Mike Kienenberger <mk...@gmail.com>.
On 3/26/06, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> I will check out the XMLMind editor but I don't see how it will really
> help unless someone sits down and writes an xdoc CSS.
>
> Basically what the docs could really use is a DTD of xdoc. I'm not
> aware that such a thing exists (which might be explained with the fact
> that not really a good xdoc documentation exists... =8-/ )
Yes, the lack of a valid dtd was the problem I ran into when I tried
to use XMLMind (free) to edit the MyFaces xdocs.
I did manage to locate the following xdocs dtd, but I ran out of time
to try to get it working.
http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/xdoc/src/dtd/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Henning P. Schmiedehausen wrote:
> "Mike Kienenberger" <mk...@gmail.com> writes:
>
>> I'd recommend keeping the docs in an xml format -- documentation
>> standards seem to change every year.
>
> I'm really +1 here.
>
> I can tell you folks what I did in my free (hah!) time in the last two weeks:
>
> - I checked whether there is a decent tool to edit xdocs. Basically there is
> not. There isn't even a DTD of xdoc, which makes it even harder to use an
> XML editor.
>
> - I looked into OpenOffice 2.x and its docbook support. It should work, however
> I wasn't really able to get it to run. And the docbook <-> OpenOffice
> mappings are not really intuitive. And the result is that it produces not
> really a web site.
>
> I will check out the XMLMind editor but I don't see how it will really
> help unless someone sits down and writes an xdoc CSS.
>
> Basically what the docs could really use is a DTD of xdoc. I'm not
> aware that such a thing exists (which might be explained with the fact
> that not really a good xdoc documentation exists... =8-/ )
>
It should be very straightforward as xdoc is so simple...
geir
> Best regards
> Henning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Mike Kienenberger" <mk...@gmail.com> writes:
>I'd recommend keeping the docs in an xml format -- documentation
>standards seem to change every year.
I'm really +1 here.
I can tell you folks what I did in my free (hah!) time in the last two weeks:
- I checked whether there is a decent tool to edit xdocs. Basically there is
not. There isn't even a DTD of xdoc, which makes it even harder to use an
XML editor.
- I looked into OpenOffice 2.x and its docbook support. It should work, however
I wasn't really able to get it to run. And the docbook <-> OpenOffice
mappings are not really intuitive. And the result is that it produces not
really a web site.
I will check out the XMLMind editor but I don't see how it will really
help unless someone sits down and writes an xdoc CSS.
Basically what the docs could really use is a DTD of xdoc. I'm not
aware that such a thing exists (which might be explained with the fact
that not really a good xdoc documentation exists... =8-/ )
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Why isn't OO good for DocBook work?
Because it's totally primitive and doesn't have complete support for
DocBook.
> Does XMLMind try to do wysiwyg for docbook?
Not just WYSIWYG but validations and other productivity small
but very efficient work improvement features.
One must try it to see them.
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
interesting.
Why isn't OO good for DocBook work?
Does XMLMind try to do wysiwyg for docbook?
Ahmed Mohombe wrote:
>> Even better, I just noticed that OpenOffice Writer claims to output
>> DocBook. I don't know how conformant the output is...
> OpenOffice is not very good for DocBook work. "I had them all" :), and
> XMLMind is much better.
> It's also free so I see no reason to make my life more complicated than
> it should be :).
>
> Ahmed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Even better, I just noticed that OpenOffice Writer claims to output
> DocBook. I don't know how conformant the output is...
OpenOffice is not very good for DocBook work. "I had them all" :), and XMLMind is much better.
It's also free so I see no reason to make my life more complicated than it should be :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Even better, I just noticed that OpenOffice Writer claims to output
DocBook. I don't know how conformant the output is...
Ahmed Mohombe wrote:
>>> any great ideas for a new doc tool? anyone know much about APT?
>>
>> [First off, I've only glanced at some converted APT documents.]
>>
>> We started converting from xdocs to apt for MyFaces, but I think we're
>> going to abandon that effort. apt is more like a wiki markup -- once
>> you convert to it, there's no XML transformation to convert to another
>> format if you change your methodology.
>>
>> There's also been reports that there are limitations on what you can
>> do with apt (again, like a wiki.)
>>
>> I'd recommend keeping the docs in an xml format -- documentation
>> standards seem to change every year.
> I'm not aware that DocBook would have changed to something else :).
> With a nice editor like XMLMind it's just as simple to use as a word
> document.
>
> Ahmed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Ahmed Mohombe <am...@yahoo.com>.
>> With a nice editor like XMLMind it's just as simple to use as a word document.
>
> Is it really good? I glanced at the web site and thought that 220 EUR
> is quite steep for a "simple XML editor". The good thing is that it
> runs on Linux. XMLSpy Professional edition is just twice the price
> (399 EUR) and offers quite a number of features. But does not run on
> Linux. :-(
Yes, it is really good. One doesn't need to buy the commercial license - it's an option
but the free version is equally good and depends on the "use situation" what to choose.
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Ahmed Mohombe <am...@yahoo.com> writes:
>With a nice editor like XMLMind it's just as simple to use as a word document.
Is it really good? I glanced at the web site and thought that 220 EUR
is quite steep for a "simple XML editor". The good thing is that it
runs on Linux. XMLSpy Professional edition is just twice the price
(399 EUR) and offers quite a number of features. But does not run on
Linux. :-(
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Ahmed Mohombe <am...@yahoo.com>.
>> any great ideas for a new doc tool? anyone know much about APT?
>
> [First off, I've only glanced at some converted APT documents.]
>
> We started converting from xdocs to apt for MyFaces, but I think we're
> going to abandon that effort. apt is more like a wiki markup -- once
> you convert to it, there's no XML transformation to convert to another
> format if you change your methodology.
>
> There's also been reports that there are limitations on what you can
> do with apt (again, like a wiki.)
>
> I'd recommend keeping the docs in an xml format -- documentation
> standards seem to change every year.
I'm not aware that DocBook would have changed to something else :).
With a nice editor like XMLMind it's just as simple to use as a word document.
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Geir Magnusson Jr wrote:
> the other question I have is "how stable is the output?" Will different
> VMs w/ different XSLT impls produce byte-compatible output?
>
First, no. If the xsl:output had indent set to 'no', then perhaps.
Different processor indent differently.
You could also add:
<xsl:strip-space elements="*"/>
to remove all the unnecessary whitespace.
But why would the output be important to be byte-compatible? (I don't
see the output being versioned)
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
the other question I have is "how stable is the output?" Will different
VMs w/ different XSLT impls produce byte-compatible output?
Robert Koberg wrote:
> Here is an XSL that should transform the xdocs. I took a quick look at
> the user docs xdoc and the source of the rendered page. I did not see
> where the left menu/nav came from. I assume it is just well formed html
> and can be included as is shown in the XSL below (does this look painful
> :). If the source XML was in its own directory, you could just use ant's
> Xslt task to transform the site:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
>
> <xsl:output encoding="UTF-8" indent="yes" method="html"/>
>
> <!-- Identity template - copies stuff not overridden below -->
> <xsl:template match="@* | node()">
> <xsl:copy>
> <xsl:apply-templates select="@*"/>
> <xsl:apply-templates/>
> </xsl:copy>
> </xsl:template>
>
> <!-- basic page layout -->
> <xsl:template match="/">
> <html>
> <head>
> <title>
>
> <xsl:value-of select="document/properties/title"/>
>
> </title>
> <meta name="author" value="Velocity Documentation Team"/>
> <link rel="stylesheet"
> href="http://jakarta.apache.org/velocity/site.css" type="text/css"/>
> <link rel="stylesheet" href="./site.css" type="text/css"/>
> </head>
> <body>
> <div id="container">
> <div id="header">
> <div id="logo1">
> <a href="http://jakarta.apache.org">
> <img
> src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/>
> </a>
> </div>
> <div id="logo2">
> <a href="http://jakarta.apache.org/velocity/">
> <img src="./images/newlogo.png" alt="Velocity" border="0"/>
> </a>
> </div>
> <div class="menusection">
> <span class="menuheader">Velocity</span>
>
> <!-- copy in the nav -->
> <xsl:apply-templates select="document('nav.xml')"/>
>
> </div>
>
> <!-- fill in body content -->
> <xsl:apply-templates select="document/body"/>
>
> </div>
> </div>
> </body>
> </html>
> </xsl:template>
>
> <!-- override identity transformation -->
>
> <xsl:template match="section | subsection">
> <div id="{@href}" class="{local-name()}">
> <xsl:choose>
> <xsl:when test="local-name()='section'">
> <h2>
> <xsl:value-of select="@name"/>
> </h2>
> </xsl:when>
> <xsl:when test="local-name()='subsection'">
> <h3>
> <xsl:value-of select="@name"/>
> </h3>
> </xsl:when>
> <xsl:otherwise>
> <strong style="color:red">Have not accounted for elements
> name: <xsl:value-of select="local-name()"/></strong>
> </xsl:otherwise>
> </xsl:choose>
> <xsl:apply-templates/>
> </div>
> </xsl:template>
>
> <xsl:template match="source">
> <pre>
> <xsl:apply-templates/>
> </pre>
> </xsl:template>
>
> </xsl:stylesheet>
>
>
>
> Nathan Bubna wrote:
>> On 3/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
>>
>>> On 3/5/06, Nathan Bubna <nb...@gmail.com> wrote:
>>>
>>>> any great ideas for a new doc tool? anyone know much about APT?
>>>
>>> [First off, I've only glanced at some converted APT documents.]
>>>
>>> We started converting from xdocs to apt for MyFaces, but I think we're
>>> going to abandon that effort. apt is more like a wiki markup -- once
>>> you convert to it, there's no XML transformation to convert to another
>>> format if you change your methodology.
>>>
>>> There's also been reports that there are limitations on what you can
>>> do with apt (again, like a wiki.)
>>>
>>> I'd recommend keeping the docs in an xml format -- documentation
>>> standards seem to change every year.
>>
>>
>> very good advice. between this and the option to use Anakia, i think
>> we'll be keeping them basically as they are, just adapting the
>> transformation process as needed.
>>
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Geir Magnusson Jr wrote:
> the left side nav comes from an xml file in xdocs/stylesheets.
OK. I had thought of another way to handle it that is perhaps better,
performance-wise. You could have another XSL that is import'ed or
include'd that has a named template that contains the nav. When using
something like ant to transform, the Templates object would be cached so
the nav wouldn't need to be reparsed for each transform:
<xsl:template name="left-nav">
<!-- nav (X)HTML -->
</xsl:template>
>> <div class="menusection">
>> <span class="menuheader">Velocity</span>
>>
>> <!-- copy in the nav
>> <xsl:apply-templates select="document('nav.xml')"/> -->
<xsl:call-template name="left-nav"/>
>>
>> </div>
>>
>> <!-- fill in body content -->
>> <xsl:apply-templates select="document/body"/>
>>
This should have been:
<xsl:apply-templates select="document/body/*"/>
so it does not copy the body element.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
the left side nav comes from an xml file in xdocs/stylesheets.
Robert Koberg wrote:
> Here is an XSL that should transform the xdocs. I took a quick look at
> the user docs xdoc and the source of the rendered page. I did not see
> where the left menu/nav came from. I assume it is just well formed html
> and can be included as is shown in the XSL below (does this look painful
> :). If the source XML was in its own directory, you could just use ant's
> Xslt task to transform the site:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
>
> <xsl:output encoding="UTF-8" indent="yes" method="html"/>
>
> <!-- Identity template - copies stuff not overridden below -->
> <xsl:template match="@* | node()">
> <xsl:copy>
> <xsl:apply-templates select="@*"/>
> <xsl:apply-templates/>
> </xsl:copy>
> </xsl:template>
>
> <!-- basic page layout -->
> <xsl:template match="/">
> <html>
> <head>
> <title>
>
> <xsl:value-of select="document/properties/title"/>
>
> </title>
> <meta name="author" value="Velocity Documentation Team"/>
> <link rel="stylesheet"
> href="http://jakarta.apache.org/velocity/site.css" type="text/css"/>
> <link rel="stylesheet" href="./site.css" type="text/css"/>
> </head>
> <body>
> <div id="container">
> <div id="header">
> <div id="logo1">
> <a href="http://jakarta.apache.org">
> <img
> src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/>
> </a>
> </div>
> <div id="logo2">
> <a href="http://jakarta.apache.org/velocity/">
> <img src="./images/newlogo.png" alt="Velocity" border="0"/>
> </a>
> </div>
> <div class="menusection">
> <span class="menuheader">Velocity</span>
>
> <!-- copy in the nav -->
> <xsl:apply-templates select="document('nav.xml')"/>
>
> </div>
>
> <!-- fill in body content -->
> <xsl:apply-templates select="document/body"/>
>
> </div>
> </div>
> </body>
> </html>
> </xsl:template>
>
> <!-- override identity transformation -->
>
> <xsl:template match="section | subsection">
> <div id="{@href}" class="{local-name()}">
> <xsl:choose>
> <xsl:when test="local-name()='section'">
> <h2>
> <xsl:value-of select="@name"/>
> </h2>
> </xsl:when>
> <xsl:when test="local-name()='subsection'">
> <h3>
> <xsl:value-of select="@name"/>
> </h3>
> </xsl:when>
> <xsl:otherwise>
> <strong style="color:red">Have not accounted for elements
> name: <xsl:value-of select="local-name()"/></strong>
> </xsl:otherwise>
> </xsl:choose>
> <xsl:apply-templates/>
> </div>
> </xsl:template>
>
> <xsl:template match="source">
> <pre>
> <xsl:apply-templates/>
> </pre>
> </xsl:template>
>
> </xsl:stylesheet>
>
>
>
> Nathan Bubna wrote:
>> On 3/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
>>
>>> On 3/5/06, Nathan Bubna <nb...@gmail.com> wrote:
>>>
>>>> any great ideas for a new doc tool? anyone know much about APT?
>>>
>>> [First off, I've only glanced at some converted APT documents.]
>>>
>>> We started converting from xdocs to apt for MyFaces, but I think we're
>>> going to abandon that effort. apt is more like a wiki markup -- once
>>> you convert to it, there's no XML transformation to convert to another
>>> format if you change your methodology.
>>>
>>> There's also been reports that there are limitations on what you can
>>> do with apt (again, like a wiki.)
>>>
>>> I'd recommend keeping the docs in an xml format -- documentation
>>> standards seem to change every year.
>>
>>
>> very good advice. between this and the option to use Anakia, i think
>> we'll be keeping them basically as they are, just adapting the
>> transformation process as needed.
>>
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Here is an XSL that should transform the xdocs. I took a quick look at
the user docs xdoc and the source of the rendered page. I did not see
where the left menu/nav came from. I assume it is just well formed html
and can be included as is shown in the XSL below (does this look painful
:). If the source XML was in its own directory, you could just use ant's
Xslt task to transform the site:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output encoding="UTF-8" indent="yes" method="html"/>
<!-- Identity template - copies stuff not overridden below -->
<xsl:template match="@* | node()">
<xsl:copy>
<xsl:apply-templates select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
<!-- basic page layout -->
<xsl:template match="/">
<html>
<head>
<title>
<xsl:value-of select="document/properties/title"/>
</title>
<meta name="author" value="Velocity Documentation Team"/>
<link rel="stylesheet"
href="http://jakarta.apache.org/velocity/site.css" type="text/css"/>
<link rel="stylesheet" href="./site.css" type="text/css"/>
</head>
<body>
<div id="container">
<div id="header">
<div id="logo1">
<a href="http://jakarta.apache.org">
<img
src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/>
</a>
</div>
<div id="logo2">
<a href="http://jakarta.apache.org/velocity/">
<img src="./images/newlogo.png" alt="Velocity" border="0"/>
</a>
</div>
<div class="menusection">
<span class="menuheader">Velocity</span>
<!-- copy in the nav -->
<xsl:apply-templates select="document('nav.xml')"/>
</div>
<!-- fill in body content -->
<xsl:apply-templates select="document/body"/>
</div>
</div>
</body>
</html>
</xsl:template>
<!-- override identity transformation -->
<xsl:template match="section | subsection">
<div id="{@href}" class="{local-name()}">
<xsl:choose>
<xsl:when test="local-name()='section'">
<h2>
<xsl:value-of select="@name"/>
</h2>
</xsl:when>
<xsl:when test="local-name()='subsection'">
<h3>
<xsl:value-of select="@name"/>
</h3>
</xsl:when>
<xsl:otherwise>
<strong style="color:red">Have not accounted for elements
name: <xsl:value-of select="local-name()"/></strong>
</xsl:otherwise>
</xsl:choose>
<xsl:apply-templates/>
</div>
</xsl:template>
<xsl:template match="source">
<pre>
<xsl:apply-templates/>
</pre>
</xsl:template>
</xsl:stylesheet>
Nathan Bubna wrote:
> On 3/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
>
>>On 3/5/06, Nathan Bubna <nb...@gmail.com> wrote:
>>
>>>any great ideas for a new doc tool? anyone know much about APT?
>>
>>[First off, I've only glanced at some converted APT documents.]
>>
>>We started converting from xdocs to apt for MyFaces, but I think we're
>>going to abandon that effort. apt is more like a wiki markup -- once
>>you convert to it, there's no XML transformation to convert to another
>>format if you change your methodology.
>>
>>There's also been reports that there are limitations on what you can
>>do with apt (again, like a wiki.)
>>
>>I'd recommend keeping the docs in an xml format -- documentation
>>standards seem to change every year.
>
>
> very good advice. between this and the option to use Anakia, i think
> we'll be keeping them basically as they are, just adapting the
> transformation process as needed.
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 3/5/06, Nathan Bubna <nb...@gmail.com> wrote:
> > any great ideas for a new doc tool? anyone know much about APT?
>
> [First off, I've only glanced at some converted APT documents.]
>
> We started converting from xdocs to apt for MyFaces, but I think we're
> going to abandon that effort. apt is more like a wiki markup -- once
> you convert to it, there's no XML transformation to convert to another
> format if you change your methodology.
>
> There's also been reports that there are limitations on what you can
> do with apt (again, like a wiki.)
>
> I'd recommend keeping the docs in an xml format -- documentation
> standards seem to change every year.
very good advice. between this and the option to use Anakia, i think
we'll be keeping them basically as they are, just adapting the
transformation process as needed.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Mike Kienenberger <mk...@gmail.com>.
On 3/5/06, Nathan Bubna <nb...@gmail.com> wrote:
> any great ideas for a new doc tool? anyone know much about APT?
[First off, I've only glanced at some converted APT documents.]
We started converting from xdocs to apt for MyFaces, but I think we're
going to abandon that effort. apt is more like a wiki markup -- once
you convert to it, there's no XML transformation to convert to another
format if you change your methodology.
There's also been reports that there are limitations on what you can
do with apt (again, like a wiki.)
I'd recommend keeping the docs in an xml format -- documentation
standards seem to change every year.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Nathan Bubna <nb...@gmail.com>.
cool. thanks for the tip. just shows that i'm a bit ignorant about
xdoc type stuff in general. :)
On 3/5/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Nathan Bubna wrote:
> > My only concern is that when Geir and Gabriel started VelocityTools,
> > they decided to develop most of the documentation with Geir's new DVSL
> > tool. :) It's worked great, but abandoning DVSL means reformatting
> > the docs for some other tool. it might honestly be less effort to
> > spruce up DVSL a bit in the short term. but then there's that whole
> > long term thing....
> >
>
> Not true. The sources for DVSL are 'standard' xdoc - so Anakia will work
> just as well.
>
> geir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Bubna wrote:
> My only concern is that when Geir and Gabriel started VelocityTools,
> they decided to develop most of the documentation with Geir's new DVSL
> tool. :) It's worked great, but abandoning DVSL means reformatting
> the docs for some other tool. it might honestly be less effort to
> spruce up DVSL a bit in the short term. but then there's that whole
> long term thing....
>
Not true. The sources for DVSL are 'standard' xdoc - so Anakia will work
just as well.
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Nathan Bubna <nb...@gmail.com>.
My only concern is that when Geir and Gabriel started VelocityTools,
they decided to develop most of the documentation with Geir's new DVSL
tool. :) It's worked great, but abandoning DVSL means reformatting
the docs for some other tool. it might honestly be less effort to
spruce up DVSL a bit in the short term. but then there's that whole
long term thing....
any great ideas for a new doc tool? anyone know much about APT?
On 3/5/06, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> "Henri Yandell" <fl...@gmail.com> writes:
>
> [Gee, I wandered of for some time, then went on holidays and what do I
> find when I return here? Yet _another_ "my templating engine is better
> than your templating engine" thread featuring the incomparable talents
> of Mr. Jonathan Revusky and Mr. Daniel Dekany (sp?) Can we all please
> grow up at some point? Didn't we rehash the "my error reporting is
> better than your error reporting" and "my macros are better than your
> macros" to death? How about "my user base is bigger than your user
> base?"]
>
> >None of the above means we should treat a release any less though;
> >interested in hearing from the velocity guys when a DVSL 0.46 jar will
> >be released to iBiblio properly.
>
> Actually, when I was browsing this thread, I was thinking about
> calling a vote "who is still interested in maintaining DVSL?" and if
> noone shows up, mothballing it on archives. Even maven uses a
> different processor these days as far as I can see. Any opinions about
> that?
>
> Best regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> Social behaviour: Bavarians can be extremely egalitarian and folksy.
> -- http://en.wikipedia.org/wiki/Bavaria
> Most Franconians do not like to be called Bavarians.
> -- http://en.wikipedia.org/wiki/Franconia
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Henri Yandell" <fl...@gmail.com> writes:
[Gee, I wandered of for some time, then went on holidays and what do I
find when I return here? Yet _another_ "my templating engine is better
than your templating engine" thread featuring the incomparable talents
of Mr. Jonathan Revusky and Mr. Daniel Dekany (sp?) Can we all please
grow up at some point? Didn't we rehash the "my error reporting is
better than your error reporting" and "my macros are better than your
macros" to death? How about "my user base is bigger than your user
base?"]
>None of the above means we should treat a release any less though;
>interested in hearing from the velocity guys when a DVSL 0.46 jar will
>be released to iBiblio properly.
Actually, when I was browsing this thread, I was thinking about
calling a vote "who is still interested in maintaining DVSL?" and if
noone shows up, mothballing it on archives. Even maven uses a
different processor these days as far as I can see. Any opinions about
that?
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Henri Yandell <fl...@gmail.com>.
On 2/27/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> Henri Yandell wrote:
> There isn't an absolute promise of that, I guess. However, I think it's
> safe to say that many people opt for ASF projects because they think
> that the likelihood of them remaining active and supported is much
> higher than with a random project they find on sourceforge.
That, and that the source will remain open, none of the bit where an
individual developer decides to turn the project they're dependent on
into a profit making personal business. Or gets 'acquired' by another
business.
You're right in that inactivity is also a huge problem; or rather
making sure we reflect inactivity on the website is a huge problem.
Jakarta's size and depth hides these issues, so currently my aim is to
flatten Jakarta so it's easier to see such things - ie) velocity would
be split into three separate subprojects of Jakarta, or it can goto
TLP: velocity.apache.org.
Then we move inactive components into an obvious inactive state - this
kind of thing is starting to happen in Commons already. Published as
inactive (well dormant is the current label).
One thing inactive components might do is point to another license and
community friendly alternative that we recommend. ie) The Jakarta BCEL
mailing list agreed that for new development we recommend ObjectWeb
ASM. Another thing that needs to be displayed on the site.
None of the above means we should treat a release any less though;
interested in hearing from the velocity guys when a DVSL 0.46 jar will
be released to iBiblio properly.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Henri Yandell wrote:
> On 2/26/06, Jonathan Revusky <re...@wanadoo.es> wrote:
>
>
>>Towards the end of the skit it is revealed that Cyril is some kid's pet
>>hamster.
>>
>>Surely you see my point. The very "seriousness", the formality around
>>the pet hamster's funeral makes it far more of a joke than it could ever
>>be otherwise. Likewise, the "concept of release" can be serious and all,
>>but if the thing being released is something of a joke, some abandonware
>>that was left in some half-baked state, doesn't all the "seriousness"
>>just make the whole thing even more of a joke?
>
>
> It doesn't seem like a joke to Cyril's owner.
Well, of course not. He, and everybody else taking part in the ceremony
is taking the whole thing *extremely* seriously.
But that is precisely what makes the situation so comical to an outside
observer....
> Users of DVSL won't be
> happy to learn that the binary jar in the Maven repository they have
> been depending on is not reproduceable; there's no source and there's
> no tag in CVS.
Well, it's not *really* unreproduceable. At least in principle. There
is, after all, a version repository, and in principle, you can
reconstruct the state of the code of any given date in the past from
that. And probably, since no further development ever took place, the
code in the trunk does correspond to the code in the .jar. Most
likely.... I dunno... But in any case, if I (or anybody) want to hack
the DVSL source code, I can get my hands on some source code to hack and
maybe do something with it. If I want...
But really, let's face it: somebody who has made a significant
investment in DVSL has bigger problems than the fact that the CVS wasn't
tagged when that specific .jar file was put up. That's a second-order
(if not, third or fourth-order) problem.
Or let me put it this way: somebody who made a significant investment in
using DVSL back when is not in a good situation really. He is relying on
something that is not being actively developed or maintained or
supported. Nor was a migration path offered to anything else.
Let's suppose that, contrary to fact, the release you mention had a
corresponding CVS tag. Do you think that the people (if there really are
any) relying on DVSL would be in a _significantly_ better position?
>
> There's an informal promise from the ASF (and open source in general)
> that binaries are released with source; there's no promise that
> projects will be kept in active development when the community is not
> interested.
There isn't an absolute promise of that, I guess. However, I think it's
safe to say that many people opt for ASF projects because they think
that the likelihood of them remaining active and supported is much
higher than with a random project they find on sourceforge.
Similarly, if I invest in a blue-chip stock, like General Electric or
Exxon or something, there is no absolute promise that the company will
not go out of business, and the shares will become worthless. In fact,
this kind of thing does happen. However, these companies are considered
to be blue chip investments precisely because the probability of this
event is reckoned to be extremely low. (In fact, this kind of belief in
this case looks to be pretty well founded. The likelihood of GE or Exxon
going bankrupt in the foreseeable future surely is negligible.)
Anyway, structurally, it's like you're arguing that, because investors
were never promised that the company could not go out of business (with
the investors consequently losing their money) the company going
bankrupt is therefore not an issue that should cause any concern.
That seems like extremely fallacious reasoning to me.
Meanwhile, it is a constant theme in my own private discussions with
people that, even when they recognize that a given ASF project is
technically inferior, they at least feel that the ASF project is somehow
the "safe" option. These people have this feeling that some random open
source project may easily just be abandoned tomorrow and that something
being on ASF provides some assurance (I don't say 'guarantee') of
continuity. This is quite important in people's decision making.
>
> Fortunately your use of the term 'abandonware' above makes my point
> for me - there is no such thing as abandonware in open source,
I can't agree with that statement. If I abandon a pet dog, it is true
that some animal lover could adopt this stray mutt and provide it a
loving home. However, the fact that somebody might do this doesn't
contradict the fact that the dog was abandoned in the first place.
Who can deny that there are open source projects that could be correctly
characterized as "abandonware"? Okay, source is available and somebody
*could* pick them up again, but they are currently in an abandoned
state. Moreover, I think it's safe to say that, in the vast majority of
cases, once abandoned, they remain that way.
> a user
> is free to continue on if the community in general stops being
> interested. However in this case, it is abandonware. There was a
> binary-only release (in fact, 4 of them, with 6 dated snapshot
> releases) - meaning the users are dependent on shifting sand when it
> comes to supporting themselves.
Well, I don't quite grasp this bit about "shifting sand". The sand sure
as heck hasn't shifted for a good while in this case. Frankly, it seems
to me that, if the sand really was shifting, this would be an
improvement in the situation (not for me but I mean a DVSL user) since
it would mean that something was actually happening, that the project
was alive.
But it's not. And that's the first-order problem, isn't it?
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog: http://freemarker.blogspot.com/
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Henri Yandell <fl...@gmail.com>.
On 2/26/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> Towards the end of the skit it is revealed that Cyril is some kid's pet
> hamster.
>
> Surely you see my point. The very "seriousness", the formality around
> the pet hamster's funeral makes it far more of a joke than it could ever
> be otherwise. Likewise, the "concept of release" can be serious and all,
> but if the thing being released is something of a joke, some abandonware
> that was left in some half-baked state, doesn't all the "seriousness"
> just make the whole thing even more of a joke?
It doesn't seem like a joke to Cyril's owner. Users of DVSL won't be
happy to learn that the binary jar in the Maven repository they have
been depending on is not reproduceable; there's no source and there's
no tag in CVS.
There's an informal promise from the ASF (and open source in general)
that binaries are released with source; there's no promise that
projects will be kept in active development when the community is not
interested.
Fortunately your use of the term 'abandonware' above makes my point
for me - there is no such thing as abandonware in open source, a user
is free to continue on if the community in general stops being
interested. However in this case, it is abandonware. There was a
binary-only release (in fact, 4 of them, with 6 dated snapshot
releases) - meaning the users are dependent on shifting sand when it
comes to supporting themselves.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Opinion noted.
geir
Jonathan Revusky wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Jonathan Revusky wrote:
>>
>>> Geir Magnusson Jr wrote:
>>>
>>>> I wouldn't call it "rogue" :)
>>>>
>>>> I'm surprised that there weren't any version tags, as I am usually
>>>> very good about that...
>>>>
>>>> Do you want to see a release?
>>>
>>>
>>> This whole discussion strikes me as odd. To me, the reasons for a new
>>> release are that you have new features and/or bugfixes that you want
>>> to get out there. Why on earth would you put out a new release of
>>> something that has not been actively developed for at least 3 years,
>>> and, of which nobody really has taken ownership, something that is
>>> basically abandonware?
>>
>>
>> Because at the ASF, the concept of release is a serious thing.
>
> "The concept of release is a serious thing."
>
> Hmm... My first reaction to this sentence was basically: "What on earth
> is this guy saying?" Like, does this mean that, elsewhere, the "concept"
> of release is *not* a "serious" thing? And what does that mean, pray
> tell...
>
> Well, okay, it may be that there is some greater seriousness than
> average at ASF regarding the various kind of administrative/bureaucratic
> procedures around a release, and what it means to label a release as RC
> vs. final vs. preview or whatever.... though I don't honestly know
> either...
>
> The problem I see is that when you are serious about all the formalities
> and procedures around something when the "something" in question is a
> joke, then the whole thing is really kind of a bigger joke.
>
> I mean, one could think of some kind of monty-python-esque skit in which
> you have a very formal sort of funeral, everybody dressed in somber
> attire, solemn eulogies being offered, and the priest in all the
> priestly attire speaking solemnly and so on. "Ah, Cyril, I knew him
> well." "The first time I met Cyril...." Later, a 21-gun salute is
> offered, like a full state funeral. Flags flying at half mast...
>
> Towards the end of the skit it is revealed that Cyril is some kid's pet
> hamster.
>
> Surely you see my point. The very "seriousness", the formality around
> the pet hamster's funeral makes it far more of a joke than it could ever
> be otherwise. Likewise, the "concept of release" can be serious and all,
> but if the thing being released is something of a joke, some abandonware
> that was left in some half-baked state, doesn't all the "seriousness"
> just make the whole thing even more of a joke?
>
>
>> Henri pointed out that for some reason, it's not clear that there was
>> an official release of this, so just for that reason, there should be.
>
> Yes, but again, this is formalistic, bureaucratic discussion around
> something that... let's face it... is something of a joke.
>
>>
>>>
>>> In whose interest is it to encourage people to use code that is not
>>> being actively maintained or supported? That is what you would be
>>> doing by putting out some kind of official release of DVSL.
>>
>>
>> If people want to use it, that's their option. If they then want to
>> contribute to it, they are not only welcome, but encouraged.
>
>
> Well, typically, a con-man will defend himself by saying that the person
> getting conned is acting of his own free will.
>
> For example, somebody who makes a living peddling low-quality penny
> stock investments will say that the people who buy this stuff (and
> invariably lose their money) were fully aware of the risk of losing
> their money and so on. That's true as far as it goes. The problem is
> that the penny stock huckster invariably was trying to create the
> impression that the underlying companies were much more solid
> investments than they actually were. Also, the person who bought this
> stuff was not a sophisticated stock investor, but a nice little old lady
> or some other kind of stock market neophyte, who did not fully
> understand how risky these investments were.
>
> If somebody knowingly wants to use software that is in a completely
> abandoned, orphaned state, that is their right, just as if they want to
> invest in near-worthless penny stocks.
>
> There is only a problem if somebody is misrepresenting what these things
> are. My concern would be that, by putting out a release, you could be
> sending the signal that this really is an active project, when it is
> not. I think there is some moral hazard in that.
>
> After all, with the money that granny put into those penny stocks, she
> could have bought some good blue chip investments that would at least
> hold their value and probably appreciate. Similarly, the dead end effort
> that somebody puts into some obsolete abandonware project could have
> been invested in mastering some software tool that is actively
> maintained and developed.
>
> But the real question is whether your goal here is self-promotion,
> promoting your own work independently of its quality -- or whether you
> want to play a positive, helpful role for people.
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project http://freemarker.org
> Declarative XML processing with FreeMarker:
> http://freemarker.org/docs/xgui_declarative_basics.html
>
>
>
>>
>> geir
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Geir Magnusson Jr wrote:
>
>
> Jonathan Revusky wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>> I wouldn't call it "rogue" :)
>>>
>>> I'm surprised that there weren't any version tags, as I am usually
>>> very good about that...
>>>
>>> Do you want to see a release?
>>
>>
>> This whole discussion strikes me as odd. To me, the reasons for a new
>> release are that you have new features and/or bugfixes that you want
>> to get out there. Why on earth would you put out a new release of
>> something that has not been actively developed for at least 3 years,
>> and, of which nobody really has taken ownership, something that is
>> basically abandonware?
>
>
> Because at the ASF, the concept of release is a serious thing.
"The concept of release is a serious thing."
Hmm... My first reaction to this sentence was basically: "What on earth
is this guy saying?" Like, does this mean that, elsewhere, the "concept"
of release is *not* a "serious" thing? And what does that mean, pray tell...
Well, okay, it may be that there is some greater seriousness than
average at ASF regarding the various kind of administrative/bureaucratic
procedures around a release, and what it means to label a release as RC
vs. final vs. preview or whatever.... though I don't honestly know either...
The problem I see is that when you are serious about all the formalities
and procedures around something when the "something" in question is a
joke, then the whole thing is really kind of a bigger joke.
I mean, one could think of some kind of monty-python-esque skit in which
you have a very formal sort of funeral, everybody dressed in somber
attire, solemn eulogies being offered, and the priest in all the
priestly attire speaking solemnly and so on. "Ah, Cyril, I knew him
well." "The first time I met Cyril...." Later, a 21-gun salute is
offered, like a full state funeral. Flags flying at half mast...
Towards the end of the skit it is revealed that Cyril is some kid's pet
hamster.
Surely you see my point. The very "seriousness", the formality around
the pet hamster's funeral makes it far more of a joke than it could ever
be otherwise. Likewise, the "concept of release" can be serious and all,
but if the thing being released is something of a joke, some abandonware
that was left in some half-baked state, doesn't all the "seriousness"
just make the whole thing even more of a joke?
> Henri
> pointed out that for some reason, it's not clear that there was an
> official release of this, so just for that reason, there should be.
Yes, but again, this is formalistic, bureaucratic discussion around
something that... let's face it... is something of a joke.
>
>>
>> In whose interest is it to encourage people to use code that is not
>> being actively maintained or supported? That is what you would be
>> doing by putting out some kind of official release of DVSL.
>
>
> If people want to use it, that's their option. If they then want to
> contribute to it, they are not only welcome, but encouraged.
Well, typically, a con-man will defend himself by saying that the person
getting conned is acting of his own free will.
For example, somebody who makes a living peddling low-quality penny
stock investments will say that the people who buy this stuff (and
invariably lose their money) were fully aware of the risk of losing
their money and so on. That's true as far as it goes. The problem is
that the penny stock huckster invariably was trying to create the
impression that the underlying companies were much more solid
investments than they actually were. Also, the person who bought this
stuff was not a sophisticated stock investor, but a nice little old lady
or some other kind of stock market neophyte, who did not fully
understand how risky these investments were.
If somebody knowingly wants to use software that is in a completely
abandoned, orphaned state, that is their right, just as if they want to
invest in near-worthless penny stocks.
There is only a problem if somebody is misrepresenting what these things
are. My concern would be that, by putting out a release, you could be
sending the signal that this really is an active project, when it is
not. I think there is some moral hazard in that.
After all, with the money that granny put into those penny stocks, she
could have bought some good blue chip investments that would at least
hold their value and probably appreciate. Similarly, the dead end effort
that somebody puts into some obsolete abandonware project could have
been invested in mastering some software tool that is actively
maintained and developed.
But the real question is whether your goal here is self-promotion,
promoting your own work independently of its quality -- or whether you
want to play a positive, helpful role for people.
Jonathan Revusky
--
lead developer, FreeMarker project http://freemarker.org
Declarative XML processing with FreeMarker:
http://freemarker.org/docs/xgui_declarative_basics.html
>
> geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jonathan Revusky wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Henri Yandell wrote:
>>
>>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>>> the Maven repository; there are no tags in SVN and there's been no
>>> release on the site. I took a quick look and he's right; it's not a
>>> cvs2svn issue as there were no tags in CVS either.
>>>
>>> Is the 0.45 jar an unofficial rogue one?
>>
>>
>> I wouldn't call it "rogue" :)
>>
>> I'm surprised that there weren't any version tags, as I am usually
>> very good about that...
>>
>> Do you want to see a release?
>
> This whole discussion strikes me as odd. To me, the reasons for a new
> release are that you have new features and/or bugfixes that you want to
> get out there. Why on earth would you put out a new release of something
> that has not been actively developed for at least 3 years, and, of which
> nobody really has taken ownership, something that is basically abandonware?
Because at the ASF, the concept of release is a serious thing. Henri
pointed out that for some reason, it's not clear that there was an
official release of this, so just for that reason, there should be.
>
> In whose interest is it to encourage people to use code that is not
> being actively maintained or supported? That is what you would be doing
> by putting out some kind of official release of DVSL.
If people want to use it, that's their option. If they then want to
contribute to it, they are not only welcome, but encouraged.
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Geir Magnusson Jr wrote:
>
>
> Henri Yandell wrote:
>
>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>> the Maven repository; there are no tags in SVN and there's been no
>> release on the site. I took a quick look and he's right; it's not a
>> cvs2svn issue as there were no tags in CVS either.
>>
>> Is the 0.45 jar an unofficial rogue one?
>
>
> I wouldn't call it "rogue" :)
>
> I'm surprised that there weren't any version tags, as I am usually very
> good about that...
>
> Do you want to see a release?
This whole discussion strikes me as odd. To me, the reasons for a new
release are that you have new features and/or bugfixes that you want to
get out there. Why on earth would you put out a new release of something
that has not been actively developed for at least 3 years, and, of which
nobody really has taken ownership, something that is basically abandonware?
In whose interest is it to encourage people to use code that is not
being actively maintained or supported? That is what you would be doing
by putting out some kind of official release of DVSL.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> geir
>
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Geir Magnusson Jr wrote:
>
>
> Robert Koberg wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>>
>>> I'm not sure that a template engine should be a "serious XML
>>> tranformation tool", <snip/>
>>
>>
>> I am glad you are not sure. I would agree for a runtime system, but I
>> would disagree in pretty much any other situation. Of course there is
>> a problem with people having the skills - but for
>> handling/transforming content, there is no better way than using XSL!
>
>
> That was the problem I ran into when doing serious work in this area
> some years ago. It's a powerful tool, but when using it for content
> layout, it was rare to find people with good visual design skills *and*
> the XSL skills...
yea, it's a bummer.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Robert Koberg wrote:
> Geir Magnusson Jr wrote:
>
>>
>> I'm not sure that a template engine should be a "serious XML
>> tranformation tool", <snip/>
>
> I am glad you are not sure. I would agree for a runtime system, but I
> would disagree in pretty much any other situation. Of course there is a
> problem with people having the skills - but for handling/transforming
> content, there is no better way than using XSL!
That was the problem I ran into when doing serious work in this area
some years ago. It's a powerful tool, but when using it for content
layout, it was rare to find people with good visual design skills *and*
the XSL skills...
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Geir Magnusson Jr wrote:
>
> I'm not sure that a template engine should be a "serious XML
> tranformation tool", <snip/>
I am glad you are not sure. I would agree for a runtime system, but I
would disagree in pretty much any other situation. Of course there is a
problem with people having the skills - but for handling/transforming
content, there is no better way than using XSL!
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Daniel Dekany wrote:
> Saturday, February 25, 2006, 10:27:53 PM, Geir Magnusson Jr wrote:
>
> [snip]
>> If I recall, it took you quite some time to copy the lame velocimarco
>> functionality for freemarker ;) I'm sure your implementation was vastly
>> superior, but you'd be a moron if you didn't address deficiencies in the
>> thing that you copied. That's how science and technology progresses,
>> right? "Stand on the shoulders of giants", and all that. Velocimacros
>> wasn't an original idea in itself, but was new to templating solutions
>> at that time. Man, how the years go by.
> [snip]
>
> :-D !!! Sure, Velocity was the first project on the earth that has
> used macros (which are, basically, procedures)! What a revolutionary
> invention! How you guys didn't get Nobel Prize? And, obviously,
> anybody who have macros in its whatever language copies Velocity...
>
> Now, you just try to kill Jonathan by causing heart attack, right? Or,
> you had a stroke recently... :)
>
You did notice that I said "Velocimacros weren't an original idea in
itself" right? :)
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, February 25, 2006, 10:27:53 PM, Geir Magnusson Jr wrote:
[snip]
> If I recall, it took you quite some time to copy the lame velocimarco
> functionality for freemarker ;) I'm sure your implementation was vastly
> superior, but you'd be a moron if you didn't address deficiencies in the
> thing that you copied. That's how science and technology progresses,
> right? "Stand on the shoulders of giants", and all that. Velocimacros
> wasn't an original idea in itself, but was new to templating solutions
> at that time. Man, how the years go by.
[snip]
:-D !!! Sure, Velocity was the first project on the earth that has
used macros (which are, basically, procedures)! What a revolutionary
invention! How you guys didn't get Nobel Prize? And, obviously,
anybody who have macros in its whatever language copies Velocity...
Now, you just try to kill Jonathan by causing heart attack, right? Or,
you had a stroke recently... :)
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Serge Knystautas <sk...@gmail.com>.
On 2/25/06, Robert Koberg <ro...@koberg.com> wrote:
> Yep, any chance of answering the questions above?
>
> <snip/>
>
> > I would be surprised as well. But were I doing serious XML processing,
> > I wouldn't be using a templating engine for anything but templating.
> >
>
> Yep, I would use XSL/SAX/[some]DOM for serious XML processing. I was
> trying to get to the limits/functionality/ability of DVSL. From the
> (lack of) response from Geir, I don't think DVSL should be compared to
> (marketed as) XSL.
Rob,
In terms of answering your questions, I would just look at the few
DVSL examples and kick the tires so to speak. A few years back I
wrote a prototype of the code metrics system that took the XML reports
from findbugs, checkstyle, pmd, and others and transformed that into
HTML. I was relatively new to both DVSL and XSLT, and DVSL worked
pretty well for my needs while XSLT quickly became very laborious for
complex transformations.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Robert Koberg wrote:
> Hi - see comments below
>
>>>> - how are namespaces handled? how do you declare them? Is XPath
>>>> fully supported (uses Jaxen perhaps?)?
>>>>
>>>> - are there modes and named templates?
>>>>
>>>> - can you do something like:
>>>>
>>>> #if ($foo)
>>>> #match("foo")$context.applyTemplates()#end
>>>> #else
>>>> #match("*")$context.applyTemplates()#end
>>>> #end
>>>>
>>>> - can you use the XML nodes in a conditional. For example say I have
>>>> a source like:
>>>>
>>>> <foo bar="something"/>
>>>>
>>>> Can an if be like an XSL if testing the existence of the bar
>>>> attribute like:
>>>>
>>>> #if (@bar)
>>>> do something...
>>>> #end
>
>
>>
>> I'm not sure that a template engine should be a "serious XML
>> tranformation tool", but I suppose that's the beauty of software
>> marketing - you can always just reposition if there isn't uptake in
>> current incarnation.
>>
>> The point of DVSL is to have a separate tool to handle the XML
>> processing, and just invoke velocity templates for output formatting.
>> The intent was to replace anakia, which is really just a procedural
>> approach to rendering our xml-based documentation system.
>
> Yep, any chance of answering the questions above?
Sorry - did in a separate email.
>
> <snip/>
>
>> I would be surprised as well. But were I doing serious XML
>> processing, I wouldn't be using a templating engine for anything but
>> templating.
>>
>
> Yep, I would use XSL/SAX/[some]DOM for serious XML processing. I was
> trying to get to the limits/functionality/ability of DVSL. From the
> (lack of) response from Geir, I don't think DVSL should be compared to
> (marketed as) XSL.
No, and it generally isn't, but XSL is what it was patterned after, so
being able to say "like XSL" helps people grok it...
I think that the top blub is pretty honest :
http://jakarta.apache.org/velocity/dvsl/index.html
geir
>
> best,
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Hi - see comments below
>>> - how are namespaces handled? how do you declare them? Is XPath fully
>>> supported (uses Jaxen perhaps?)?
>>>
>>> - are there modes and named templates?
>>>
>>> - can you do something like:
>>>
>>> #if ($foo)
>>> #match("foo")$context.applyTemplates()#end
>>> #else
>>> #match("*")$context.applyTemplates()#end
>>> #end
>>>
>>> - can you use the XML nodes in a conditional. For example say I have
>>> a source like:
>>>
>>> <foo bar="something"/>
>>>
>>> Can an if be like an XSL if testing the existence of the bar
>>> attribute like:
>>>
>>> #if (@bar)
>>> do something...
>>> #end
>
> I'm not sure that a template engine should be a "serious XML
> tranformation tool", but I suppose that's the beauty of software
> marketing - you can always just reposition if there isn't uptake in
> current incarnation.
>
> The point of DVSL is to have a separate tool to handle the XML
> processing, and just invoke velocity templates for output formatting.
> The intent was to replace anakia, which is really just a procedural
> approach to rendering our xml-based documentation system.
Yep, any chance of answering the questions above?
<snip/>
> I would be surprised as well. But were I doing serious XML processing,
> I wouldn't be using a templating engine for anything but templating.
>
Yep, I would use XSL/SAX/[some]DOM for serious XML processing. I was
trying to get to the limits/functionality/ability of DVSL. From the
(lack of) response from Geir, I don't think DVSL should be compared to
(marketed as) XSL.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Geir Magnusson Jr wrote:
>
>
> Jonathan Revusky wrote:
>
>> Robert Koberg wrote:
>>
>> Much of the motivation behind the the new features that were
>> introduced in FreeMarker 2.3 was to make it an adequate tool to build
>> an XML transformation tool on top of. I mean, besides the obvious ones
>> of the visit/recurse directives, features like much improved
>> whitespace handling, significant improvements to the macro system,
>> with the introduction of namespaces and macros with nested content.
>> Without these things, FreeMarker could never be a serious XML
>> transformation tool.
>>
>> Since Velocity never did add these features (or hardly anything else)
>> it seems apparent to me that Velocity itself is not adequate
>> infrastructure on which to build a serious XML transformation tool.
>
>
> I'm not sure that a template engine should be a "serious XML
> tranformation tool", but I suppose that's the beauty of software
> marketing - you can always just reposition if there isn't uptake in
> current incarnation.
First of all, FreeMarker was never "repositioned" as an XML
transformation tool. It is, and always has been a general purpose
template engine. However, certain features were added to it that make it
a more adequate tool for XML processing, among other things.
In general, there seems to be some strange, confused thinking on your
part here. Let me clarify a few things:
First of all, starting from rudimentary first principles: any template
engine like FreeMarker or Velocity or WebMacro that can "merge" a java
data model with a template is *de facto* an XML transformation tool. A
DOM tree (or JDOM or DOM4J tree) is a java object model that can be
exposed to a template processing job.
By analogy, any general purpose text editor is also de facto an XML
editor, since the tool allows you to edit text and XML is just text.
OTOH, a general purpose text editor cannot be a "serious" XML editing
tool unless various special XML-related features are added. Similarly, a
general text editor cannot be a serious source code editing tool without
things like syntax highlighting and auto-indenting, among other things.
However, even so, even Microsoft Notepad is a source code editor, since
you can edit source code with it.
The above comments seem kind of obvious to me, and they don't strike me
as controversial, but I make them to provide an initial framework for
discussion. I shall continue:
A general purpose java templating engine can (and probably will) be used
to process XML, just as a general purpose text editor like emacs or vi
can (and will) be used to edit XML. Now, whether the tool incorporates
special features related to working with XML is entirely another matter.
Now, it is my view that, in its range of likely usage, a template engine
like FreeMarker or Velocity or Webmacro will often be used in
conjunction with an XML data model, so there is a strong case for
introducing the necessary functionality to handle these use cases
properly -- in a "serious" manner.
Now, even accepting (for the sake of argument) that a tool that is
completely specialized for XML (as opposed to general templating) such
as XSLT is better -- *if* all you're doing is processing XML, there
would still be substantial interest in XML-related features in a general
template engine. For example, continuing the text editor analogy, I
could accept that a specialized XML editor is going to be the best tool
for editing XML, but if I am a coder who uses emacs, say, for editing
all kinds of source code, I may prefer to use emacs for editing XML as
well. Thus, there would surely be (and is) interest in an emacs editing
mode specialized for editing XML.
You see what I mean, right? Similarly, if I use FreeMarker (or Velocity)
for all kinds of text generation tasks, I may want to use it for
XML-processing ones as well.
Given that the tool is likely to be used for XML transformation, one
might as well be serious about it and introduce the features people need
in that specific application space.
>
> The point of DVSL is to have a separate tool to handle the XML
> processing,
Well, whether you classify DVSL as a "separate tool" or as a Velocity
add-on or whatever seems somewhat arbitrary.
FreeMarker's declarative XML processing consists of two new directives
<#visit...> and <#recurse..>, as well as a built-in wrapper to expose
DOM objects to a template in an intuitive way. Also, some XML-related
built-ins were added to the core.
Now, we could have added the visit/recurse directives and XML-related
built-ins as a separately downloadable macro library along with the DOM
wrapper classes. This was even discussed as a possibility at the time.
However, finally everything was added to FreeMarker's core
functionality. In the end, this was my call, and I definitely feel now
that we made the right decision. This is a while back, so it is hard to
recall everything that was going through my mind then, but I am pretty
certain the reason, was, quite frankly, specifically to avoid what you
see here wrt this DVSL thing.
Since this declarative XML processing functionality was added as a core
part of FreeMarker, and there is absolute clarity that we are committed
to supporting this as core functionality. It is not abandonware. If I,
Daniel, and Attila drift off and other maintainers take our place, those
people will not be able to say, as Will recently did, that they are not
supporting this functionality. Visit and recurse, for example, are core
directives in the language now, just like if/else.
The result is that there is absolute clarity in our camp about what is
going on, whereas, frankly, wrt DVSL and Anakia and what not, it is all
extremely murky and unclear whether there is any willingness on
anybody's part to support or maintain these things.
<snip a bunch of nonsense about how we copied Velocimacros, already
addressed that>
>> I believe that anybody building much more than a toy app will
>> eventually find himself tearing out his hair with these limitations.
>>
>> Even if DVSL were to become more actively developed, given the
>> deficiencies in Velocity itself, it has no prospect of being a serious
>> XML transformation tool.
>
>
> The intention of velocity is just to use it for formatting... I like
> the XSLT model, but can't stand writing output (HTML) in a language that
> looks just like it (XSL). Personal itch, I guess.
>
>>
>> If you look at alfresco.org and statestep.com, you will see some
>> professional tools that leverage FreeMarker's XMl processing
>> capabilities. I have serious doubts whether anybody is currently using
>> Velocity in conjunction with DVSL for serious XML processing tasks.
>>
>
> I would be surprised as well. But were I doing serious XML processing,
> I wouldn't be using a templating engine for anything but templating.
From my perspective, this is *such* a bizarre, confused comment.
Generating human-readable output, reports or whatever, from an XML data
model combined with some kind of template *is* templating, just the same
as editing XML *is* text-editing. To be a good XML editing tool, an
general purpose text editor needs to add certain features, and to be a
good XML processing tool, a general purpose templating tool needs
certain special features.
The difference between FreeMarker and Velocity in this regard is that in
FreeMarker, the specific work to make FreeMarker a good XML processing
tool has been done. In Velocity it basically has not been done. Some
initial stuff was done, Anakia and then DVSL, but then left in a
completely abandoned half-baked state.
Since the functionality in FreeMarker was added as part of the core
product, there is clarity about it being supported in the future. The
whole situation wrt Anakia and DVSL is very murky and unclear.
I think it's obvious that this is just highly undesirable. Given this
lack of clarity, I cannot easily imagine that a rational, well informed
person would really want to touch DVSL, say, with a ten-foot pole.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project http://freemarker.org/
declarative XML processing with FreeMarker,
http://freemarker.org/docs/xgui_declarative_basics.html
>
>> I suppose all of the above could be construed as highly negative and
>> so on. But really, as a fellow developer, I think I'm doing you (and
>> anybody else reading this) a good turn. I am discouraging you from
>> wasting your valuable time and energy on something that is clearly a
>> dead end.
>>
>> Regards,
>>
>> Jonathan Revusky
>> --
>> lead developer, FreeMarker project, http://freemarker.org/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Ah. My mistake then. Sorry. :)
geir
Jonathan Revusky wrote:
> Geir Magnusson Jr wrote:
> <snip>
>
>>> Just for starters, given Velocity's deficiencies in whitespace
>>> handling, any recursively complex XML transformation will output
>>> oodles of extraneous whitespace. That could be tolerable, I suppose
>>> (though I don't quite know why anybody *should* tolerate it) but the
>>> real killer is the lameness (I can't find a better word) of
>>> Velocity's macro system. There is no notion there of scope/visibility
>>> of macros or variables. Everything just seems to live in some big
>>> global namespace where local variables and included macros and so on
>>> can happily clobber one another. And you combine this with the fact
>>> that Velocity macros pass arguments by name rather than by value
>>> probably leads to some major problems as well.
>>
>>
>> If I recall, it took you quite some time to copy the lame velocimarco
>> functionality for freemarker ;)
>
> It's late here, and I can't answer all this fatuous nonsense right now.
> Besides, I am sometimes accused of writing overly lengthy emails, and a
> complete answer would be lengthy. So, at the moment, I'll just answer
> the above point.
>
> You are completely mistaken in the above, Geir. FreeMarker's template
> language has had macros since its very beginnings. I began using
> FreeMarker in mid-1999, I believe. This was well before Velocity even
> existed, and FreeMarker had macros then. I was just a user, not a
> FreeMarker contributer, at that point.
>
>> I'm sure your implementation was vastly superior, but you'd be a moron
>> if you didn't address deficiencies in the thing that you copied.
>> That's how science and technology progresses, right? "Stand on the
>> shoulders of giants", and all that. Velocimacros wasn't an original
>> idea in itself, but was new to templating solutions at that time.
>> Man, how the years go by.
>
> FreeMarker already had macros before Velocity ever existed. They were
> not an innovation of the Velocity project, even if we are just looking
> at the java templating space.
>
> Now, I later took on much more protagonism in the FreeMarker project.
> The work I did on FreeMarker's macro system, with a lot of great input
> from Daniel Dekany and Attila Szegedi and others, was building on
> functionality already present in FreeMarker. At no point were we
> "copying" anything in Velocity. Not that there would be anything wrong
> with copying anything in Velocity, mind you. But it's not a matter of
> legitimate dispute that FreeMarker had macros before Velocity did -- in
> fact, before Velocity even existed.
>
> Now, to be generous, the source of your confusion about this could be
> that, in FM 1.x, they were called functions, not macros. But that's just
> nomenclature. FM 1.x functions were the same thing as what you call
> Velocimacros.
>
> Other points you make require correction as well, and I'll get to that
> later.
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Geir Magnusson Jr wrote:
<snip>
>> Just for starters, given Velocity's deficiencies in whitespace
>> handling, any recursively complex XML transformation will output
>> oodles of extraneous whitespace. That could be tolerable, I suppose
>> (though I don't quite know why anybody *should* tolerate it) but the
>> real killer is the lameness (I can't find a better word) of Velocity's
>> macro system. There is no notion there of scope/visibility of macros
>> or variables. Everything just seems to live in some big global
>> namespace where local variables and included macros and so on can
>> happily clobber one another. And you combine this with the fact that
>> Velocity macros pass arguments by name rather than by value probably
>> leads to some major problems as well.
>
>
> If I recall, it took you quite some time to copy the lame velocimarco
> functionality for freemarker ;)
It's late here, and I can't answer all this fatuous nonsense right now.
Besides, I am sometimes accused of writing overly lengthy emails, and a
complete answer would be lengthy. So, at the moment, I'll just answer
the above point.
You are completely mistaken in the above, Geir. FreeMarker's template
language has had macros since its very beginnings. I began using
FreeMarker in mid-1999, I believe. This was well before Velocity even
existed, and FreeMarker had macros then. I was just a user, not a
FreeMarker contributer, at that point.
> I'm sure your implementation was vastly
> superior, but you'd be a moron if you didn't address deficiencies in the
> thing that you copied. That's how science and technology progresses,
> right? "Stand on the shoulders of giants", and all that. Velocimacros
> wasn't an original idea in itself, but was new to templating solutions
> at that time. Man, how the years go by.
FreeMarker already had macros before Velocity ever existed. They were
not an innovation of the Velocity project, even if we are just looking
at the java templating space.
Now, I later took on much more protagonism in the FreeMarker project.
The work I did on FreeMarker's macro system, with a lot of great input
from Daniel Dekany and Attila Szegedi and others, was building on
functionality already present in FreeMarker. At no point were we
"copying" anything in Velocity. Not that there would be anything wrong
with copying anything in Velocity, mind you. But it's not a matter of
legitimate dispute that FreeMarker had macros before Velocity did -- in
fact, before Velocity even existed.
Now, to be generous, the source of your confusion about this could be
that, in FM 1.x, they were called functions, not macros. But that's just
nomenclature. FM 1.x functions were the same thing as what you call
Velocimacros.
Other points you make require correction as well, and I'll get to that
later.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jonathan Revusky wrote:
> Robert Koberg wrote:
>> Geir Magnusson Jr wrote:
>>
>>> The velocity aspect - templating - is the same. What it's meant to
>>> do is simply use the declarative model of XSL (which *is*
>>> complicated) and let you use Velocity to do the rendering.
>>
>>
>> Hi,
>>
>> I just had a look at this again after using Velocity for a year or
>> two. I can see some way to use this inside a Velocity template/page
>> very nicely. I believe I know XSL 1.0 pretty well. I can see how some
>> things in Velocity proper can replace some things in XSL so they do
>> not need to be repeated there. I have some quick questions questions
>> off the top of my head:
>>
>> - how are namespaces handled? how do you declare them? Is XPath fully
>> supported (uses Jaxen perhaps?)?
>>
>> - are there modes and named templates?
>>
>> - can you do something like:
>>
>> #if ($foo)
>> #match("foo")$context.applyTemplates()#end
>> #else
>> #match("*")$context.applyTemplates()#end
>> #end
>>
>> - can you use the XML nodes in a conditional. For example say I have a
>> source like:
>>
>> <foo bar="something"/>
>>
>> Can an if be like an XSL if testing the existence of the bar attribute
>> like:
>>
>> #if (@bar)
>> do something...
>> #end
>>
>> best,
>> -Rob
>
> Robert, a few years ago, I looked quite seriously at the issues involved
> in enhancing FreeMarker to become a serious XML transformation tool. At
> that time, FM had some XML processing capabilities, approximately
> analogous to Anakia, but I had no illusions that this made it a feasible
> XSLT substitute.
>
> Much of the motivation behind the the new features that were introduced
> in FreeMarker 2.3 was to make it an adequate tool to build an XML
> transformation tool on top of. I mean, besides the obvious ones of the
> visit/recurse directives, features like much improved whitespace
> handling, significant improvements to the macro system, with the
> introduction of namespaces and macros with nested content. Without these
> things, FreeMarker could never be a serious XML transformation tool.
>
> Since Velocity never did add these features (or hardly anything else) it
> seems apparent to me that Velocity itself is not adequate infrastructure
> on which to build a serious XML transformation tool.
I'm not sure that a template engine should be a "serious XML
tranformation tool", but I suppose that's the beauty of software
marketing - you can always just reposition if there isn't uptake in
current incarnation.
The point of DVSL is to have a separate tool to handle the XML
processing, and just invoke velocity templates for output formatting.
The intent was to replace anakia, which is really just a procedural
approach to rendering our xml-based documentation system.
>
> Just for starters, given Velocity's deficiencies in whitespace handling,
> any recursively complex XML transformation will output oodles of
> extraneous whitespace. That could be tolerable, I suppose (though I
> don't quite know why anybody *should* tolerate it) but the real killer
> is the lameness (I can't find a better word) of Velocity's macro system.
> There is no notion there of scope/visibility of macros or variables.
> Everything just seems to live in some big global namespace where local
> variables and included macros and so on can happily clobber one another.
> And you combine this with the fact that Velocity macros pass arguments
> by name rather than by value probably leads to some major problems as well.
If I recall, it took you quite some time to copy the lame velocimarco
functionality for freemarker ;) I'm sure your implementation was vastly
superior, but you'd be a moron if you didn't address deficiencies in the
thing that you copied. That's how science and technology progresses,
right? "Stand on the shoulders of giants", and all that. Velocimacros
wasn't an original idea in itself, but was new to templating solutions
at that time. Man, how the years go by.
>
> I believe that anybody building much more than a toy app will eventually
> find himself tearing out his hair with these limitations.
>
> Even if DVSL were to become more actively developed, given the
> deficiencies in Velocity itself, it has no prospect of being a serious
> XML transformation tool.
The intention of velocity is just to use it for formatting... I like
the XSLT model, but can't stand writing output (HTML) in a language that
looks just like it (XSL). Personal itch, I guess.
>
> If you look at alfresco.org and statestep.com, you will see some
> professional tools that leverage FreeMarker's XMl processing
> capabilities. I have serious doubts whether anybody is currently using
> Velocity in conjunction with DVSL for serious XML processing tasks.
>
I would be surprised as well. But were I doing serious XML processing,
I wouldn't be using a templating engine for anything but templating.
> I suppose all of the above could be construed as highly negative and so
> on. But really, as a fellow developer, I think I'm doing you (and
> anybody else reading this) a good turn. I am discouraging you from
> wasting your valuable time and energy on something that is clearly a
> dead end.
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Robert Koberg wrote:
> Geir Magnusson Jr wrote:
>
>> The velocity aspect - templating - is the same. What it's meant to do
>> is simply use the declarative model of XSL (which *is* complicated)
>> and let you use Velocity to do the rendering.
>
>
> Hi,
>
> I just had a look at this again after using Velocity for a year or two.
> I can see some way to use this inside a Velocity template/page very
> nicely. I believe I know XSL 1.0 pretty well. I can see how some things
> in Velocity proper can replace some things in XSL so they do not need to
> be repeated there. I have some quick questions questions off the top of
> my head:
>
> - how are namespaces handled? how do you declare them? Is XPath fully
> supported (uses Jaxen perhaps?)?
>
> - are there modes and named templates?
>
> - can you do something like:
>
> #if ($foo)
> #match("foo")$context.applyTemplates()#end
> #else
> #match("*")$context.applyTemplates()#end
> #end
>
> - can you use the XML nodes in a conditional. For example say I have a
> source like:
>
> <foo bar="something"/>
>
> Can an if be like an XSL if testing the existence of the bar attribute
> like:
>
> #if (@bar)
> do something...
> #end
>
> best,
> -Rob
Robert, a few years ago, I looked quite seriously at the issues involved
in enhancing FreeMarker to become a serious XML transformation tool. At
that time, FM had some XML processing capabilities, approximately
analogous to Anakia, but I had no illusions that this made it a feasible
XSLT substitute.
Much of the motivation behind the the new features that were introduced
in FreeMarker 2.3 was to make it an adequate tool to build an XML
transformation tool on top of. I mean, besides the obvious ones of the
visit/recurse directives, features like much improved whitespace
handling, significant improvements to the macro system, with the
introduction of namespaces and macros with nested content. Without these
things, FreeMarker could never be a serious XML transformation tool.
Since Velocity never did add these features (or hardly anything else) it
seems apparent to me that Velocity itself is not adequate infrastructure
on which to build a serious XML transformation tool.
Just for starters, given Velocity's deficiencies in whitespace handling,
any recursively complex XML transformation will output oodles of
extraneous whitespace. That could be tolerable, I suppose (though I
don't quite know why anybody *should* tolerate it) but the real killer
is the lameness (I can't find a better word) of Velocity's macro system.
There is no notion there of scope/visibility of macros or variables.
Everything just seems to live in some big global namespace where local
variables and included macros and so on can happily clobber one another.
And you combine this with the fact that Velocity macros pass arguments
by name rather than by value probably leads to some major problems as well.
I believe that anybody building much more than a toy app will eventually
find himself tearing out his hair with these limitations.
Even if DVSL were to become more actively developed, given the
deficiencies in Velocity itself, it has no prospect of being a serious
XML transformation tool.
If you look at alfresco.org and statestep.com, you will see some
professional tools that leverage FreeMarker's XMl processing
capabilities. I have serious doubts whether anybody is currently using
Velocity in conjunction with DVSL for serious XML processing tasks.
I suppose all of the above could be construed as highly negative and so
on. But really, as a fellow developer, I think I'm doing you (and
anybody else reading this) a good turn. I am discouraging you from
wasting your valuable time and energy on something that is clearly a
dead end.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Hi and thanks for responding,
[more comments questions below. I realize it has been a while since you
touched this, so thanks in advance for any answers from you or anyone
else. They are not really important, just curious.]
Geir Magnusson Jr wrote:
>
>
> Robert Koberg wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>> The velocity aspect - templating - is the same. What it's meant to
>>> do is simply use the declarative model of XSL (which *is*
>>> complicated) and let you use Velocity to do the rendering.
>>
>>
>> Hi,
>>
>> I just had a look at this again after using Velocity for a year or
>> two. I can see some way to use this inside a Velocity template/page
>> very nicely. I believe I know XSL 1.0 pretty well. I can see how some
>> things in Velocity proper can replace some things in XSL so they do
>> not need to be repeated there. I have some quick questions questions
>> off the top of my head:
>>
>> - how are namespaces handled? how do you declare them? Is XPath fully
>> supported (uses Jaxen perhaps?)?
>
>
> It was a while ago... we were just using what was in dom4j, and that was
> jaxen, IIRC
OK. In dom4j/jaxen you have to set the namespaces to use them in an
XPath expression, for example:
org.dom4j.xpath.DefaultXPath xpath = new DefaultXPath(xpathStr);
xpath.setNamespaceURIs(namespacesMap);
The map is setup so that the keys are the prefixes and the values are
the URIs.
You can also set a namespace context with a org.jaxen.NamespaceContext.
>
>>
>> - are there modes and named templates?
>
>
> That question I don't understand.
>
In XSL you apply-templates in a mode so you can do different things with
the same node, for example:
<xsl:template match="*" mode="nav-tree">
<li>
<p><xsl:value-of select="@label"/></p>
<xsl:if test="*">
<ol>
<xsl:apply-templates mode="nav-tree"/>
</ol>
</xsl:if>
</li>
</xsl:template>
This is matching someElem and building up a nested ordered list. It will
test if there are children elements and if so continue nesting by only
send the flow to templates that have a mode="nav-tree".
Also in XSL you can have named templates, for example:
...
<html>
<xsl:call-template name="head"/>
<xsl:call-template name="body"/>
</html>
...
Which would, for instance, call:
<xsl:template name="head">
...
</xsl:template>
This jogs another question :) Can you call-template's and
apply-templates with a param, for example:
...
<xsl:apply-templates>
<xsl:with-param name="param-a" select="'string'"/>
<xsl:with-param name="param-n" select="node"/>
</xsl:apply-templates>
...
<xsl:template match="*">
<xsl:param name="param-a" select="'default'"/>
<xsl:param name="param-n" select="'defaultx'"/>
...
</xsl:template>
>>
>> - can you do something like:
>>
>> #if ($foo)
>> #match("foo")$context.applyTemplates()#end
>> #else
>> #match("*")$context.applyTemplates()#end
>> #end
>
>
> That would be cool, and (again, it's been a while, so YMMV) I think it
> should. Of course, we'd want some kind of scope, I suspect, so that
> it's not global but only applied to some local context of processing, I
> would guess.
In XSL, you would do:
<xsl:template match="possibleFooParent">
<xsl:choose>
<xsl:when test="fooElem">
<!--
If the elem 'possibleFooParent' has a child named fooElem it would come
in here. Oh, I see below that testing for nodes is not possible.
-->
...
</xsl:when>
<xsl:otherwise>
...
</xsl:otherwise>
</xsl:choose>
</xsl:template>
>
>>
>> - can you use the XML nodes in a conditional. For example say I have a
>> source like:
>>
>> <foo bar="something"/>
>>
>> Can an if be like an XSL if testing the existence of the bar attribute
>> like:
>>
>> #if (@bar)
>> do something...
>> #end
>
>
> No. There is no modification to the core Velocity for this - the idea
> was to use stock and standard velocity with a framework for VM
> invocation as you wander about the document. That's all.
>
> If you are interested in it..... thanks for volunteering! Patches welcome!
I think I am going to stick with XSL. I think I mentioned this before,
but you could use a toolbox tool to do a transformation using XSL and
return the result to velocity. Or you could do it in a servlet filter
and put it in the context.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Robert Koberg wrote:
> Geir Magnusson Jr wrote:
>
>> The velocity aspect - templating - is the same. What it's meant to do
>> is simply use the declarative model of XSL (which *is* complicated)
>> and let you use Velocity to do the rendering.
>
> Hi,
>
> I just had a look at this again after using Velocity for a year or two.
> I can see some way to use this inside a Velocity template/page very
> nicely. I believe I know XSL 1.0 pretty well. I can see how some things
> in Velocity proper can replace some things in XSL so they do not need to
> be repeated there. I have some quick questions questions off the top of
> my head:
>
> - how are namespaces handled? how do you declare them? Is XPath fully
> supported (uses Jaxen perhaps?)?
It was a while ago... we were just using what was in dom4j, and that was
jaxen, IIRC
>
> - are there modes and named templates?
That question I don't understand.
>
> - can you do something like:
>
> #if ($foo)
> #match("foo")$context.applyTemplates()#end
> #else
> #match("*")$context.applyTemplates()#end
> #end
That would be cool, and (again, it's been a while, so YMMV) I think it
should. Of course, we'd want some kind of scope, I suspect, so that
it's not global but only applied to some local context of processing, I
would guess.
>
> - can you use the XML nodes in a conditional. For example say I have a
> source like:
>
> <foo bar="something"/>
>
> Can an if be like an XSL if testing the existence of the bar attribute
> like:
>
> #if (@bar)
> do something...
> #end
No. There is no modification to the core Velocity for this - the idea
was to use stock and standard velocity with a framework for VM
invocation as you wander about the document. That's all.
If you are interested in it..... thanks for volunteering! Patches welcome!
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Robert Koberg <ro...@koberg.com>.
Geir Magnusson Jr wrote:
> The velocity aspect - templating - is the same. What it's meant to do
> is simply use the declarative model of XSL (which *is* complicated) and
> let you use Velocity to do the rendering.
Hi,
I just had a look at this again after using Velocity for a year or two.
I can see some way to use this inside a Velocity template/page very
nicely. I believe I know XSL 1.0 pretty well. I can see how some things
in Velocity proper can replace some things in XSL so they do not need to
be repeated there. I have some quick questions questions off the top of
my head:
- how are namespaces handled? how do you declare them? Is XPath fully
supported (uses Jaxen perhaps?)?
- are there modes and named templates?
- can you do something like:
#if ($foo)
#match("foo")$context.applyTemplates()#end
#else
#match("*")$context.applyTemplates()#end
#end
- can you use the XML nodes in a conditional. For example say I have a
source like:
<foo bar="something"/>
Can an if be like an XSL if testing the existence of the bar attribute like:
#if (@bar)
do something...
#end
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Ahmed Mohombe <am...@yahoo.com>.
>>>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>>>> the Maven repository; there are no tags in SVN and there's been no
>>>> release on the site. I took a quick look and he's right; it's not a
>>>> cvs2svn issue as there were no tags in CVS either.
>>>>
>>>> Is the 0.45 jar an unofficial rogue one?
>>>
>>> I wouldn't call it "rogue" :)
>>>
>>> I'm surprised that there weren't any version tags, as I am usually
>>> very good about that...
>>>
>>> Do you want to see a release?
>> Yes, please.
>> Also a few more and realistic examples would be wonderful.
>>
>> From the users guide, IMHO it seems also a little too complicated to
>> use it (well, that's just my feeling - compared to how simple is
>> Velocity in general).
>
> The velocity aspect - templating - is the same. What it's meant to do
> is simply use the declarative model of XSL (which *is* complicated) and
> let you use Velocity to do the rendering.
>
> Do you have any examples to offer? :)
No. This is why I was asking for more examples.
It would be very practical to have one (documented side by side), with and without XSL.
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Ahmed Mohombe wrote:
>>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>>> the Maven repository; there are no tags in SVN and there's been no
>>> release on the site. I took a quick look and he's right; it's not a
>>> cvs2svn issue as there were no tags in CVS either.
>>>
>>> Is the 0.45 jar an unofficial rogue one?
>>
>> I wouldn't call it "rogue" :)
>>
>> I'm surprised that there weren't any version tags, as I am usually
>> very good about that...
>>
>> Do you want to see a release?
> Yes, please.
> Also a few more and realistic examples would be wonderful.
>
> From the users guide, IMHO it seems also a little too complicated to
> use it (well, that's just my feeling - compared to how simple is
> Velocity in general).
The velocity aspect - templating - is the same. What it's meant to do
is simply use the declarative model of XSL (which *is* complicated) and
let you use Velocity to do the rendering.
Do you have any examples to offer? :)
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Ahmed Mohombe <am...@yahoo.com>.
>> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
>> the Maven repository; there are no tags in SVN and there's been no
>> release on the site. I took a quick look and he's right; it's not a
>> cvs2svn issue as there were no tags in CVS either.
>>
>> Is the 0.45 jar an unofficial rogue one?
>
> I wouldn't call it "rogue" :)
>
> I'm surprised that there weren't any version tags, as I am usually very
> good about that...
>
> Do you want to see a release?
Yes, please.
Also a few more and realistic examples would be wonderful.
From the users guide, IMHO it seems also a little too complicated to use it (well, that's just my
feeling - compared to how simple is Velocity in general).
Thanks in advance,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DVSL - ever released?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Henri Yandell wrote:
> A colleague noticed that while there's a 0.45 jar of velocity-dvsl in
> the Maven repository; there are no tags in SVN and there's been no
> release on the site. I took a quick look and he's right; it's not a
> cvs2svn issue as there were no tags in CVS either.
>
> Is the 0.45 jar an unofficial rogue one?
I wouldn't call it "rogue" :)
I'm surprised that there weren't any version tags, as I am usually very
good about that...
Do you want to see a release?
geir
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org