You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by ch...@apache.org on 2003/09/10 22:21:45 UTC
cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
cheche 2003/09/10 13:21:45
Modified: src/resources/conf forrest.xmap sitemap.xmap
src/resources/fresh-site/src/documentation/content/xdocs
site.xml
Added: legal LICENSE.jdtcore
lib/core jdtcore-2.1.0.jar
src/resources/fresh-site/src/documentation/content/xdocs/samples
xsp-sample.xsp
src/resources/stylesheets page2document.xsl
Log:
Added support for xsp
PR: FOR-56
Revision Changes Path
1.1 xml-forrest/legal/LICENSE.jdtcore
Index: LICENSE.jdtcore
===================================================================
Eclipse.org Software User Agreement
17th June, 2002
ECLIPSE.ORG MAKES AVAILABLE SOFTWARE, DOCUMENTATION, INFORMATION AND/OR
OTHER MATERIALS FOR OPEN SOURCE PROJECTS (COLLECTIVELY "CONTENT"). USE OF
THE CONTENT IS GOVERNED BY THE TERMS AND CONDITIONS OF THIS AGREEMENT
AND/OR THE TERMS AND CONDITIONS OF LICENSE AGREEMENTS OR NOTICES INDICATED
OR REFERENCED BELOW. BY USING THE CONTENT, YOU AGREE THAT YOUR USE OF THE
CONTENT IS GOVERNED BY THIS AGREEMENT AND/OR THE TERMS AND CONDITIONS OF
ANY APPLICABLE LICENSE AGREEMENTS OR NOTICES INDICATED OR REFERENCED BELOW.
IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT AND THE
TERMS AND CONDITIONS OF ANY APPLICABLE LICENSE AGREEMENTS OR NOTICES
INDICATED OR REFERENCED BELOW, THEN YOU MAY NOT USE THE CONTENT.
Unless otherwise indicated, all Content made available by Eclipse.org is
provided to you under the terms and conditions of the Common Public License
Version 1.0 ("CPL"). A copy of the CPL is provided with this Content and is
also available at http://www.eclipse.org/legal/cpl-v10.html. For purposes
of the CPL, "Program" will mean the Content.
Content includes, but is not limited to, source code, object code,
documentation and other files maintained in the Eclipse.org CVS repository
("Repository") in CVS modules ("Modules") and made available as
downloadable archives ("Downloads").
Content may be apportioned into plug-ins ("Plug-ins"), plug-in fragments
("Fragments"), and features ("Features"). A Feature is a bundle of one or
more Plug-ins and/or Fragments and associated material. Files named
"feature.xml" may contain a list of the names and version numbers of the
Plug-ins and/or Fragments associated with a Feature. Plug-ins and Fragments
are located in directories named "plugins" and Features are located in
directories named "features".
Features may also include other Features ("Included Features"). Files named
"feature.xml" may contain a list of the names and version numbers of
Included Features.
The terms and conditions governing Plug-ins and Fragments should be
contained in files named "about.html" ("Abouts"). The terms and conditions
governing Features and Included Features should be contained in files named
"license.html" ("Feature Licenses"). Abouts and Feature Licenses may be
located in any directory of a Download or Module including, but not limited
to the following locations:
* The top-level (root) directory
* Plug-in and Fragment directories
* Subdirectories of the directory named "src" of certain Plug-ins
* Feature directories
Note: if a Feature made available by Eclipse.org is installed using the
Eclipse Update Manager, you must agree to a license ("Feature Update
License") during the installation process. If the Feature contains Included
Features, the Feature Update License should either provide you with the
terms and conditions governing the Included Features or inform you where
you can locate them. Feature Update Licenses may be found in the "license"
property of files named "feature.properties". Such Abouts, Feature Licenses
and Feature Update Licenses contain the terms and conditions (or references
to such terms and conditions) that govern your use of the associated
Content in that directory. The Abouts, Feature Licenses and Feature Update
Licenses may refer to the CPL or other license agreements, notices or terms
and conditions . It is your obligation to read and accept all such all
terms and conditions prior to use of the Content. If no About, Feature
License or Feature Update License is provided, please contact Eclipse.org
to determine what terms and conditions govern that particular Content.
Content may contain encryption software. The country in which you are
currently may have restrictions on the import, possession, and use, and/or
re-export to another country, of encryption software. BEFORE using any
encryption software, please check the country's laws, regulations and
policies concerning the import, possession, or use, and re-export of
encryption software, to see if this is permitted.
Common Public License - v 1.0
THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
1. DEFINITIONS
"Contribution" means:
a) in the case of the initial Contributor, the initial code and
documentation distributed under this Agreement, and
b) in the case of each subsequent Contributor:
i) changes to the Program, and
ii) additions to the Program;
where such changes and/or additions to the Program originate from and
are distributed by that particular Contributor. A Contribution
'originates' from a Contributor if it was added to the Program by such
Contributor itself or anyone acting on such Contributor's behalf.
Contributions do not include additions to the Program which: (i) are
separate modules of software distributed in conjunction with the
Program under their own license agreement, and (ii) are not derivative
works of the Program.
"Contributor" means any person or entity that distributes the Program.
"Licensed Patents " mean patent claims licensable by a Contributor which
are necessarily infringed by the use or sale of its Contribution alone or
when combined with the Program.
"Program" means the Contributions distributed in accordance with this
Agreement.
"Recipient" means anyone who receives the Program under this Agreement,
including all Contributors.
2. GRANT OF RIGHTS
a) Subject to the terms of this Agreement, each Contributor hereby
grants Recipient a non-exclusive, worldwide, royalty-free copyright
license to reproduce, prepare derivative works of, publicly display,
publicly perform, distribute and sublicense the Contribution of such
Contributor, if any, and such derivative works, in source code and
object code form.
b) Subject to the terms of this Agreement, each Contributor hereby
grants Recipient a non-exclusive, worldwide, royalty-free patent
license under Licensed Patents to make, use, sell, offer to sell,
import and otherwise transfer the Contribution of such Contributor, if
any, in source code and object code form. This patent license shall
apply to the combination of the Contribution and the Program if, at
the time the Contribution is added by the Contributor, such addition
of the Contribution causes such combination to be covered by the
Licensed Patents. The patent license shall not apply to any other
combinations which include the Contribution. No hardware per se is
licensed hereunder.
c) Recipient understands that although each Contributor grants the
licenses to its Contributions set forth herein, no assurances are
provided by any Contributor that the Program does not infringe the
patent or other intellectual property rights of any other entity. Each
Contributor disclaims any liability to Recipient for claims brought by
any other entity based on infringement of intellectual property rights
or otherwise. As a condition to exercising the rights and licenses
granted hereunder, each Recipient hereby assumes sole responsibility
to secure any other intellectual property rights needed, if any. For
example, if a third party patent license is required to allow
Recipient to distribute the Program, it is Recipient's responsibility
to acquire that license before distributing the Program.
d) Each Contributor represents that to its knowledge it has sufficient
copyright rights in its Contribution, if any, to grant the copyright
license set forth in this Agreement.
3. REQUIREMENTS
A Contributor may choose to distribute the Program in object code form
under its own license agreement, provided that:
a) it complies with the terms and conditions of this Agreement; and
b) its license agreement:
i) effectively disclaims on behalf of all Contributors all warranties
and conditions, express and implied, including warranties or
conditions of title and non-infringement, and implied warranties or
conditions of merchantability and fitness for a particular purpose;
ii) effectively excludes on behalf of all Contributors all liability
for damages, including direct, indirect, special, incidental and
consequential damages, such as lost profits;
iii) states that any provisions which differ from this Agreement are
offered by that Contributor alone and not by any other party; and
iv) states that source code for the Program is available from such
Contributor, and informs licensees how to obtain it in a reasonable
manner on or through a medium customarily used for software exchange.
When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy of the
Program.
Contributors may not remove or alter any copyright notices contained within
the Program.
Each Contributor must identify itself as the originator of its
Contribution, if any, in a manner that reasonably allows subsequent
Recipients to identify the originator of the Contribution.
4. COMMERCIAL DISTRIBUTION
Commercial distributors of software may accept certain responsibilities
with respect to end users, business partners and the like. While this
license is intended to facilitate the commercial use of the Program, the
Contributor who includes the Program in a commercial product offering
should do so in a manner which does not create potential liability for
other Contributors. Therefore, if a Contributor includes the Program in a
commercial product offering, such Contributor ("Commercial Contributor")
hereby agrees to defend and indemnify every other Contributor ("Indemnified
Contributor") against any losses, damages and costs (collectively "Losses")
arising from claims, lawsuits and other legal actions brought by a third
party against the Indemnified Contributor to the extent caused by the acts
or omissions of such Commercial Contributor in connection with its
distribution of the Program in a commercial product offering. The
obligations in this section do not apply to any claims or Losses relating
to any actual or alleged intellectual property infringement. In order to
qualify, an Indemnified Contributor must: a) promptly notify the Commercial
Contributor in writing of such claim, and b) allow the Commercial
Contributor to control, and cooperate with the Commercial Contributor in,
the defense and any related settlement negotiations. The Indemnified
Contributor may participate in any such claim at its own expense.
For example, a Contributor might include the Program in a commercial
product offering, Product X. That Contributor is then a Commercial
Contributor. If that Commercial Contributor then makes performance claims,
or offers warranties related to Product X, those performance claims and
warranties are such Commercial Contributor's responsibility alone. Under
this section, the Commercial Contributor would have to defend claims
against the other Contributors related to those performance claims and
warranties, and if a court requires any other Contributor to pay any
damages as a result, the Commercial Contributor must pay those damages.
5. NO WARRANTY
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON
AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR
CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Each Recipient is solely responsible for determining
the appropriateness of using and distributing the Program and assumes all
risks associated with its exercise of rights under this Agreement,
including but not limited to the risks and costs of program errors,
compliance with applicable laws, damage to or loss of data, programs or
equipment, and unavailability or interruption of operations.
6. DISCLAIMER OF LIABILITY
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY
CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION
LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE
EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
7. GENERAL
If any provision of this Agreement is invalid or unenforceable under
applicable law, it shall not affect the validity or enforceability of the
remainder of the terms of this Agreement, and without further action by the
parties hereto, such provision shall be reformed to the minimum extent
necessary to make such provision valid and enforceable.
If Recipient institutes patent litigation against a Contributor with
respect to a patent applicable to software (including a cross-claim or
counterclaim in a lawsuit), then any patent licenses granted by that
Contributor to such Recipient under this Agreement shall terminate as of
the date such litigation is filed. In addition, if Recipient institutes
patent litigation against any entity (including a cross-claim or
counterclaim in a lawsuit) alleging that the Program itself (excluding
combinations of the Program with other software or hardware) infringes such
Recipient's patent(s), then such Recipient's rights granted under Section
2(b) shall terminate as of the date such litigation is filed.
All Recipient's rights under this Agreement shall terminate if it fails to
comply with any of the material terms or conditions of this Agreement and
does not cure such failure in a reasonable period of time after becoming
aware of such noncompliance. If all Recipient's rights under this Agreement
terminate, Recipient agrees to cease use and distribution of the Program as
soon as reasonably practicable. However, Recipient's obligations under this
Agreement and any licenses granted by Recipient relating to the Program
shall continue and survive.
Everyone is permitted to copy and distribute copies of this Agreement, but
in order to avoid inconsistency the Agreement is copyrighted and may only
be modified in the following manner. The Agreement Steward reserves the
right to publish new versions (including revisions) of this Agreement from
time to time. No one other than the Agreement Steward has the right to
modify this Agreement. IBM is the initial Agreement Steward. IBM may assign
the responsibility to serve as the Agreement Steward to a suitable separate
entity. Each new version of the Agreement will be given a distinguishing
version number. The Program (including Contributions) may always be
distributed subject to the version of the Agreement under which it was
received. In addition, after a new version of the Agreement is published,
Contributor may elect to distribute the Program (including its
Contributions) under the new version. Except as expressly stated in
Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to
the intellectual property of any Contributor under this Agreement, whether
expressly, by implication, estoppel or otherwise. All rights in the Program
not expressly granted under this Agreement are reserved.
This Agreement is governed by the laws of the State of New York and the
intellectual property laws of the United States of America. No party to
this Agreement will bring a legal action under this Agreement more than one
year after the cause of action arose. Each party waives its rights to a
jury trial in any resulting litigation.
1.1 xml-forrest/lib/core/jdtcore-2.1.0.jar
<<Binary file>>
1.31 +9 -2 xml-forrest/src/resources/conf/forrest.xmap
Index: forrest.xmap
===================================================================
RCS file: /home/cvs/xml-forrest/src/resources/conf/forrest.xmap,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- forrest.xmap 9 Sep 2003 20:35:20 -0000 1.30
+++ forrest.xmap 10 Sep 2003 20:21:45 -0000 1.31
@@ -215,7 +215,14 @@
<map:serialize type="xml-document"/>
</map:match>
</map:when>
-
+
+ <map:when test="content/xdocs/{1}.xsp">
+ <map:match type="regexp" pattern="^(.*?)([^/]*).xml$">
+ <map:generate type="serverpages" src="content/xdocs/{1}{2}.xsp" />
+ <map:transform src="resources/stylesheets/page2document.xsl" />
+ <map:serialize type="xml-document"/>
+ </map:match>
+ </map:when>
<map:otherwise>
<map:generate src="content/xdocs/{1}.xml" />
<map:call resource="transform-to-document">
1.118 +2 -1 xml-forrest/src/resources/conf/sitemap.xmap
Index: sitemap.xmap
===================================================================
RCS file: /home/cvs/xml-forrest/src/resources/conf/sitemap.xmap,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -r1.117 -r1.118
--- sitemap.xmap 7 Sep 2003 05:08:43 -0000 1.117
+++ sitemap.xmap 10 Sep 2003 20:21:45 -0000 1.118
@@ -12,6 +12,7 @@
<map:components>
<map:generators default="file">
<map:generator name="file" src="org.apache.cocoon.generation.FileGenerator" />
+ <map:generator name="serverpages" src="org.apache.cocoon.generation.ServerPagesGenerator"/>
<!--
<map:generator name="html" src="org.apache.cocoon.generation.HTMLGenerator">
<jtidy-config>jtidy.properties</jtidy-config>
1.21 +1 -0 xml-forrest/src/resources/fresh-site/src/documentation/content/xdocs/site.xml
Index: site.xml
===================================================================
RCS file: /home/cvs/xml-forrest/src/resources/fresh-site/src/documentation/content/xdocs/site.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- site.xml 9 Sep 2003 20:41:48 -0000 1.20
+++ site.xml 10 Sep 2003 20:21:45 -0000 1.21
@@ -39,6 +39,7 @@
<faq label="FAQ" href="faq.html" description="Frequently Asked Questions" />
<sdocbook label="Simplifed Docbook page" href="sdocbook.html"
description="Simplified DocBook title" />
+ <xsp label="XSP page" href="xsp-sample.html" description="XSP title" />
<subdir label="Subdir" href="subdir/">
<index label="Index" href="index.html"
description="Page generated from a subdirectory"/>
1.1 xml-forrest/src/resources/fresh-site/src/documentation/content/xdocs/samples/xsp-sample.xsp
Index: xsp-sample.xsp
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!-- CVS $Id: xsp-sample.xsp,v 1.1 2003/09/10 20:21:45 cheche Exp $ -->
<xsp:page language="java"
xmlns:xsp="http://apache.org/xsp">
<page>
<title>Hello</title>
<content>
<para>This is my first Cocoon page within Forrest!</para>
<xsp:element name="para">
With the help of XSP and
<xsp:expr>Constants.COMPLETE_NAME</xsp:expr>
</xsp:element>
</content>
</page>
</xsp:page>
1.1 xml-forrest/src/resources/stylesheets/page2document.xsl
Index: page2document.xsl
===================================================================
<?xml version="1.0"?>
<!--+
| Transforms ServerPages Generator output to document format.
|
| CVS $Id: page2document.xsl,v 1.1 2003/09/10 20:21:45 cheche Exp $
+-->
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href="copyover.xsl"/>
<xsl:template match="page">
<document>
<xsl:apply-templates />
</document>
</xsl:template>
<xsl:template match="title">
<header>
<title><xsl:value-of select="." /></title>
</header>
</xsl:template>
<xsl:template match="content">
<body>
<xsl:apply-templates />
</body>
</xsl:template>
<xsl:template match="para">
<p>
<xsl:apply-templates />
</p>
</xsl:template>
</xsl:stylesheet>
Re: XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets
page2document.xsl)
Posted by Juan Jose Pablos <ch...@che-che.com>.
David Crossley wrote:
> Juan Jose Pablos wrote:
>
>>David Crossley wrote:
>>
>>>+1 to SVG as it currently is. I do not want to have Forrest CVS
>>>get top-heavy with other add-ins. The wiki document
>>>http://wiki.cocoondev.org/Wiki.jsp?page=AddingXSPToForrest
>>>describes how to do it. Yes let us wait for "real blocks" to get
>>>automated plugins.
>>
>>That document is obsolete you do not need to do all these steps to get
>>xsp support within forrest.
>
>
> Oh sorry, well then could someone who knows about it add a warning
> to it please.
>
> --David
Done it. I am not surre if that is enough.
Cheers,
cheche
Re: XSP vs SVG (Re: cvs
commit: xml-forrest/src/resources/stylesheets page2document.xsl)
Posted by David Crossley <cr...@indexgeo.com.au>.
Juan Jose Pablos wrote:
> David Crossley wrote:
> >
> > +1 to SVG as it currently is. I do not want to have Forrest CVS
> > get top-heavy with other add-ins. The wiki document
> > http://wiki.cocoondev.org/Wiki.jsp?page=AddingXSPToForrest
> > describes how to do it. Yes let us wait for "real blocks" to get
> > automated plugins.
>
> That document is obsolete you do not need to do all these steps to get
> xsp support within forrest.
Oh sorry, well then could someone who knows about it add a warning
to it please.
--David
Re: XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets
page2document.xsl)
Posted by Juan Jose Pablos <ch...@che-che.com>.
David Crossley wrote:
>
> +1 to SVG as it currently is. I do not want to have Forrest CVS
> get top-heavy with other add-ins. The wiki document
> http://wiki.cocoondev.org/Wiki.jsp?page=AddingXSPToForrest
> describes how to do it. Yes let us wait for "real blocks" to get
> automated plugins.
That document is obsolete you do not need to do all these steps to get
xsp support within forrest.
Re: XSP vs SVG (Re: cvs commit:
xml-forrest/src/resources/stylesheets page2document.xsl)
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> Juan Jose Pablos wrote:
> ...
> > The issue here is that we have two identical technologies one is added
> > by default and the other is not.
>
> The issue here is that you two are not communicating ;-P
>
> You are at a point where you both keep saying the same things over and
> over and understand what the other says but still have the same opinion.
>
> Let's try and get over this a bit faster, maybe a VOTE?
>
> Well, my vote goes to keeping SVG as default and adding xsp as an extra
> download, or in alternative have both in CVS. I'll wait for real blocks
> support to have a real autodownload of functionality.
Nicely said, Nicola Ken. I was trying to come up with some words to
break the impasse, but you have said it well.
The SVG stuff has been in Forrest since early days, so it is not fair
to compare its situation with the new request to add XSP support.
+1 to SVG as it currently is. I do not want to have Forrest CVS
get top-heavy with other add-ins. The wiki document
http://wiki.cocoondev.org/Wiki.jsp?page=AddingXSPToForrest
describes how to do it. Yes let us wait for "real blocks" to get
automated plugins.
--David
Re: XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets
page2document.xsl)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
...
> The issue here is that we have two identical technologies one is added
> by default and the other is not.
The issue here is that you two are not communicating ;-P
You are at a point where you both keep saying the same things over and
over and understand what the other says but still have the same opinion.
Let's try and get over this a bit faster, maybe a VOTE?
Well, my vote goes to keeping SVG as default and adding xsp as an extra
download, or in alternative have both in CVS. I'll wait for real blocks
support to have a real autodownload of functionality.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets
page2document.xsl)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
>><target name="seed" depends="get-svg, get-xsp, ...">
>
>
> 'cvs rm -f xsp-sample.xsp' will instantly solve that problem with no loss
> of functionality.
>
cvs add group.png project.png will allow nice images to be displayed
with an increase of performance :-)
>
> Give up! ;) We're not going to remove SVG from fresh-site because
> generating a logo from skinconf.xml is cool and maybe even useful.
I have not enough e-paper to write down all the cool features and useful
things that XSP provides.
>
> Besides which, we couldn't remove built-in SVG support because it would
> break backwards-compat with all sites expecting it. The issue is XSP
> support.
>
>
For those sites that expecting SVG support, there is a lovely ant task
waiting for them:
if ${project.home}/src/documentation/resources/images/*.svg
then
target="get-svg"
<-- This point has not got enought ground but I thought about it
We have not release yet ( unless you do it only for the sake of wining
an argument) so there is not need to keep backwards compatibility.
-->
The issue here is that we have two identical technologies one is added
by default and the other is not.
Cheers,
Cheche
Re: XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl)
Posted by Jeff Turner <je...@apache.org>.
On Fri, Sep 12, 2003 at 01:04:50AM +0200, Juan Jose Pablos wrote:
> Jeff Turner wrote:
> >
> >Okay, so we _could_ add a task:
> >
> ><target name="get-svg">
> > <get ... />
> ></target>
> >
>
> Hey!, we are getting closer! :-)
>
> >And then because the seed target uses SVG, we'd need to make a
> >dependency:
> >
> ><target name="seed" depends="get-svg, ...">
> >
>
> Same as xsp, there is a xsp-sample.xsp so it has to be:
>
> <target name="seed" depends="get-svg, get-xsp, ...">
'cvs rm -f xsp-sample.xsp' will instantly solve that problem with no loss
of functionality.
> >Of course the same offline/proxy issues affect a get-xsp target, but
> >given the number of Forrest users wanting XSP, this is a tiny cost
> >compared to that of increasing the Forrest download by 2.4Mb for
> >everyone.
> >
> >--Jeff
>
> Unless xsp or svg are not added by default in the seed example, then
> there is not dependency.
Give up! ;) We're not going to remove SVG from fresh-site because
generating a logo from skinconf.xml is cool and maybe even useful.
Besides which, we couldn't remove built-in SVG support because it would
break backwards-compat with all sites expecting it. The issue is XSP
support.
--Jeff
> These examples can be added when users run get-svg or get-xsp doing this
> we decrease 4.4Mb download for everyone.
>
>
> Cheers,
> Cheche
>
Re: XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets
page2document.xsl)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
>
> Okay, so we _could_ add a task:
>
> <target name="get-svg">
> <get ... />
> </target>
>
Hey!, we are getting closer! :-)
> And then because the seed target uses SVG, we'd need to make a
> dependency:
>
> <target name="seed" depends="get-svg, ...">
>
Same as xsp, there is a xsp-sample.xsp so it has to be:
<target name="seed" depends="get-svg, get-xsp, ...">
> Of course the same offline/proxy issues affect a get-xsp target, but
> given the number of Forrest users wanting XSP, this is a tiny cost
> compared to that of increasing the Forrest download by 2.4Mb for
> everyone.
>
> --Jeff
Unless xsp or svg are not added by default in the seed example, then
there is not dependency.
These examples can be added when users run get-svg or get-xsp doing this
we decrease 4.4Mb download for everyone.
Cheers,
Cheche
XSP vs SVG (Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 11, 2003 at 04:04:51PM +0200, Juan Jose Pablos wrote:
> We are comparing two cases SVG and XSP, if you feel that we need to run
> an Ant task then let's do it. But for both technologies as they are
> equivalent cases:
>
> SVG support
> ===========
> batik-1.5b4-fop.jar 2068 Kb
> works with static content.
> Low usage
>
> XSP support
> ===========
> jdtcore-2.1.0.jar 2408 Kb
> works with static content.
> Requested by users.
>
>
> So same reasons you apply for a "get-xsp" ant task I applied for
> "get-svg" ant task.
Okay, so we _could_ add a task:
<target name="get-svg">
<get ... />
</target>
And then because the seed target uses SVG, we'd need to make a
dependency:
<target name="seed" depends="get-svg, ...">
And since 'forrest seed' is the first thing we recommend that new users
do, almost everyone will end up running get-svg, and a significant
proportion will be unable to use Forrest because they are offline or have
proxy problems. Great.
Of course the same offline/proxy issues affect a get-xsp target, but
given the number of Forrest users wanting XSP, this is a tiny cost
compared to that of increasing the Forrest download by 2.4Mb for
everyone.
--Jeff
> Cheers,
> cheche
>
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
>>
>>There is not mention on the archives of such a request.
>
>
> Jason Lane was trying to use XMLForm.
>
But that is not a request.
>>So, for someone like me that does not use svg. should be have a
>>./build.sh get-svg as well?
>
>
> You've used SVG before, because you've built the seed site before. And
> you're avoiding the question ;P
>
funny, you forgot as well to reply to my question.
No, I am not using SVG on my sites, for the skins I created I used png
files.
The fresh-site example for forrest use it, I fixed a couple of issues,
but I am not using that technology somewhere else.
>>I do not know if it is a real world example but I am looking to access a
>>database for specifict data and get a PDF with that.
>
>
> Depends on whether you want to website to reflect what's currently in the
> database. It's a fair use-case for XSP, but also irrelevant to the
> question of why XSP users can't run an Ant task.
>
We are comparing two cases SVG and XSP, if you feel that we need to run
an Ant task then let's do it. But for both technologies as they are
equivalent cases:
SVG support
===========
batik-1.5b4-fop.jar 2068 Kb
works with static content.
Low usage
XSP support
===========
jdtcore-2.1.0.jar 2408 Kb
works with static content.
Requested by users.
So same reasons you apply for a "get-xsp" ant task I applied for
"get-svg" ant task.
I am not against SVG, I think that we need it, but all your reasons can
be applied to SVG, and SVG is distributed by default, so why XSP can not?
Cheers,
cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 11, 2003 at 01:08:39PM +0200, Juan Jose Pablos wrote:
> Jeff Turner wrote:
> >On Thu, Sep 11, 2003 at 11:57:10AM +0200, Juan Jose Pablos wrote:
> >>I added XSP because it was requested not because of its size.
> >
> >
> >XForms was also requested, but (I hope) we're not going to include that.
>
> There is not mention on the archives of such a request.
Jason Lane was trying to use XMLForm.
> >Why can't the handful of users wanting XSP just run './build.sh get-xsp'
> >and save everyone else the download?
> >
>
> So, for someone like me that does not use svg. should be have a
> ./build.sh get-svg as well?
You've used SVG before, because you've built the seed site before. And
you're avoiding the question ;P
> >>Are you saying that XSP is not useful for static sites?.
> >
> >
> >I haven't seen any real-world use-cases for wanting XSP-generated static
> >HTML in Forrest.
>
>
> I do not know if it is a real world example but I am looking to access a
> database for specifict data and get a PDF with that.
Depends on whether you want to website to reflect what's currently in the
database. It's a fair use-case for XSP, but also irrelevant to the
question of why XSP users can't run an Ant task.
--Jeff
> Cheers,
> Cheche
>
>
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
> On Thu, Sep 11, 2003 at 11:57:10AM +0200, Juan Jose Pablos wrote:
>>I added XSP because it was requested not because of its size.
>
>
> XForms was also requested, but (I hope) we're not going to include that.
There is not mention on the archives of such a request.
> Why can't the handful of users wanting XSP just run './build.sh get-xsp'
> and save everyone else the download?
>
So, for someone like me that does not use svg. should be have a
./build.sh get-svg as well?
>>Are you saying that XSP is not useful for static sites?.
>
>
> I haven't seen any real-world use-cases for wanting XSP-generated static
> HTML in Forrest.
I do not know if it is a real world example but I am looking to access a
database for specifict data and get a PDF with that.
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 11, 2003 at 11:57:10AM +0200, Juan Jose Pablos wrote:
> Jeff Turner wrote:
> >Most things in Cocoon are under 2Mb, but that is no reason to go adding
> >them to Forrest. Unlike XSP, SVG is useful for all sites, not just
> >dynamic ones, and is used in our seed webapp.
> >
>
> I added XSP because it was requested not because of its size.
XForms was also requested, but (I hope) we're not going to include that.
Why can't the handful of users wanting XSP just run './build.sh get-xsp'
and save everyone else the download?
> I have not added the midi block because is small, have I?
Well if <bgsound> hadn't traumatised a generation of web users, perhaps
we could include it ;) It works in a static site and has no external
dependencies.
> Are you saying that XSP is not useful for static sites?.
I haven't seen any real-world use-cases for wanting XSP-generated static
HTML in Forrest.
--Jeff
> There is a "static" example already that we use in our seed webapp
> (fresh-site).
>
> Cheers,
> Cheche
>
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
> Most things in Cocoon are under 2Mb, but that is no reason to go adding
> them to Forrest. Unlike XSP, SVG is useful for all sites, not just
> dynamic ones, and is used in our seed webapp.
>
I added XSP because it was requested not because of its size. I have
not added the midi block because is small, have I?
Are you saying that XSP is not useful for static sites?.
There is a "static" example already that we use in our seed webapp
(fresh-site).
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 11, 2003 at 02:16:32AM +0200, Juan Jose Pablos wrote:
> Jeff Turner wrote:
> >
> >Couldn't we rather have an Ant task that fetches jdtcore.jar? 95% of
> >Forrest users don't need XSP, so adding 2.3mb to the download is a high
> >price to pay.
> >
> >--Jeff
>
>
> I agreee that we should try to reduce the download.
>
> I have to admit that I looked it before I commit jdtcore, I added to our
> cvs because I saw another library around same size.
>
> Batik library is around 2Mb as well, so we have exactly the same issue.
> So do not you think that there is a hih price to pay for converting svg
> to jpg and png already?.
Most things in Cocoon are under 2Mb, but that is no reason to go adding
them to Forrest. Unlike XSP, SVG is useful for all sites, not just
dynamic ones, and is used in our seed webapp.
--Jeff
> Anyway I am open to other options.
>
> Cheers,
> Cheche
>
>
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
>
> Couldn't we rather have an Ant task that fetches jdtcore.jar? 95% of
> Forrest users don't need XSP, so adding 2.3mb to the download is a high
> price to pay.
>
> --Jeff
I agreee that we should try to reduce the download.
I have to admit that I looked it before I commit jdtcore, I added to our
cvs because I saw another library around same size.
Batik library is around 2Mb as well, so we have exactly the same issue.
So do not you think that there is a hih price to pay for converting svg
to jpg and png already?.
Anyway I am open to other options.
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeff Turner wrote:
> On Wed, Sep 10, 2003 at 08:21:45PM -0000, cheche@apache.org wrote:
>
>>cheche 2003/09/10 13:21:45
>>
>> Modified: src/resources/conf forrest.xmap sitemap.xmap
>> src/resources/fresh-site/src/documentation/content/xdocs
>> site.xml
>> Added: legal LICENSE.jdtcore
>> lib/core jdtcore-2.1.0.jar
>
>
> Couldn't we rather have an Ant task that fetches jdtcore.jar? 95% of
> Forrest users don't need XSP, so adding 2.3mb to the download is a high
> price to pay.
Have you considered pizza yet? It's waaaay smaller, and has just couple
of known issues (it is file based; and some other issue). Should be more
than enough for light jsp usage.
Vadim
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
...
> What I am a suggesting would be to use maven to build
> forrest. I haven't used maven too much either, so I don't know how much work
> this would be or if we would even want to do it.
We use Ant to run Forrest itself, so Maven doesn't make much sense anyway.
If we want to use a central repository there is Krysalis Ruper, or
simply an Ant <get>.
[My comments are baised, as I am the initial author of Krysalis
Centipede www.krysalis.org/centipede ;-)]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave Brondsema wrote:
> Have you considered using maven for builds? It will download all the
> latest
> > dependency jars from a central repository. Not sure how it handles
> optional
> > dependencies.
> >
>
> I do not know much about Maven, is this related to this issue?:
>
> http://issues.cocoondev.org/jira/secure/ViewIssue.jspa?key=FOR-55
>
>
Sort of opposites. AFAICT, that issue is to allow maven projects to build their
forrest site as part of the build process. In other words, a forrest plugin for
the maven project. What I am a suggesting would be to use maven to build
forrest. I haven't used maven too much either, so I don't know how much work
this would be or if we would even want to do it.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave Brondsema wrote:
Have you considered using maven for builds? It will download all the
latest
> dependency jars from a central repository. Not sure how it handles optional
> dependencies.
>
I do not know much about Maven, is this related to this issue?:
http://issues.cocoondev.org/jira/secure/ViewIssue.jspa?key=FOR-55
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Jeff Turner <je...@apache.org>:
> On Wed, Sep 10, 2003 at 08:21:45PM -0000, cheche@apache.org wrote:
> > cheche 2003/09/10 13:21:45
> >
> > Modified: src/resources/conf forrest.xmap sitemap.xmap
> > src/resources/fresh-site/src/documentation/content/xdocs
> > site.xml
> > Added: legal LICENSE.jdtcore
> > lib/core jdtcore-2.1.0.jar
>
> Couldn't we rather have an Ant task that fetches jdtcore.jar? 95% of
> Forrest users don't need XSP, so adding 2.3mb to the download is a high
> price to pay.
>
> --Jeff
>
Have you considered using maven for builds? It will download all the latest
dependency jars from a central repository. Not sure how it handles optional
dependencies.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets page2document.xsl
Posted by Jeff Turner <je...@apache.org>.
On Wed, Sep 10, 2003 at 08:21:45PM -0000, cheche@apache.org wrote:
> cheche 2003/09/10 13:21:45
>
> Modified: src/resources/conf forrest.xmap sitemap.xmap
> src/resources/fresh-site/src/documentation/content/xdocs
> site.xml
> Added: legal LICENSE.jdtcore
> lib/core jdtcore-2.1.0.jar
Couldn't we rather have an Ant task that fetches jdtcore.jar? 95% of
Forrest users don't need XSP, so adding 2.3mb to the download is a high
price to pay.
--Jeff