You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by fe...@apache.org on 2007/05/06 12:24:26 UTC
svn commit: r535593 -
/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Author: ferdinand
Date: Sun May 6 03:24:22 2007
New Revision: 535593
URL: http://svn.apache.org/viewvc?view=rev&rev=535593
Log:
Attempt to fix disappearance of processing-instructions.
Modified:
forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Modified: forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
URL: http://svn.apache.org/viewvc/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl?view=diff&rev=535593&r1=535592&r2=535593
==============================================================================
--- forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl (original)
+++ forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl Sun May 6 03:24:22 2007
@@ -20,9 +20,14 @@
<!-- Fixes FOR-555. This might not be the best solution though, but it sure works -->
<xsl:template match="comment()">
<xsl:copy>
- <xsl:apply-templates select="@*|*|text()|processing-instruction()|comment()"/>
+ <xsl:apply-templates select="@*|*|text()|comment()"/>
</xsl:copy>
</xsl:template>
+
+ <!-- If processed by rule below processing instructions disappaer -->
+ <xsl:template match="processing-instruction()">
+ <xsl:copy-of select="."/>
+ </xsl:template>
<xsl:template match="*">
<!-- remove element prefix (if any) -->
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
> Thanks for that pointer David. Cyriaque actually fixed the same bug in a
> different way. So no need to apply this to other versions.
>
> > This seems like a strange place to be handling processing
> > instructions and xml comments. The FOR-555 indicate that
> > there is a wider issue.
>
> Did look at FOR-555 and my understanding was that it was meant to remove
> namespaces that had wormed their way into the final output.
No. Removing namespaces was an earlier issue. See the comments
in main/webapp/sitemap.xmap where the transformer stylesheet
that you are editing is called from. FOR-555 was about a
change in behaviour that suddenly caused xml comments
to vanish.
-David
> Handling PIs and probably comments separatelly is necessary because of
> the way they are treated differently in xsl and can't be 'unnamespaced'
> the way it was done for elements and attributes.
>
>
> Best regards,
> Ferdinand
>
>
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by Ferdinand Soethe <fe...@apache.org>.
Thanks for that pointer David. Cyriaque actually fixed the same bug in a
different way. So no need to apply this to other versions.
> This seems like a strange place to be handling processing
> instructions and xml comments. The FOR-555 indicate that
> there is a wider issue.
Did look at FOR-555 and my understanding was that it was meant to remove
namespaces that had wormed their way into the final output.
Handling PIs and probably comments separatelly is necessary because of
the way they are treated differently in xsl and can't be 'unnamespaced'
the way it was done for elements and attributes.
Best regards,
Ferdinand
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by David Crossley <cr...@apache.org>.
Did you see Cyriaque's change to this file in trunk some time ago.
At r463293 he was adding support for PHP which i presume needs to
get processing instructions from source through to output.
It might address your issue. I gather that the same template
in 0.7 was not dealing with processing instructions.
http://article.gmane.org/gmane.text.xml.forrest.cvs/7502
This seems like a strange place to be handling processing
instructions and xml comments. The FOR-555 indicate that
there is a wider issue.
-David
> Author: ferdinand
> Date: Sun May 6 03:24:22 2007
> New Revision: 535593
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=535593
> Log:
> Attempt to fix disappearance of processing-instructions.
>
> Modified:
> forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
>
> Modified: forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
> URL: http://svn.apache.org/viewvc/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl?view=diff&rev=535593&r1=535592&r2=535593
> ==============================================================================
> --- forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl (original)
> +++ forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl Sun May 6 03:24:22 2007
> @@ -20,9 +20,14 @@
> <!-- Fixes FOR-555. This might not be the best solution though, but it sure works -->
> <xsl:template match="comment()">
> <xsl:copy>
> - <xsl:apply-templates select="@*|*|text()|processing-instruction()|comment()"/>
> + <xsl:apply-templates select="@*|*|text()|comment()"/>
> </xsl:copy>
> </xsl:template>
> +
> + <!-- If processed by rule below processing instructions disappaer -->
> + <xsl:template match="processing-instruction()">
> + <xsl:copy-of select="."/>
> + </xsl:template>
>
> <xsl:template match="*">
> <!-- remove element prefix (if any) -->
>
>
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by Ferdinand Soethe <fe...@apache.org>.
Thorsten Scherler wrote:
> I did not know that the 0.7 branch is the version where we do such
> bugfixes.
> Please, do bugfixes in trunk and not in such old branches such as 0.7.
> You are the only person that I know that is fixing stuff in an already
> released and antique version.
I corrected this bug in the current version of .7 because I have a
project that is still using .7 and needed this fix.
In addition I offered to apply this fix to .8 and trunk.
Not sure what is wrong about that.
> It is much more important to fix stuff in trunk!
Perhaps that depends on the point of view. My clients using a production
version of Forrest would certainly like to see bugs fixed in the current
version.
Best regards,
Ferdinand Soethe
Re: fixing bugs in trunk or branch
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
> Ferdinand Soethe wrote:
> >
> > I'm sorry to have stepped out of line. I hadn't found Cyriaques solution
> > when I looked for it. So I tracked down the bug on my own (in far too
> > much time) and wanted to share the work with others. That's all.
>
> I don't recall this sort of thing being discussed before - patching earlier
> releases - though David has been doing some doc updates relative to this on
> occasion.
Yes it has been discussed before. There seems to be a
slightly different aspect to it this time.
In the absence of someone reviewing the past threads
and documenting it, i have been trying to add links
to some of them here.
http://forrest.apache.org/guidelines.html#develop
It is a big downfall that we have not documented such
stuff. It causes us to continually re-visit. This
community is too small to cope with ongoing discussion.
> No apology needed as far as I can see, we need to discuss it now to be clear
> what should and shouldn't get done.
The intention is good. We need to include the past
discussion. Please let's document it this time.
> > What I don't get: Had I found Cyriaques solution and copied it in .7
> > what would have been different? It still would have required testing
> > give that .7 is a different environment that .8. It still would have
> > only been me to test it given.
> >
> > We still wouldn't be sure that it really works.
> >
> > And I may be mistaken here but I thought the version I fixed is a yet
> > unreleased update to a released version. Not?
>
> This is true, there is a doc trail missing here though, how do current users
> of 0.7 know that this patch is available, where is the patch to be provided
> as an official download for current 0.7 users, what is the process for
> releasing patches for earlier versions, do we need to vote on a patch
> release etc etc...
So many questions in one sentence.
I will try to quickly explain. Please see the archives
for more.
If someone finds a problem with an old release
which sufficiently bothers them, then they can provide
a patch for the old release. We can apply it to trunk
and to the relevant release branch of SVN. They can
checkout from svn. Alternatively they can find the
change in the svn mailing list and apply it to their
downloaded copy of that release.
Normally we don't bother to do any further releases
of such a branch. Sure if there is a big problem
like there was with the 0.5 release, then we do.
Committers can tinker with old release branches
if they want to.
Any developer can create their own private package
of a branch for their clients that cannot manage SVN.
Do 'cd main; build release-dist'.
Changes that are considered important enough
to be also added to a release branch, should be
noted in the status.xml files. However there is
a problem here. We need to also add such entries
to trunk's site-author/status.xml because that
is what creates the website changes.html doc.
If there is sufficient demand, then we can create
an actual release of a release branch, e.g. 0.8.1
However it would need to be a very good reason.
As you have seen it is a lot of effort. We would do
better to release trunk more often and encourage
people to upgrade.
Ideally we don't manage any "release branches".
See Nicola Ken's proposal linked at the abovementioned
guidelines doc via FOR-631. Unfortunately we have
not implemented that yet.
> The downside here is , you can see what extra work will be required to keep
> maintaining and patching updates for 0.7, this takes away time from the
> current 0.8 release which I guess we will maintain for a while, and also
> trunk.
We really only have the resources to focus on trunk.
> > P.S. One thing I really really disliked about commercial software was
> > the fact that you were always forced into upgrading because bugs would
> > only get fixed in new releases.
>
> I guess there will be differing opinions here, new releases come about as a
> result of two things mainly, new features and bug-fixes found in older
> versions. How far back does one go in maintaining older releases?
>
> Finally, these are 0.x versions, they are really beta/minor releases, and as
> such, open source or not we are not bound to keep users of previous versions
> happy, they know the risks. We provide an update path to 0.8.
Agreed.
> My 2 cents, leave 0.7 alone and lets concentrate on 0.9-dev, ...
I agree.
> ... if we find
> things we can apply to 0.8 then fair enough, ...
Only if there is a call for it to be applied
to an old branch.
> we need to have a patch-release
> system for current users of 0.8, not just patch 0.8 for those that have not
> already downloaded it.
I disagree, see above.
-David
Re: fixing bugs in trunk or branch
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
> I'm sorry to have stepped out of line.
Hmmm, please don't see it like that. This community
is small and we need to try to work efficiently.
At the same time, we need to enable developers like you,
who need to support older versions, a way to do it.
I reckon that many committers would be frightened
to need to maintain old versions, as well as trunk.
We have enough trouble finding a bit of time to spend
on developing things in trunk.
> I hadn't found Cyriaques solution
> when I looked for it. So I tracked down the bug on my own (in far too
> much time) and wanted to share the work with others. That's all.
Sorry that it has blown up. As usual the
discussion turned into something else.
(Although i am very glad that this caused
Nicola Ken's proposal at FOR-631 to re-surface.)
> What I don't get: Had I found Cyriaques solution and copied it in .7
> what would have been different? It still would have required testing
> give that .7 is a different environment that .8. It still would have
> only been me to test it given.
>
> We still wouldn't be sure that it really works.
I don't think that the issue was about testing,
rather about primarily fixing issues in trunk.
And the orginal query wondered what poor Ferdinand
was doing so far out in the branches. :-)
> And I may be mistaken here but I thought the version I fixed is a yet
> unreleased update to a released version. Not?
Correct.
> Best regards,
> Ferdinand
>
>
> P.S. One thing I really really disliked about commercial software was
> the fact that you were always forced into upgrading because bugs would
> only get fixed in new releases.
Yes, open source development provides a way.
However small communities have difficulty.
-David
RE: fixing bugs in trunk or branch
Posted by "Gav...." <br...@brightontown.com.au>.
> -----Original Message-----
> From: Ferdinand Soethe [mailto:ferdinand@apache.org]
> Sent: Tuesday, 8 May 2007 4:03 AM
> To: dev@forrest.apache.org
> Subject: Re: fixing bugs in trunk or branch
>
> I'm sorry to have stepped out of line. I hadn't found Cyriaques solution
> when I looked for it. So I tracked down the bug on my own (in far too
> much time) and wanted to share the work with others. That's all.
I don't recall this sort of thing being discussed before - patching earlier
releases - though David has been doing some doc updates relative to this on
occasion.
No apology needed as far as I can see, we need to discuss it now to be clear
what should and shouldn't get done.
>
> What I don't get: Had I found Cyriaques solution and copied it in .7
> what would have been different? It still would have required testing
> give that .7 is a different environment that .8. It still would have
> only been me to test it given.
>
> We still wouldn't be sure that it really works.
>
> And I may be mistaken here but I thought the version I fixed is a yet
> unreleased update to a released version. Not?
This is true, there is a doc trail missing here though, how do current users
of 0.7 know that this patch is available, where is the patch to be provided
as an official download for current 0.7 users, what is the process for
releasing patches for earlier versions, do we need to vote on a patch
release etc etc...
The downside here is , you can see what extra work will be required to keep
maintaining and patching updates for 0.7, this takes away time from the
current 0.8 release which I guess we will maintain for a while, and also
trunk.
>
> Best regards,
> Ferdinand
>
>
> P.S. One thing I really really disliked about commercial software was
> the fact that you were always forced into upgrading because bugs would
> only get fixed in new releases.
I guess there will be differing opinions here, new releases come about as a
result of two things mainly, new features and bug-fixes found in older
versions. How far back does one go in maintaining older releases?
Finally, these are 0.x versions, they are really beta/minor releases, and as
such, open source or not we are not bound to keep users of previous versions
happy, they know the risks. We provide an update path to 0.8.
My 2 cents, leave 0.7 alone and lets concentrate on 0.9-dev, if we find
things we can apply to 0.8 then fair enough, we need to have a patch-release
system for current users of 0.8, not just patch 0.8 for those that have not
already downloaded it.
Gav...
Re: fixing bugs in trunk or branch
Posted by Ferdinand Soethe <fe...@apache.org>.
I'm sorry to have stepped out of line. I hadn't found Cyriaques solution
when I looked for it. So I tracked down the bug on my own (in far too
much time) and wanted to share the work with others. That's all.
What I don't get: Had I found Cyriaques solution and copied it in .7
what would have been different? It still would have required testing
give that .7 is a different environment that .8. It still would have
only been me to test it given.
We still wouldn't be sure that it really works.
And I may be mistaken here but I thought the version I fixed is a yet
unreleased update to a released version. Not?
Best regards,
Ferdinand
P.S. One thing I really really disliked about commercial software was
the fact that you were always forced into upgrading because bugs would
only get fixed in new releases.
Re: fixing bugs in trunk or branch
Posted by Michael Wechner <mi...@wyona.com>.
David Crossley wrote:
>Michael Wechner wrote:
>
>
>>Thorsten Scherler wrote:
>>
>>
>>>Ferdinand Soethe wrote:
>>>
>>>
>>>
>>>>If nobody has any objections I'd apply this fix to .8 and head as well
>>>>next week.
>>>>
>>>>
>>>I did not know that the 0.7 branch is the version where we do such
>>>bugfixes.
>>>
>>>Please, do bugfixes in trunk and not in such old branches such as 0.7.
>>>You are the only person that I know that is fixing stuff in an already
>>>released and antique version.
>>>
>>>
>>well, I guess there are people still using 0.7 version and for those people
>>it probably makes sense, right? Or how much does it take to upgrade from
>>0.7 to trunk version?
>>
>>
>
>Not much effort. If they use their own sitemaps or private
>plugins, then there are some tweaks needed. See upgrading doc.
>
>
>
>>>It is much more important to fix stuff in trunk!
>>>
>>>
>>is the same patch applicable on trunk? It seems to me that Ferdinand wants
>>to apply the same fix to trunk as well as he wrote above or do I
>>misunderstand something?
>>
>>
>
>I reckon that it is the wrong way around. We should fix
>such bugs in trunk, and then apply the proven and reviewed fix
>to the branch that needed it. Hopefully only the immediate
>past release, but wherever the committer or patch contributor
>needs it.
>
>Doing it in the branch first is dangerous. People would
>be likely to be using it directly in production.
>
>I for one am not keen to fire up a copy of 0.7 just to
>review a fix. I already have a 0.9-dev seed running
>here so it is easier.
>
>We have the forrestbot running every hour on our zone
>server to do continuous testing via the seed-sample.
>It only keeps trunk up-to-date, so does not test any branches.
>
>
I understand, but I think it's also important to understand the other side.
If one uses an old version and doesn't have the resources (time, money,
knowledge, functionality, ...) to upgrade to a newer version
(in the case of Forrest this might be simple, but there is other
software which takes a lot of resources to upgrade
if you customized it and also be aware "simple" is always relative),
then it makes a lot of sense to fix this older version.
I think it's important that devs are understanding this.
Again just my 2 cents
Michi
>-David
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
fixing bugs in trunk or branch
Posted by David Crossley <cr...@apache.org>.
Michael Wechner wrote:
> Thorsten Scherler wrote:
> >Ferdinand Soethe wrote:
> >
> >>If nobody has any objections I'd apply this fix to .8 and head as well
> >>next week.
> >
> >I did not know that the 0.7 branch is the version where we do such
> >bugfixes.
> >
> >Please, do bugfixes in trunk and not in such old branches such as 0.7.
> >You are the only person that I know that is fixing stuff in an already
> >released and antique version.
>
> well, I guess there are people still using 0.7 version and for those people
> it probably makes sense, right? Or how much does it take to upgrade from
> 0.7 to trunk version?
Not much effort. If they use their own sitemaps or private
plugins, then there are some tweaks needed. See upgrading doc.
> >It is much more important to fix stuff in trunk!
>
> is the same patch applicable on trunk? It seems to me that Ferdinand wants
> to apply the same fix to trunk as well as he wrote above or do I
> misunderstand something?
I reckon that it is the wrong way around. We should fix
such bugs in trunk, and then apply the proven and reviewed fix
to the branch that needed it. Hopefully only the immediate
past release, but wherever the committer or patch contributor
needs it.
Doing it in the branch first is dangerous. People would
be likely to be using it directly in production.
I for one am not keen to fire up a copy of 0.7 just to
review a fix. I already have a 0.9-dev seed running
here so it is easier.
We have the forrestbot running every hour on our zone
server to do continuous testing via the seed-sample.
It only keeps trunk up-to-date, so does not test any branches.
-David
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by Michael Wechner <mi...@wyona.com>.
Thorsten Scherler wrote:
>On Sun, 2007-05-06 at 12:28 +0200, Ferdinand Soethe wrote:
>
>
>>If nobody has any objections I'd apply this fix to .8 and head as well
>>next week.
>>
>>
>
>I did not know that the 0.7 branch is the version where we do such
>bugfixes.
>
>Please, do bugfixes in trunk and not in such old branches such as 0.7.
>You are the only person that I know that is fixing stuff in an already
>released and antique version.
>
>
well, I guess there are people still using 0.7 version and for those people
it probably makes sense, right? Or how much does it take to upgrade from
0.7 to trunk version?
>It is much more important to fix stuff in trunk!
>
>
is the same patch applicable on trunk? It seems to me that Ferdinand wants
to apply the same fix to trunk as well as he wrote above or do I
misunderstand something?
Just my 2 cents
Michael
>
>wdot?
>
>salu2
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
Re: svn commit: r535593 -
/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2007-05-06 at 12:28 +0200, Ferdinand Soethe wrote:
> If nobody has any objections I'd apply this fix to .8 and head as well
> next week.
I did not know that the 0.7 branch is the version where we do such
bugfixes.
Please, do bugfixes in trunk and not in such old branches such as 0.7.
You are the only person that I know that is fixing stuff in an already
released and antique version.
It is much more important to fix stuff in trunk!
wdot?
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Posted by Ferdinand Soethe <fe...@apache.org>.
If nobody has any objections I'd apply this fix to .8 and head as well
next week.
Best regards,
Ferdinand Soethe
ferdinand@apache.org wrote:
> Author: ferdinand
> Date: Sun May 6 03:24:22 2007
> New Revision: 535593
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=535593
> Log:
> Attempt to fix disappearance of processing-instructions.
>
> Modified:
> forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
>
> Modified: forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
> URL: http://svn.apache.org/viewvc/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl?view=diff&rev=535593&r1=535592&r2=535593
> ==============================================================================
> --- forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl (original)
> +++ forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl Sun May 6 03:24:22 2007
> @@ -20,9 +20,14 @@
> <!-- Fixes FOR-555. This might not be the best solution though, but it sure works -->
> <xsl:template match="comment()">
> <xsl:copy>
> - <xsl:apply-templates select="@*|*|text()|processing-instruction()|comment()"/>
> + <xsl:apply-templates select="@*|*|text()|comment()"/>
> </xsl:copy>
> </xsl:template>
> +
> + <!-- If processed by rule below processing instructions disappaer -->
> + <xsl:template match="processing-instruction()">
> + <xsl:copy-of select="."/>
> + </xsl:template>
>
> <xsl:template match="*">
> <!-- remove element prefix (if any) -->
>
>
>
>