You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2002/08/08 14:26:55 UTC
[PROPOSAL] Cocoon-apps CVS module
Vadim Gritsenko wrote:
>>From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>>
>>On Thursday, August 8, 2002, at 10:18 am, Nicola Ken Barozzi wrote:
>>
>>
>...
>
>
>>>Let's make a cocoon-apps CVS repository that can trigger the
>>>compilation of Cocoon by assuming that the cocoon2 CVS is checked
>>>
>>>
>out
>
>
>>>in the same common dir.
>>>
>>>It would make it easier also for the cleanup that's gonna take place
>>>soon.
>>>
>>>So, how does this sound?
>>>
>>>
>>+1
>>
>>I think the idea of a cocoon-apps area closely associated with the
>>Cocoon project is essential. The separation of apps from cocoon is
>>important, but it is also important to the Cocoon project to have lots
>>of apps that turn Cocoon into a quick to implement solution for a
>>
>>
>whole
>
>
>>range of applications. It makes no sense to force people to locate
>>these applications in timeconsuming-to-setup separate projects. In
>>some cases it will be these apps that 'sell' Cocoon.
>>
>>However (and this is a minor point). I have a lot of frustrations
>>
>>
>with
>
>
>>the configuration of the Avalon project, and one such frustration is
>>the dependancy of projects upon other projects with critical namings,
>>that are required to be in the same common parent directory and have
>>
>>
>to
>
>
>>be built in a particular order in order to function.
>>
>>
>
>I think Cocoon-apps's build can invoke Cocoon's build, so this should
>not be an issue.
>
>
>
>
>>Cocoon applications will be dependant upon Cocoon: I therefore suggest
>>that the cocoon-apps directory should be located *inside* the cocoon
>>CVS repository.
>>
>>
>
>Not sure that this is better.
>
>Vadim
>
>
>
I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
cocoon-apps. Which is for sample applications
using cocoon. The bar for giving people commit access would be lower
than the core. The main purpose would be
to encourage folks to write example apps. Such usage example would be
REALLY useful to me.
Jakarta Lucene does this with lucene-scratchpad (which is basically for
the same thing.....different terminology).
This would also not cloud the Cocoon repository with a bunch of apps.
-andy
>
>
>>Stuart.
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ugo Cei <u....@cbim.it>.
Andrew C. Oliver wrote:
> I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
> cocoon-apps. Which is for sample applications
> using cocoon. The bar for giving people commit access would be lower
> than the core. The main purpose would be
> to encourage folks to write example apps. Such usage example would be
> REALLY useful to me.
+1 (from a non-committer).
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Building Cocoon on Mac OS X
Posted by Jesse Reynolds <li...@va.com.au>.
Urgh, I think I just answered my own question... corrupted filenames eg:
"AbstractJavaCompiler.ja100644"
/src/java/org/apache/cocoon/components/language/programming/java/AbstractJavaCompiler.ja100644
yikes... Ah, I must have used "tar" and not "gnutar". DOH!
package:
Building jar: /Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/cocoon.jar
Building jar:
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/cocoon-scratchpad.jar
BUILD SUCCESSFUL
Total time: 1 minute 42 seconds
Yay
cheers
jesse
At 8:08 +1000 16/8/2002, Jesse Reynolds wrote:
>Hello folx
>
>Has anyone ever built Cocoon 2.x on Mac OS X?
>
>I got about 36 errors the first time I tried, below. They mostly
>seem to be classes not found... any ideas anyone?
>
>I'm on Mac OS X version 10.1.5 on a powerbook g4.
>
>
>compile:
>Compiling with Java 1.3, debug on, optimize off, deprecation off
>Compiling 19 source files to
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/classes
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Javac.java:71:
>Superclass
>org.apache.cocoon.components.language.programming.java.AbstractJavaCompiler
>of class
>org.apache.cocoon.components.language.programming.java.Javac not
>found.
>public class Javac extends AbstractJavaCompiler {
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/JavaLanguage.java:64:
>Class
>org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage
>not found in import.
>import
>org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/JavaLanguage.java:80:
>Superclass
>org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage
>of class
>org.apache.cocoon.components.language.programming.java.JavaLanguage
>not found.
>public class JavaLanguage extends CompiledProgrammingLanguage
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Jikes.java:68:
>Superclass
>org.apache.cocoon.components.language.programming.java.AbstractJavaCompiler
>of class
>org.apache.cocoon.components.language.programming.java.Jikes not
>found.
>public class Jikes extends AbstractJavaCompiler {
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/CategoryNodeBuilder.java:68:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder not
>found.
>public class CategoryNodeBuilder extends AbstractParentProcessingNodeBuilder
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/ContainerNodeBuilder.java:66:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.ContainerNodeBuilder not
>found.
>public class ContainerNodeBuilder extends
>AbstractParentProcessingNodeBuilder implements ThreadSafe {
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ActNodeBuilder.java:58:
>Class
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>not found in import.
>import
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ActNodeBuilder.java:73:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.sitemap.ActNodeBuilder
>not found.
>public class ActNodeBuilder extends AbstractParentProcessingNodeBuilder
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/MatchNodeBuilder.java:61:
>Class
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>not found in import.
>import
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/MatchNodeBuilder.java:75:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.sitemap.MatchNodeBuilder
>not found.
>public class MatchNodeBuilder extends AbstractParentProcessingNodeBuilder
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelineNodeBuilder.java:57:
>Class
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>not found in import.
>import
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelineNodeBuilder.java:70:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder
>not found.
>public class PipelineNodeBuilder extends
>AbstractParentProcessingNodeBuilder implements ThreadSafe {
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SelectNodeBuilder.java:59:
>Class
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>not found in import.
>import
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SelectNodeBuilder.java:72:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder
>not found.
>public class SelectNodeBuilder extends
>AbstractParentProcessingNodeBuilder implements ThreadSafe {
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SitemapNodeBuilder.java:57:
>Class
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>not found in import.
>import
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SitemapNodeBuilder.java:72:
>Superclass
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
>of class
>org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder
>not found.
>public class SitemapNodeBuilder extends
>AbstractParentProcessingNodeBuilder implements ThreadSafe {
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/ElementProcessorSerializer.java:59:
>Class
>org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException
>not found in import.
>import
>org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/HSSFSerializer.java:58:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.HSSFElementProcessorFactory
>not found in import.
>import
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.HSSFElementProcessorFactory;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/POIFSSerializer.java:58:
>Class
>org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException
>not found in import.
>import
>org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/POIFSSerializer.java:60:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.POIFSElementProcessor
>not found in import.
>import
>org.apache.cocoon.components.elementprocessor.impl.poi.POIFSElementProcessor;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/ElementProcessorFactory.java:87:
>Class
>org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException
>not found in throws.
> throws CannotCreateElementProcessorException;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:71:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Sheet
>not found.
> private Sheet _sheet;
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:79:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Sheet
>not found.
> Row(final HSSFRow row, final Sheet sheet)
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:126:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Cell
>not found.
> Cell createCell(final int column, final int cellType)
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:133:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Cell
>not found.
> Cell retval = new Cell(_row
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:133:
>Class
>org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Cell
>not found.
> Cell retval = new Cell(_row
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:110:
>No variable classpath defined in class
>org.apache.cocoon.components.language.programming.java.Pizza.
> Main.setClassReader(new ClassReader(this.classpath, null));
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:114:
>Undefined variable: file
> Main.compile(new String[]{file},
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:116:
>Undefined variable: destDir
> new FileCompilerOutput(new File(destDir)),
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:119:
>No variable errors defined in class
>org.apache.cocoon.components.language.programming.java.Pizza.
> this.errors = new ByteArrayInputStream(err.toByteArray());
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/NamedContainerNodeBuilder.java:69:
>Method
>configure(org.apache.avalon.framework.configuration.Configuration)
>not found in class
>org.apache.cocoon.components.treeprocessor.ContainerNodeBuilder.
> super.configure(config);
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java:71:
>No variable treeBuilder defined in class
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> this.treeBuilder.setupNode(node, config);
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java:73:
>Method
>buildChildNodes(org.apache.avalon.framework.configuration.Configuration)
>not found in class
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> ProcessingNode[] children = buildChildNodes(config);
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java:76:
>Method getLogger() not found in class
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> getLogger().error(msg);
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ViewNodeBuilder.java:88:
>Method getLogger() not found in class
>org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
> getLogger().error(msg);
> ^
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ViewNodeBuilder.java:93:
>No variable treeBuilder defined in class
>org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
> SitemapLanguage sitemapBuilder = (SitemapLanguage)this.treeBuilder;
> ^
>36 errors
>
>BUILD FAILED
>
>/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build.xml:912: Compile
>failed, messages should have been provided.
>
>Total time: 15 seconds
>
>--
> Jesse Reynolds - Virtual Artists Pty Ltd - http://www.va.com.au
>
> Email: jesse (at) va.com.au > Website Development
> Phone: +61 (0)8 8223 2288 > Web & Email Hosting
> Web: http://jesse.va.com.au > Streaming Media Hosting
> > Telehousing / Colocation
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
>To unsubscribe, e-mail: <co...@xml.apache.org>
>For additional commands, e-mail: <co...@xml.apache.org>
--
Jesse Reynolds - Virtual Artists Pty Ltd - http://www.va.com.au
Email: jesse (at) va.com.au > Website Development
Phone: +61 (0)8 8223 2288 > Web & Email Hosting
Web: http://jesse.va.com.au > Streaming Media Hosting
> Telehousing / Colocation
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Building Cocoon on Mac OS X
Posted by Jesse Reynolds <li...@va.com.au>.
Hello folx
Has anyone ever built Cocoon 2.x on Mac OS X?
I got about 36 errors the first time I tried, below. They mostly seem
to be classes not found... any ideas anyone?
I'm on Mac OS X version 10.1.5 on a powerbook g4.
compile:
Compiling with Java 1.3, debug on, optimize off, deprecation off
Compiling 19 source files to
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/classes
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Javac.java:71:
Superclass
org.apache.cocoon.components.language.programming.java.AbstractJavaCompiler
of class org.apache.cocoon.components.language.programming.java.Javac
not found.
public class Javac extends AbstractJavaCompiler {
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/JavaLanguage.java:64:
Class
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage
not found in import.
import
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/JavaLanguage.java:80:
Superclass
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage
of class
org.apache.cocoon.components.language.programming.java.JavaLanguage
not found.
public class JavaLanguage extends CompiledProgrammingLanguage
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Jikes.java:68:
Superclass
org.apache.cocoon.components.language.programming.java.AbstractJavaCompiler
of class org.apache.cocoon.components.language.programming.java.Jikes
not found.
public class Jikes extends AbstractJavaCompiler {
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/CategoryNodeBuilder.java:68:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder not
found.
public class CategoryNodeBuilder extends AbstractParentProcessingNodeBuilder
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/ContainerNodeBuilder.java:66:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.ContainerNodeBuilder not
found.
public class ContainerNodeBuilder extends
AbstractParentProcessingNodeBuilder implements ThreadSafe {
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ActNodeBuilder.java:58:
Class
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
not found in import.
import
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ActNodeBuilder.java:73:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.sitemap.ActNodeBuilder not
found.
public class ActNodeBuilder extends AbstractParentProcessingNodeBuilder
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/MatchNodeBuilder.java:61:
Class
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
not found in import.
import
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/MatchNodeBuilder.java:75:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.sitemap.MatchNodeBuilder
not found.
public class MatchNodeBuilder extends AbstractParentProcessingNodeBuilder
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelineNodeBuilder.java:57:
Class
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
not found in import.
import
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelineNodeBuilder.java:70:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder
not found.
public class PipelineNodeBuilder extends
AbstractParentProcessingNodeBuilder implements ThreadSafe {
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SelectNodeBuilder.java:59:
Class
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
not found in import.
import
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SelectNodeBuilder.java:72:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder
not found.
public class SelectNodeBuilder extends
AbstractParentProcessingNodeBuilder implements ThreadSafe {
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SitemapNodeBuilder.java:57:
Class
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
not found in import.
import
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/SitemapNodeBuilder.java:72:
Superclass
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder
of class
org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder
not found.
public class SitemapNodeBuilder extends
AbstractParentProcessingNodeBuilder implements ThreadSafe {
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/ElementProcessorSerializer.java:59:
Class
org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException
not found in import.
import
org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/HSSFSerializer.java:58:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.HSSFElementProcessorFactory
not found in import.
import
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.HSSFElementProcessorFactory;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/POIFSSerializer.java:58:
Class
org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException
not found in import.
import
org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/serialization/POIFSSerializer.java:60:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.POIFSElementProcessor
not found in import.
import
org.apache.cocoon.components.elementprocessor.impl.poi.POIFSElementProcessor;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/ElementProcessorFactory.java:87:
Class
org.apache.cocoon.components.elementprocessor.CannotCreateElementProcessorException
not found in throws.
throws CannotCreateElementProcessorException;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:71:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Sheet
not found.
private Sheet _sheet;
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:79:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Sheet
not found.
Row(final HSSFRow row, final Sheet sheet)
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:126:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Cell
not found.
Cell createCell(final int column, final int cellType)
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:133:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Cell
not found.
Cell retval = new Cell(_row
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Row.java:133:
Class
org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements.Cell
not found.
Cell retval = new Cell(_row
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:110:
No variable classpath defined in class
org.apache.cocoon.components.language.programming.java.Pizza.
Main.setClassReader(new ClassReader(this.classpath, null));
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:114:
Undefined variable: file
Main.compile(new String[]{file},
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:116:
Undefined variable: destDir
new FileCompilerOutput(new File(destDir)),
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/Pizza.java:119:
No variable errors defined in class
org.apache.cocoon.components.language.programming.java.Pizza.
this.errors = new ByteArrayInputStream(err.toByteArray());
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/NamedContainerNodeBuilder.java:69:
Method
configure(org.apache.avalon.framework.configuration.Configuration)
not found in class
org.apache.cocoon.components.treeprocessor.ContainerNodeBuilder.
super.configure(config);
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java:71:
No variable treeBuilder defined in class
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
this.treeBuilder.setupNode(node, config);
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java:73:
Method
buildChildNodes(org.apache.avalon.framework.configuration.Configuration)
not found in class
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
ProcessingNode[] children = buildChildNodes(config);
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java:76:
Method getLogger() not found in class
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
getLogger().error(msg);
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ViewNodeBuilder.java:88:
Method getLogger() not found in class
org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
getLogger().error(msg);
^
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build/cocoon/src/org/apache/cocoon/components/treeprocessor/sitemap/ViewNodeBuilder.java:93:
No variable treeBuilder defined in class
org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
SitemapLanguage sitemapBuilder = (SitemapLanguage)this.treeBuilder;
^
36 errors
BUILD FAILED
/Installers/cocoon-2.0.2-src/cocoon-2.0.2/build.xml:912: Compile
failed, messages should have been provided.
Total time: 15 seconds
--
Jesse Reynolds - Virtual Artists Pty Ltd - http://www.va.com.au
Email: jesse (at) va.com.au > Website Development
Phone: +61 (0)8 8223 2288 > Web & Email Hosting
Web: http://jesse.va.com.au > Streaming Media Hosting
> Telehousing / Colocation
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Redirect/Rewrite Module
Posted by Michael Wechner <mi...@wyona.org>.
Giacomo Pati wrote:
>On Fri, 9 Aug 2002, Michael Wechner wrote:
>
>>Hi
>>
>>I have a situation where I would like to do a lot of
>>URI-redirects/rewrites. I know I can do this via the sitemap,
>>but other people would be doing this. So for the reason of "Separation
>>of Concern" I would like to separate this from the actual sitemap.
>>
>>My question is what are the possibilties to do something like that?
>>
>>-One way would probably be to have a separate sitemap dedicated to
>>redirects, which is mounted by the actual sitemap.
>>
>>-Or to have the redirects in a separate file, which is "pulled in" by
>>the actual sitemap as an external entity
>>
>>-Or to have an action/component, where every request is sent through and
>>is acting
>>as an redirect/rewrite module (and maybe calling Cocoon again!!)
>>
>>Any thoughts on this?
>>
>
>What about redesigning your URI space?
>
>You know, I'm not a friend of redirects as they where made to keep old
>URIs still working if you had to restructure your site. It seems to me
>that people think redirection is a tool/pattern for web development.
>
I agree with you, but the problem of old URIs will probably exist for
another year or so:-)
I think there are at least two solutions:
1) You can propagate the modifications of URIs through the net using a
P2P approach
or something similar. This would not only be good for old URIs, but also
for URIs where
content is changing all the time, such as for instance RSS. (For
instance Slashdot has the
policy that you are not "allowed" to request their RSS more often than
every 30 minutes,
else your IP will be blocked.)
2) Each URI has an owner. When the URI is old (expired), but is still
being requested, then the server should tell the owner about it
Both solutions could be part of a Content Management System/Framework.
But there is also another "misuse" of redirects:
Companies (for instance newspapers) sometimes want to announce a new
"product"
on the web, but the URI is too long for people remembering when reading
the adds,
but actually it would be appropriate context-wise. So the marketing
department thinks
of an "abbreviated" URI.
All the best
Michael
>
>
>Giacomo
>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
>To unsubscribe, e-mail: <co...@xml.apache.org>
>For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Redirect/Rewrite Module
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 9 Aug 2002, Michael Wechner wrote:
> Hi
>
> I have a situation where I would like to do a lot of
> URI-redirects/rewrites. I know I can do this via the sitemap,
> but other people would be doing this. So for the reason of "Separation
> of Concern" I would like to separate this from the actual sitemap.
>
> My question is what are the possibilties to do something like that?
>
> -One way would probably be to have a separate sitemap dedicated to
> redirects, which is mounted by the actual sitemap.
>
> -Or to have the redirects in a separate file, which is "pulled in" by
> the actual sitemap as an external entity
>
> -Or to have an action/component, where every request is sent through and
> is acting
> as an redirect/rewrite module (and maybe calling Cocoon again!!)
>
> Any thoughts on this?
What about redesigning your URI space?
You know, I'm not a friend of redirects as they where made to keep old
URIs still working if you had to restructure your site. It seems to me
that people think redirection is a tool/pattern for web development.
Giacomo
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Redirect/Rewrite Module
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 9 Aug 2002, Michael Wechner wrote:
> Hi
>
> I have a situation where I would like to do a lot of
> URI-redirects/rewrites. I know I can do this via the sitemap,
> but other people would be doing this. So for the reason of "Separation
> of Concern" I would like to separate this from the actual sitemap.
>
> My question is what are the possibilties to do something like that?
>
> -One way would probably be to have a separate sitemap dedicated to
> redirects, which is mounted by the actual sitemap.
>
> -Or to have the redirects in a separate file, which is "pulled in" by
> the actual sitemap as an external entity
>
> -Or to have an action/component, where every request is sent through and
> is acting
> as an redirect/rewrite module (and maybe calling Cocoon again!!)
>
> Any thoughts on this?
What about redesigning your URI space?
You know, I'm not a friend of redirects as they where made to keep old
URIs still working if you had to restructure your site. It seems to me
that people think redirection is a tool/pattern for web development.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Redirect/Rewrite Module
Posted by Michael Wechner <mi...@wyona.org>.
Hi
I have a situation where I would like to do a lot of
URI-redirects/rewrites. I know I can do this via the sitemap,
but other people would be doing this. So for the reason of "Separation
of Concern" I would like to separate this from the actual sitemap.
My question is what are the possibilties to do something like that?
-One way would probably be to have a separate sitemap dedicated to
redirects, which is mounted by the actual sitemap.
-Or to have the redirects in a separate file, which is "pulled in" by
the actual sitemap as an external entity
-Or to have an action/component, where every request is sent through and
is acting
as an redirect/rewrite module (and maybe calling Cocoon again!!)
Any thoughts on this?
Thanks a lot in advance
Michael
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ivelin Ivanov wrote:
>Andy,
>
>----- Original Message -----
>From: "Andrew C. Oliver" <ac...@apache.org>
>To: <co...@xml.apache.org>
>Sent: Friday, August 09, 2002 7:31 AM
>Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>
>
>
>
>>Hi Ivelin,
>>
>>In the near future I plan on donating this:
>>http://www.superlinksoftware.com/cocoon/samples/bringmethis/
>>along with documentation on the pieces of it, why they were used, "best
>>practices", etc. The intent is for this to serve as a
>>"pet shop example" minus the recent connotation. I hope others will
>>help refactor it into *best* practices, etc.
>>
>>
>
>Will be nice to have as an app.
>I like the app separation idea. I am only concerned with stretching the 2.1
>release too far.
>
>
Which is WHY we need to have the cocoon-apps area, so that we DON'T
stretch the 2.1 release too far.
Besides, I've been working on this since BEFORE 2.1 started, and all of
the work I'm doing for 2.1 is to
support this effort.
>
>
>>Now, do I think this should be CLOSELY associated with Cocoon (read:
>>docs featured on the website, stored
>>on apache.org, YES)
>>
>>Do I think it needs to go in the xml-cocoon2 module? Not necessarily.
>>
>>Do I hope to be a committer of cocoon-apps? Absolutely (it will be a
>>pain in the a** for anyone else to keep up with the patches to
>>the bringmethis reverse auctions example). Do I think that should make
>>me a committer to xml-cocoon2 module? No.
>>
>>So while I understand your concerns, I think we need this BECAUSE
>>documentation is a priority for Cocoon.
>>
>>Secondly, look at the new cocoon documentation wiki:
>>http://outerthought.net/wiki/Wiki.jsp.
>>
>>Notice the activity! Its been DAILY! And already I think there are
>>several better examples of how to configure the sitemap
>>than in the Cocoon doc body.
>>
>>
>
>
>Is the final goal for the content to make it in the main doc site?
>
yes.
>If so, then it's a good staging board.
>I hope it does not evolve on its own and in parallel with the main docs
>without synchronization between the two.
>
>
Think of it as the "documentation content production area" (And if you
notice its VERY successful so far).
-Andy
>
>
>Ivelin
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>It would be great if Dianna embraces this process and applies her
>coordinator role to decide when the content on the "development" site (Wiki
>that is) is ready for release on the main site.
>
>
>
+1
>For starters, a link should be added on the Cocoon Links page to the wiki.
>
>
+1 (I'd submit a patch but its more work to commit a 1 line patch than
to do it yourself ;-) )
>
>Ivelin
>
>
>
>
>>I think content from the Wiki can be migrated into the main documentation,
>>hopefully that will be a relatively straight-forward editorial effort.
>>
>>L.
>>
>>
>>--
>>Leigh Dodds
>>http://weblogs.userland.com/eclectic
>>"Pluralitas non est ponenda sine necessitate" -- William of Ockham
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ivelin Ivanov <iv...@apache.org>.
----- Original Message -----
From: "Leigh Dodds" <ld...@ingenta.com>
To: <co...@xml.apache.org>
Sent: Friday, August 09, 2002 8:53 AM
Subject: RE: [PROPOSAL] Cocoon-apps CVS module
> > Is the final goal for the content to make it in the main doc site?
> > If so, then it's a good staging board.
> > I hope it does not evolve on its own and in parallel with the main docs
> > without synchronization between the two.
>
> Out of interest, why would it be a problem if it did evolve into a
> useful resource in it's own right?
I think I didn't express my thoughts well.
I meant that it is great if it is a lively forge of Cocoon documentation, as
long as all the stable information is reflected back in the main site.
The Wiki site might even be a better idea than the doc list, since when
someone wants to contribute, s/he can do so easily and let the commiters
edit the content as their time permits.
It would be great if Dianna embraces this process and applies her
coordinator role to decide when the content on the "development" site (Wiki
that is) is ready for release on the main site.
This will best of both worlds. A lively staging sandbox on one side and a
high-quality doc package for the end users.
Does this make sence?
For starters, a link should be added on the Cocoon Links page to the wiki.
Ivelin
>
> I think content from the Wiki can be migrated into the main documentation,
> hopefully that will be a relatively straight-forward editorial effort.
>
> L.
>
>
> --
> Leigh Dodds
> http://weblogs.userland.com/eclectic
> "Pluralitas non est ponenda sine necessitate" -- William of Ockham
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Cocoon-apps CVS module
Posted by Leigh Dodds <ld...@ingenta.com>.
> Is the final goal for the content to make it in the main doc site?
> If so, then it's a good staging board.
> I hope it does not evolve on its own and in parallel with the main docs
> without synchronization between the two.
Out of interest, why would it be a problem if it did evolve into a
useful resource in it's own right?
I think content from the Wiki can be migrated into the main documentation,
hopefully that will be a relatively straight-forward editorial effort.
L.
--
Leigh Dodds
http://weblogs.userland.com/eclectic
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ivelin Ivanov <iv...@apache.org>.
Andy,
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, August 09, 2002 7:31 AM
Subject: Re: [PROPOSAL] Cocoon-apps CVS module
> Hi Ivelin,
>
> In the near future I plan on donating this:
> http://www.superlinksoftware.com/cocoon/samples/bringmethis/
> along with documentation on the pieces of it, why they were used, "best
> practices", etc. The intent is for this to serve as a
> "pet shop example" minus the recent connotation. I hope others will
> help refactor it into *best* practices, etc.
Will be nice to have as an app.
I like the app separation idea. I am only concerned with stretching the 2.1
release too far.
>
> Now, do I think this should be CLOSELY associated with Cocoon (read:
> docs featured on the website, stored
> on apache.org, YES)
>
> Do I think it needs to go in the xml-cocoon2 module? Not necessarily.
>
> Do I hope to be a committer of cocoon-apps? Absolutely (it will be a
> pain in the a** for anyone else to keep up with the patches to
> the bringmethis reverse auctions example). Do I think that should make
> me a committer to xml-cocoon2 module? No.
>
> So while I understand your concerns, I think we need this BECAUSE
> documentation is a priority for Cocoon.
>
> Secondly, look at the new cocoon documentation wiki:
> http://outerthought.net/wiki/Wiki.jsp.
>
> Notice the activity! Its been DAILY! And already I think there are
> several better examples of how to configure the sitemap
> than in the Cocoon doc body.
Is the final goal for the content to make it in the main doc site?
If so, then it's a good staging board.
I hope it does not evolve on its own and in parallel with the main docs
without synchronization between the two.
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ivelin Ivanov wrote:
>The feeling of a live & strong community compares to nothing!
>
>
>
While I may agree, I do not understand how that related to what I just
said ;-)
-Andy
>
>----- Original Message -----
>From: "Andrew C. Oliver" <ac...@apache.org>
>To: <co...@xml.apache.org>
>Sent: Friday, August 09, 2002 9:04 AM
>Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>
>
>
>
>>Coming very soon. Next few weeks I'm wrapping up the Bringmethis
>>example. My interest in
>>these grew from that. I'm also working on some paid commercial stuff
>>that has gotten in the way but
>>I'm very close.
>>
>>-Andy
>>
>>
>>Ivelin Ivanov wrote:
>>
>>
>>
>>>Andy,
>>>
>>>on another note, you mentioned you were planning to merge CInclude with
>>>XInclude. Is this still going or is on hold?
>>>
>>>
>>>Ivelin
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ivelin Ivanov <iv...@apache.org>.
The feeling of a live & strong community compares to nothing!
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, August 09, 2002 9:04 AM
Subject: Re: [PROPOSAL] Cocoon-apps CVS module
> Coming very soon. Next few weeks I'm wrapping up the Bringmethis
> example. My interest in
> these grew from that. I'm also working on some paid commercial stuff
> that has gotten in the way but
> I'm very close.
>
> -Andy
>
>
> Ivelin Ivanov wrote:
>
> >Andy,
> >
> >on another note, you mentioned you were planning to merge CInclude with
> >XInclude. Is this still going or is on hold?
> >
> >
> >Ivelin
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Coming very soon. Next few weeks I'm wrapping up the Bringmethis
example. My interest in
these grew from that. I'm also working on some paid commercial stuff
that has gotten in the way but
I'm very close.
-Andy
Ivelin Ivanov wrote:
>Andy,
>
>on another note, you mentioned you were planning to merge CInclude with
>XInclude. Is this still going or is on hold?
>
>
>Ivelin
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ivelin Ivanov <iv...@apache.org>.
Andy,
on another note, you mentioned you were planning to merge CInclude with
XInclude. Is this still going or is on hold?
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Hi Ivelin,
In the near future I plan on donating this:
http://www.superlinksoftware.com/cocoon/samples/bringmethis/
along with documentation on the pieces of it, why they were used, "best
practices", etc. The intent is for this to serve as a
"pet shop example" minus the recent connotation. I hope others will
help refactor it into *best* practices, etc.
Now, do I think this should be CLOSELY associated with Cocoon (read:
docs featured on the website, stored
on apache.org, YES)
Do I think it needs to go in the xml-cocoon2 module? Not necessarily.
Do I hope to be a committer of cocoon-apps? Absolutely (it will be a
pain in the a** for anyone else to keep up with the patches to
the bringmethis reverse auctions example). Do I think that should make
me a committer to xml-cocoon2 module? No.
So while I understand your concerns, I think we need this BECAUSE
documentation is a priority for Cocoon.
Secondly, look at the new cocoon documentation wiki:
http://outerthought.net/wiki/Wiki.jsp.
Notice the activity! Its been DAILY! And already I think there are
several better examples of how to configure the sitemap
than in the Cocoon doc body.
-Andy
Ivelin Ivanov wrote:
>Thanks for the clarification.
>
>I like the idea of splitting applications as a parallel CVS repo for
>mutliple reasons.
>
>However is the number of Cocoon apps really big enough to expand beyond
>scratchpad just yet?
>
>Wyona, CocoBlog, Portal. What else?
>
>Slashedit is a demo, not a full blown app. Wrong?
>
>I consider the Authentication, XMLForm & i18n extensions, which need to
>mature and eventually become part of 2.1 core.
>
>Isn't it most important to stabilize the build, finish the documentation
>effort and prepare cocoon 2.1 with forrest for prime time.
>
>If I remember correctly Stefano's release plan, he wanted 2.1 early next
>year. One year release cycle is a good rythm that we shouldn't disturb if
>possible.
>
>Are we not taking on too many tasks at once, risking neither one to be done
>right and within a reasonable time frame.
>
>A month ago everyone was very excited about Dianna's initiative to
>coordinate the project documentation. Now, there are hardly any emails on
>the cocoon-doc list. We moved to the next exciting thing...again.
>
>Documentation is still a big problem.
>Look at the emails on the cocoon-user list. People are asking for
>documentation and examples.
>Let's finish that first and then integrate with Forrest.
>
>Am I totally out of whack here ?-)
>
>Cheers,
>
>Ivelin
>
>
>
>----- Original Message -----
>From: "Andrew C. Oliver" <ac...@apache.org>
>To: <co...@xml.apache.org>
>Sent: Thursday, August 08, 2002 9:03 AM
>Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>
>
>
>
>>Ivelin Ivanov wrote:
>>
>>
>>
>>>Seems like I am reading emails backwards.
>>>Would the cocoon apps be an alternative to scratchpad or independent of
>>>
>>>
>it?
>
>
>>>
>>>
>>scatchapad = immature extensions to Cocoon
>>
>>cocoon-apps = Cocoon based applications, such as example apps,
>>cocoon-based solutions like Cocco blog.
>>
>>Committers to cocoon-apps would *not necessarily* be committers to
>>Cocoon. All cocoon committers would
>>be committers to cocoon-apps.
>>
>>Lucene already does this.
>>
>>It wouldn't have full project status.
>>
>>
>>
>>>----- Original Message -----
>>>From: "Steven Noels" <st...@outerthought.org>
>>>To: <co...@xml.apache.org>
>>>Sent: Thursday, August 08, 2002 7:42 AM
>>>Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Andrew C. Oliver wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
>>>>>cocoon-apps. Which is for sample applications
>>>>>using cocoon. The bar for giving people commit access would be lower
>>>>>than the core. The main purpose would be
>>>>>to encourage folks to write example apps. Such usage example would be
>>>>>REALLY useful to me.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Please remember that you will need to provide *every* cocoon-app
>>>>committer with commit rights for that module. From
>>>>
>>>>
>>>>
>>>>
>>>>
>>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&content-ty
>>
>>
>p
>
>
>>>e=text/vnd.viewcvs-markup,
>>>
>>>
>>>
>>>
>>>>I gather it will be pretty debatable whether we want this or not.
>>>>
>>>>Warning: I'm not being the Apache commit status elitist here (I'm just a
>>>>neighbourhood Forrest committer anyhow), but I believe cocoon-apps
>>>>should be regarded as an xml.apache.org subproject, *or* that the PMC
>>>>should come up with a solution.
>>>>
>>>>Anyway, I shouldn't be posting anymore since I want to go home early
>>>>today, and I'll be off-list for two weeks anyhow. Just make sure that we
>>>>are able to live with the consequences of our decisions. We already have
>>>>a Hall of Fame of considerable weight
>>>>(http://xml.apache.org/cocoon/who.html), not sure whether we want to
>>>>open up the gates for *everybody* who comes up with some Cocoon-based
>>>>app. Even so, there should be rules laid out - *prior* to moving
>>>>
>>>>
>forward.
>
>
>>>></Steven>
>>>>--
>>>>Steven Noels http://outerthought.org/
>>>>Outerthought - Open Source, Java & XML Competence Support Center
>>>>stevenn@outerthought.org stevenn@apache.org
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Redirect/Rewrite Module
Posted by Michael Wechner <mi...@wyona.org>.
Hi
I have a situation where I would like to do a lot of
URI-redirects/rewrites. I know I can do this via the sitemap,
but other people would be doing this. So for the reason of "Separation
of Concern" I would like to separate this from the actual sitemap.
My question is what are the possibilties to do something like that?
-One way would probably be to have a separate sitemap dedicated to
redirects, which is mounted by the actual sitemap.
-Or to have the redirects in a separate file, which is "pulled in" by
the actual sitemap as an external entity
-Or to have an action/component, where every request is sent through and
is acting
as an redirect/rewrite module (and maybe calling Cocoon again!!)
Any thoughts on this?
Thanks a lot in advance
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ivelin Ivanov wrote:
> Thanks for the clarification.
>
> I like the idea of splitting applications as a parallel CVS repo for
> mutliple reasons.
>
> However is the number of Cocoon apps really big enough to expand beyond
> scratchpad just yet?
Don't look at it from the apps perspective, but from the Cocoon core
perspective.
It's not that apps need to get separated from the core as that the core
needs the apps to get off.
> Wyona, CocoBlog, Portal. What else?
>
> Slashedit is a demo, not a full blown app. Wrong?
Everything is a demo in Cocoon ;-)
It should be an app.
> I consider the Authentication, XMLForm & i18n extensions, which need to
> mature and eventually become part of 2.1 core.
These are not apps, these are components, with their demos.
They remain in the Cocoon CVS.
> Isn't it most important to stabilize the build,
Exactly. This is a step to stabilize it.
Complexity has to be reduced, and dependencies cleared.
> finish the documentation
That is going well on its own.
> effort and prepare cocoon 2.1 with forrest for prime time.
Again, it's on its own.
> If I remember correctly Stefano's release plan, he wanted 2.1 early next
> year. One year release cycle is a good rythm that we shouldn't disturb if
> possible.
This is to make it easier to manage the /beast/.
> Are we not taking on too many tasks at once, risking neither one to be done
> right and within a reasonable time frame.
FUD
> A month ago everyone was very excited about Dianna's initiative to
> coordinate the project documentation. Now, there are hardly any emails on
> the cocoon-doc list. We moved to the next exciting thing...again.
No. Wiki is the next step in documentation, and separating the Slashedit
can make us help understand better how to make a Cocoon-based structured
wiki for Forrest.
> Documentation is still a big problem.
> Look at the emails on the cocoon-user list. People are asking for
> documentation and examples.
> Let's finish that first and then integrate with Forrest.
They don't ask about docs on the cocoon-apps, so there is no big deal here.
I volunteered to do the move, so why is it going to slow you?
> Am I totally out of whack here ?-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ivelin Ivanov <iv...@apache.org>.
Thanks for the clarification.
I like the idea of splitting applications as a parallel CVS repo for
mutliple reasons.
However is the number of Cocoon apps really big enough to expand beyond
scratchpad just yet?
Wyona, CocoBlog, Portal. What else?
Slashedit is a demo, not a full blown app. Wrong?
I consider the Authentication, XMLForm & i18n extensions, which need to
mature and eventually become part of 2.1 core.
Isn't it most important to stabilize the build, finish the documentation
effort and prepare cocoon 2.1 with forrest for prime time.
If I remember correctly Stefano's release plan, he wanted 2.1 early next
year. One year release cycle is a good rythm that we shouldn't disturb if
possible.
Are we not taking on too many tasks at once, risking neither one to be done
right and within a reasonable time frame.
A month ago everyone was very excited about Dianna's initiative to
coordinate the project documentation. Now, there are hardly any emails on
the cocoon-doc list. We moved to the next exciting thing...again.
Documentation is still a big problem.
Look at the emails on the cocoon-user list. People are asking for
documentation and examples.
Let's finish that first and then integrate with Forrest.
Am I totally out of whack here ?-)
Cheers,
Ivelin
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, August 08, 2002 9:03 AM
Subject: Re: [PROPOSAL] Cocoon-apps CVS module
> Ivelin Ivanov wrote:
>
> >Seems like I am reading emails backwards.
> >Would the cocoon apps be an alternative to scratchpad or independent of
it?
> >
> >
>
> scatchapad = immature extensions to Cocoon
>
> cocoon-apps = Cocoon based applications, such as example apps,
> cocoon-based solutions like Cocco blog.
>
> Committers to cocoon-apps would *not necessarily* be committers to
> Cocoon. All cocoon committers would
> be committers to cocoon-apps.
>
> Lucene already does this.
>
> It wouldn't have full project status.
>
> >
> >----- Original Message -----
> >From: "Steven Noels" <st...@outerthought.org>
> >To: <co...@xml.apache.org>
> >Sent: Thursday, August 08, 2002 7:42 AM
> >Subject: Re: [PROPOSAL] Cocoon-apps CVS module
> >
> >
> >
> >
> >>Andrew C. Oliver wrote:
> >>
> >>
> >>
> >>>I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
> >>>cocoon-apps. Which is for sample applications
> >>>using cocoon. The bar for giving people commit access would be lower
> >>>than the core. The main purpose would be
> >>>to encourage folks to write example apps. Such usage example would be
> >>>REALLY useful to me.
> >>>
> >>>
> >>Please remember that you will need to provide *every* cocoon-app
> >>committer with commit rights for that module. From
> >>
> >>
> >>
>
>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&content-ty
p
> >e=text/vnd.viewcvs-markup,
> >
> >
> >>I gather it will be pretty debatable whether we want this or not.
> >>
> >>Warning: I'm not being the Apache commit status elitist here (I'm just a
> >>neighbourhood Forrest committer anyhow), but I believe cocoon-apps
> >>should be regarded as an xml.apache.org subproject, *or* that the PMC
> >>should come up with a solution.
> >>
> >>Anyway, I shouldn't be posting anymore since I want to go home early
> >>today, and I'll be off-list for two weeks anyhow. Just make sure that we
> >>are able to live with the consequences of our decisions. We already have
> >>a Hall of Fame of considerable weight
> >>(http://xml.apache.org/cocoon/who.html), not sure whether we want to
> >>open up the gates for *everybody* who comes up with some Cocoon-based
> >>app. Even so, there should be rules laid out - *prior* to moving
forward.
> >>
> >></Steven>
> >>--
> >>Steven Noels http://outerthought.org/
> >>Outerthought - Open Source, Java & XML Competence Support Center
> >>stevenn@outerthought.org stevenn@apache.org
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >>For additional commands, email: cocoon-dev-help@xml.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ivelin Ivanov wrote:
>Seems like I am reading emails backwards.
>Would the cocoon apps be an alternative to scratchpad or independent of it?
>
>
scatchapad = immature extensions to Cocoon
cocoon-apps = Cocoon based applications, such as example apps,
cocoon-based solutions like Cocco blog.
Committers to cocoon-apps would *not necessarily* be committers to
Cocoon. All cocoon committers would
be committers to cocoon-apps.
Lucene already does this.
It wouldn't have full project status.
>
>----- Original Message -----
>From: "Steven Noels" <st...@outerthought.org>
>To: <co...@xml.apache.org>
>Sent: Thursday, August 08, 2002 7:42 AM
>Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>
>
>
>
>>Andrew C. Oliver wrote:
>>
>>
>>
>>>I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
>>>cocoon-apps. Which is for sample applications
>>>using cocoon. The bar for giving people commit access would be lower
>>>than the core. The main purpose would be
>>>to encourage folks to write example apps. Such usage example would be
>>>REALLY useful to me.
>>>
>>>
>>Please remember that you will need to provide *every* cocoon-app
>>committer with commit rights for that module. From
>>
>>
>>
>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&content-typ
>e=text/vnd.viewcvs-markup,
>
>
>>I gather it will be pretty debatable whether we want this or not.
>>
>>Warning: I'm not being the Apache commit status elitist here (I'm just a
>>neighbourhood Forrest committer anyhow), but I believe cocoon-apps
>>should be regarded as an xml.apache.org subproject, *or* that the PMC
>>should come up with a solution.
>>
>>Anyway, I shouldn't be posting anymore since I want to go home early
>>today, and I'll be off-list for two weeks anyhow. Just make sure that we
>>are able to live with the consequences of our decisions. We already have
>>a Hall of Fame of considerable weight
>>(http://xml.apache.org/cocoon/who.html), not sure whether we want to
>>open up the gates for *everybody* who comes up with some Cocoon-based
>>app. Even so, there should be rules laid out - *prior* to moving forward.
>>
>></Steven>
>>--
>>Steven Noels http://outerthought.org/
>>Outerthought - Open Source, Java & XML Competence Support Center
>>stevenn@outerthought.org stevenn@apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Ivelin Ivanov <iv...@apache.org>.
Seems like I am reading emails backwards.
Would the cocoon apps be an alternative to scratchpad or independent of it?
----- Original Message -----
From: "Steven Noels" <st...@outerthought.org>
To: <co...@xml.apache.org>
Sent: Thursday, August 08, 2002 7:42 AM
Subject: Re: [PROPOSAL] Cocoon-apps CVS module
> Andrew C. Oliver wrote:
>
> > I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
> > cocoon-apps. Which is for sample applications
> > using cocoon. The bar for giving people commit access would be lower
> > than the core. The main purpose would be
> > to encourage folks to write example apps. Such usage example would be
> > REALLY useful to me.
>
> Please remember that you will need to provide *every* cocoon-app
> committer with commit rights for that module. From
>
http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&content-typ
e=text/vnd.viewcvs-markup,
> I gather it will be pretty debatable whether we want this or not.
>
> Warning: I'm not being the Apache commit status elitist here (I'm just a
> neighbourhood Forrest committer anyhow), but I believe cocoon-apps
> should be regarded as an xml.apache.org subproject, *or* that the PMC
> should come up with a solution.
>
> Anyway, I shouldn't be posting anymore since I want to go home early
> today, and I'll be off-list for two weeks anyhow. Just make sure that we
> are able to live with the consequences of our decisions. We already have
> a Hall of Fame of considerable weight
> (http://xml.apache.org/cocoon/who.html), not sure whether we want to
> open up the gates for *everybody* who comes up with some Cocoon-based
> app. Even so, there should be rules laid out - *prior* to moving forward.
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> stevenn@outerthought.org stevenn@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
thanks Ken. Excellent.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
>
>> Ok, can someone of the PMC clarify this.
>>
>> We should not use the cocoon cvs for cocoon-apps, so a separate cvs
>> is the way to go. I don't want to give all
>> 'cocoon-apps' committers also access to cocoon itself.
>> So it must be separated.
>
>
> +1
>
>> I think currently, the easiest solution is to start
>> a project on sourceforge etc.
>
>
> Well, there are living projects that do this:
> - avalon-apps is a separate CVS repo
> - lucene has a sandbox where IIUC there can be committers that do not
> commit to the main CVS but viceversa is possible.
>
> I will ask the PMC for suggestions.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Ok, can someone of the PMC clarify this.
>
> We should not use the cocoon cvs for cocoon-apps, so a
> separate cvs is the way to go. I don't want to give all
> 'cocoon-apps' committers also access to cocoon itself.
> So it must be separated.
+1
> I think currently, the easiest solution is to start
> a project on sourceforge etc.
Well, there are living projects that do this:
- avalon-apps is a separate CVS repo
- lucene has a sandbox where IIUC there can be committers that do not
commit to the main CVS but viceversa is possible.
I will ask the PMC for suggestions.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Sam Ruby <ru...@apache.org>.
Andrew C. Oliver wrote:
>
> This is exactly the same kind of thing we want to do. Jon Stevens
> even said it was okay when I questioned if it was legitimate for
> lucene to do it ;-)
It is also OK for cocoon to do it.
This is all very straightforward. All that is needed is the name of the
cvs module (xml-cocoon-apps, perhaps?), where you would like the cvs
commit messages to go (xml-cocoon-cvs?), and who should be granted karma
(either by name or rule).
Subprojects are free to adapt the bylaws as appropriate for their needs.
All I would request is that they are clear, posted, and auditable
(e.g., votes are done on the mailing list).
- Sam Ruby
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Sam Ruby <ru...@apache.org>.
Andrew C. Oliver wrote:
>
> This is exactly the same kind of thing we want to do. Jon Stevens
> even said it was okay when I questioned if it was legitimate for
> lucene to do it ;-)
It is also OK for cocoon to do it.
This is all very straightforward. All that is needed is the name of the
cvs module (xml-cocoon-apps, perhaps?), where you would like the cvs
commit messages to go (xml-cocoon-cvs?), and who should be granted karma
(either by name or rule).
Subprojects are free to adapt the bylaws as appropriate for their needs.
All I would request is that they are clear, posted, and auditable
(e.g., votes are done on the mailing list).
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
1. Scope
2. Its more of a Subproject of Cocoon.
3. Commiters of the main project vote to appoint committers to the
cocoon-apps, the reverse is not true.
look at the Jakarta Lucene project's lucene-sandbox. This is Exactly
what we want to do. The Lucene Sandbox
has committers voted in by the Lucene committers. They just work on
application extensions to lucene (crawlers, etc)
This is exactly the same kind of thing we want to do. Jon Stevens even
said it was okay when I questioned if it was
legitimate for lucene to do it ;-)
-Andy
cc: Jon only because I used his name in vain...
Theodore W. Leung wrote:
>This sounds very much like a subproject to me. Can you explain why you
>think this isn't just a subproject?
>
>Ted
>
>
>On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>>Ok, can someone of the PMC clarify this.
>>>
>>>We should not use the cocoon cvs for cocoon-apps, so a
>>>separate cvs is the way to go. I don't want to give all
>>>'cocoon-apps' committers also access to cocoon itself.
>>>So it must be separated.
>>>
>>>
>>Dear PMC, we need your assistance.
>>
>>Cocoon is gaining more "sample" applications every day, and more are
>>being proposed.
>>
>>We are in the process of cleaning the repository by separating the core,
>>the implementation and the components in different directories.
>>We also need to remove those apps that are not part of Cocoon itself but
>>that are important to us and to the community.
>>Therefore, a consensus is forming towards the creation of a new CVS
>>module for cocoon-apps.
>>
>>The reason why I contact you is that this would not be a completely
>>separate project itself, since we want the Cocoon committers to be able
>>to commit, while having the possibility of voting in committers that do
>>not commit to Cocoon.
>>A kind of young-sister project.
>>
>>Now, this is not a subproject, but not really still Cocoon.
>>What is it? How can it be arranged?
>>Lucene has a similar arrangement IIUC...
>>
>>Also, we had the proposal of a Forrest committer, Steven Noels, who is
>>driving the effort, and hasalready made available equipement.
>>He proposes to host this effort with his company's equipement.
>>Does Apache think it's possible to host Apache stuff on another server?
>>
>>Thank you in advance.
>>
>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
>
> Thank you very much :-)
> Since the community is accepting the proposed addendum, I'll leave
> some more days for the vote, because it's so important, and then send
> the PMC final addendum with the request of the CVS module.
send it to root as well ;-)
>
> Thanks again :-)
>
>> Ted
>>
>> On Mon, 2002-08-12 at 13:50, Nicola Ken Barozzi wrote:
>>
>>> Theodore W. Leung wrote:
>>>
>>>> This sounds very much like a subproject to me. Can you explain why
>>>> you
>>>> think this isn't just a subproject?
>>>
>>>
>>> - It depends very strongly on Cocoon.
>>> - The code it starts with will, have parts come out of Cocoon.
>>> - We would want the Cocoon committers have automatic karma to it.
>>> - Other subprojects already have a similar this arrangement, albeit
>>> on the sister project Jakarta, like Lucene, Avalon, Turbine.
>>> - It doesn't have a project goal, but is more a repository of Cocoon
>>> apps, a sort of Cocoon-Commons.
>>>
>>> On the other hand it would seem to be another subproject, since
>>> there would be a different community round it, but this has also
>>> happened with the cocoon-docs mailing list without creating a
>>> Cocoon-docs subproject.
>>> Besides we would probably still want to use the Cocoon-dev and
>>> Cocoon-user lists for it, at least in the early stages.
>>>
>>> Basically we are thinking about a Cocoon subproject, versus the fact
>>> that the norm is to have Xml.Apache Sub-Projects.
>>>
>>> Can it be arranged?
>>>
>>>
>>>> On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>>>>
>>>>
>>>>> Carsten Ziegeler wrote:
>>>>>
>>>>>
>>>>>> Ok, can someone of the PMC clarify this.
>>>>>>
>>>>>> We should not use the cocoon cvs for cocoon-apps, so a separate
>>>>>> cvs is the way to go. I don't want to give all
>>>>>> 'cocoon-apps' committers also access to cocoon itself.
>>>>>> So it must be separated.
>>>>>
>>>>>
>>>>> Dear PMC, we need your assistance.
>>>>>
>>>>> Cocoon is gaining more "sample" applications every day, and more
>>>>> are being proposed.
>>>>>
>>>>> We are in the process of cleaning the repository by separating the
>>>>> core, the implementation and the components in different directories.
>>>>> We also need to remove those apps that are not part of Cocoon
>>>>> itself but that are important to us and to the community.
>>>>> Therefore, a consensus is forming towards the creation of a new
>>>>> CVS module for cocoon-apps.
>>>>>
>>>>> The reason why I contact you is that this would not be a
>>>>> completely separate project itself, since we want the Cocoon
>>>>> committers to be able to commit, while having the possibility of
>>>>> voting in committers that do not commit to Cocoon.
>>>>> A kind of young-sister project.
>>>>>
>>>>> Now, this is not a subproject, but not really still Cocoon.
>>>>> What is it? How can it be arranged?
>>>>> Lucene has a similar arrangement IIUC...
>>>>>
>>>>> Also, we had the proposal of a Forrest committer, Steven Noels,
>>>>> who is driving the effort, and hasalready made available equipement.
>>>>> He proposes to host this effort with his company's equipement.
>>>>> Does Apache think it's possible to host Apache stuff on another
>>>>> server?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>>
>>>>> --
>>>>> Nicola Ken Barozzi nicolaken@apache.org
>>>>> - verba volant, scripta manent -
>>>>> (discussions get forgotten, just code remains)
>>>>> ---------------------------------------------------------------------
>>>>
>>>>
>>> --
>>> Nicola Ken Barozzi nicolaken@apache.org
>>> - verba volant, scripta manent -
>>> (discussions get forgotten, just code remains)
>>> ---------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Theodore W. Leung wrote:
> Sorry, I was unclear.
>
> I mean subproject of Cocoon, not subproject of xml.apache.org.
In fact this misunderstanding, and the clarifications it brought to,
lead us to a deeper knowledge of what we are doing :-)
> I'm fine for this to be a subproject of/under Cocoon.
Thank you very much :-)
Since the community is accepting the proposed addendum, I'll leave some
more days for the vote, because it's so important, and then send the PMC
final addendum with the request of the CVS module.
Thanks again :-)
> Ted
>
> On Mon, 2002-08-12 at 13:50, Nicola Ken Barozzi wrote:
>
>>Theodore W. Leung wrote:
>>
>>>This sounds very much like a subproject to me. Can you explain why you
>>>think this isn't just a subproject?
>>
>>- It depends very strongly on Cocoon.
>>- The code it starts with will, have parts come out of Cocoon.
>>- We would want the Cocoon committers have automatic karma to it.
>>- Other subprojects already have a similar this arrangement, albeit on
>>the sister project Jakarta, like Lucene, Avalon, Turbine.
>>- It doesn't have a project goal, but is more a repository of Cocoon
>>apps, a sort of Cocoon-Commons.
>>
>>On the other hand it would seem to be another subproject, since there
>>would be a different community round it, but this has also happened with
>>the cocoon-docs mailing list without creating a Cocoon-docs subproject.
>>Besides we would probably still want to use the Cocoon-dev and
>>Cocoon-user lists for it, at least in the early stages.
>>
>>Basically we are thinking about a Cocoon subproject, versus the fact
>>that the norm is to have Xml.Apache Sub-Projects.
>>
>>Can it be arranged?
>>
>>
>>>On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>>>
>>>
>>>>Carsten Ziegeler wrote:
>>>>
>>>>
>>>>>Ok, can someone of the PMC clarify this.
>>>>>
>>>>>We should not use the cocoon cvs for cocoon-apps, so a
>>>>>separate cvs is the way to go. I don't want to give all
>>>>>'cocoon-apps' committers also access to cocoon itself.
>>>>>So it must be separated.
>>>>
>>>>Dear PMC, we need your assistance.
>>>>
>>>>Cocoon is gaining more "sample" applications every day, and more are
>>>>being proposed.
>>>>
>>>>We are in the process of cleaning the repository by separating the core,
>>>>the implementation and the components in different directories.
>>>>We also need to remove those apps that are not part of Cocoon itself but
>>>>that are important to us and to the community.
>>>>Therefore, a consensus is forming towards the creation of a new CVS
>>>>module for cocoon-apps.
>>>>
>>>>The reason why I contact you is that this would not be a completely
>>>>separate project itself, since we want the Cocoon committers to be able
>>>>to commit, while having the possibility of voting in committers that do
>>>>not commit to Cocoon.
>>>>A kind of young-sister project.
>>>>
>>>>Now, this is not a subproject, but not really still Cocoon.
>>>>What is it? How can it be arranged?
>>>>Lucene has a similar arrangement IIUC...
>>>>
>>>>Also, we had the proposal of a Forrest committer, Steven Noels, who is
>>>>driving the effort, and hasalready made available equipement.
>>>>He proposes to host this effort with his company's equipement.
>>>>Does Apache think it's possible to host Apache stuff on another server?
>>>>
>>>>Thank you in advance.
>>>>
>>>>
>>>>--
>>>>Nicola Ken Barozzi nicolaken@apache.org
>>>> - verba volant, scripta manent -
>>>> (discussions get forgotten, just code remains)
>>>>---------------------------------------------------------------------
>>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
>
>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Theodore W. Leung wrote:
> Sorry, I was unclear.
>
> I mean subproject of Cocoon, not subproject of xml.apache.org.
In fact this misunderstanding, and the clarifications it brought to,
lead us to a deeper knowledge of what we are doing :-)
> I'm fine for this to be a subproject of/under Cocoon.
Thank you very much :-)
Since the community is accepting the proposed addendum, I'll leave some
more days for the vote, because it's so important, and then send the PMC
final addendum with the request of the CVS module.
Thanks again :-)
> Ted
>
> On Mon, 2002-08-12 at 13:50, Nicola Ken Barozzi wrote:
>
>>Theodore W. Leung wrote:
>>
>>>This sounds very much like a subproject to me. Can you explain why you
>>>think this isn't just a subproject?
>>
>>- It depends very strongly on Cocoon.
>>- The code it starts with will, have parts come out of Cocoon.
>>- We would want the Cocoon committers have automatic karma to it.
>>- Other subprojects already have a similar this arrangement, albeit on
>>the sister project Jakarta, like Lucene, Avalon, Turbine.
>>- It doesn't have a project goal, but is more a repository of Cocoon
>>apps, a sort of Cocoon-Commons.
>>
>>On the other hand it would seem to be another subproject, since there
>>would be a different community round it, but this has also happened with
>>the cocoon-docs mailing list without creating a Cocoon-docs subproject.
>>Besides we would probably still want to use the Cocoon-dev and
>>Cocoon-user lists for it, at least in the early stages.
>>
>>Basically we are thinking about a Cocoon subproject, versus the fact
>>that the norm is to have Xml.Apache Sub-Projects.
>>
>>Can it be arranged?
>>
>>
>>>On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>>>
>>>
>>>>Carsten Ziegeler wrote:
>>>>
>>>>
>>>>>Ok, can someone of the PMC clarify this.
>>>>>
>>>>>We should not use the cocoon cvs for cocoon-apps, so a
>>>>>separate cvs is the way to go. I don't want to give all
>>>>>'cocoon-apps' committers also access to cocoon itself.
>>>>>So it must be separated.
>>>>
>>>>Dear PMC, we need your assistance.
>>>>
>>>>Cocoon is gaining more "sample" applications every day, and more are
>>>>being proposed.
>>>>
>>>>We are in the process of cleaning the repository by separating the core,
>>>>the implementation and the components in different directories.
>>>>We also need to remove those apps that are not part of Cocoon itself but
>>>>that are important to us and to the community.
>>>>Therefore, a consensus is forming towards the creation of a new CVS
>>>>module for cocoon-apps.
>>>>
>>>>The reason why I contact you is that this would not be a completely
>>>>separate project itself, since we want the Cocoon committers to be able
>>>>to commit, while having the possibility of voting in committers that do
>>>>not commit to Cocoon.
>>>>A kind of young-sister project.
>>>>
>>>>Now, this is not a subproject, but not really still Cocoon.
>>>>What is it? How can it be arranged?
>>>>Lucene has a similar arrangement IIUC...
>>>>
>>>>Also, we had the proposal of a Forrest committer, Steven Noels, who is
>>>>driving the effort, and hasalready made available equipement.
>>>>He proposes to host this effort with his company's equipement.
>>>>Does Apache think it's possible to host Apache stuff on another server?
>>>>
>>>>Thank you in advance.
>>>>
>>>>
>>>>--
>>>>Nicola Ken Barozzi nicolaken@apache.org
>>>> - verba volant, scripta manent -
>>>> (discussions get forgotten, just code remains)
>>>>---------------------------------------------------------------------
>>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
>
>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Theodore W. Leung" <tw...@sauria.com>.
Sorry, I was unclear.
I mean subproject of Cocoon, not subproject of xml.apache.org.
I'm fine for this to be a subproject of/under Cocoon.
Ted
On Mon, 2002-08-12 at 13:50, Nicola Ken Barozzi wrote:
>
> Theodore W. Leung wrote:
> > This sounds very much like a subproject to me. Can you explain why you
> > think this isn't just a subproject?
>
> - It depends very strongly on Cocoon.
> - The code it starts with will, have parts come out of Cocoon.
> - We would want the Cocoon committers have automatic karma to it.
> - Other subprojects already have a similar this arrangement, albeit on
> the sister project Jakarta, like Lucene, Avalon, Turbine.
> - It doesn't have a project goal, but is more a repository of Cocoon
> apps, a sort of Cocoon-Commons.
>
> On the other hand it would seem to be another subproject, since there
> would be a different community round it, but this has also happened with
> the cocoon-docs mailing list without creating a Cocoon-docs subproject.
> Besides we would probably still want to use the Cocoon-dev and
> Cocoon-user lists for it, at least in the early stages.
>
> Basically we are thinking about a Cocoon subproject, versus the fact
> that the norm is to have Xml.Apache Sub-Projects.
>
> Can it be arranged?
>
> > On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
> >
> >>Carsten Ziegeler wrote:
> >>
> >>>Ok, can someone of the PMC clarify this.
> >>>
> >>>We should not use the cocoon cvs for cocoon-apps, so a
> >>>separate cvs is the way to go. I don't want to give all
> >>>'cocoon-apps' committers also access to cocoon itself.
> >>>So it must be separated.
> >>
> >>Dear PMC, we need your assistance.
> >>
> >>Cocoon is gaining more "sample" applications every day, and more are
> >>being proposed.
> >>
> >>We are in the process of cleaning the repository by separating the core,
> >>the implementation and the components in different directories.
> >>We also need to remove those apps that are not part of Cocoon itself but
> >>that are important to us and to the community.
> >>Therefore, a consensus is forming towards the creation of a new CVS
> >>module for cocoon-apps.
> >>
> >>The reason why I contact you is that this would not be a completely
> >>separate project itself, since we want the Cocoon committers to be able
> >>to commit, while having the possibility of voting in committers that do
> >>not commit to Cocoon.
> >>A kind of young-sister project.
> >>
> >>Now, this is not a subproject, but not really still Cocoon.
> >>What is it? How can it be arranged?
> >>Lucene has a similar arrangement IIUC...
> >>
> >>Also, we had the proposal of a Forrest committer, Steven Noels, who is
> >>driving the effort, and hasalready made available equipement.
> >>He proposes to host this effort with his company's equipement.
> >>Does Apache think it's possible to host Apache stuff on another server?
> >>
> >>Thank you in advance.
> >>
> >>
> >>--
> >>Nicola Ken Barozzi nicolaken@apache.org
> >> - verba volant, scripta manent -
> >> (discussions get forgotten, just code remains)
> >>---------------------------------------------------------------------
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Theodore W. Leung" <tw...@sauria.com>.
Sorry, I was unclear.
I mean subproject of Cocoon, not subproject of xml.apache.org.
I'm fine for this to be a subproject of/under Cocoon.
Ted
On Mon, 2002-08-12 at 13:50, Nicola Ken Barozzi wrote:
>
> Theodore W. Leung wrote:
> > This sounds very much like a subproject to me. Can you explain why you
> > think this isn't just a subproject?
>
> - It depends very strongly on Cocoon.
> - The code it starts with will, have parts come out of Cocoon.
> - We would want the Cocoon committers have automatic karma to it.
> - Other subprojects already have a similar this arrangement, albeit on
> the sister project Jakarta, like Lucene, Avalon, Turbine.
> - It doesn't have a project goal, but is more a repository of Cocoon
> apps, a sort of Cocoon-Commons.
>
> On the other hand it would seem to be another subproject, since there
> would be a different community round it, but this has also happened with
> the cocoon-docs mailing list without creating a Cocoon-docs subproject.
> Besides we would probably still want to use the Cocoon-dev and
> Cocoon-user lists for it, at least in the early stages.
>
> Basically we are thinking about a Cocoon subproject, versus the fact
> that the norm is to have Xml.Apache Sub-Projects.
>
> Can it be arranged?
>
> > On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
> >
> >>Carsten Ziegeler wrote:
> >>
> >>>Ok, can someone of the PMC clarify this.
> >>>
> >>>We should not use the cocoon cvs for cocoon-apps, so a
> >>>separate cvs is the way to go. I don't want to give all
> >>>'cocoon-apps' committers also access to cocoon itself.
> >>>So it must be separated.
> >>
> >>Dear PMC, we need your assistance.
> >>
> >>Cocoon is gaining more "sample" applications every day, and more are
> >>being proposed.
> >>
> >>We are in the process of cleaning the repository by separating the core,
> >>the implementation and the components in different directories.
> >>We also need to remove those apps that are not part of Cocoon itself but
> >>that are important to us and to the community.
> >>Therefore, a consensus is forming towards the creation of a new CVS
> >>module for cocoon-apps.
> >>
> >>The reason why I contact you is that this would not be a completely
> >>separate project itself, since we want the Cocoon committers to be able
> >>to commit, while having the possibility of voting in committers that do
> >>not commit to Cocoon.
> >>A kind of young-sister project.
> >>
> >>Now, this is not a subproject, but not really still Cocoon.
> >>What is it? How can it be arranged?
> >>Lucene has a similar arrangement IIUC...
> >>
> >>Also, we had the proposal of a Forrest committer, Steven Noels, who is
> >>driving the effort, and hasalready made available equipement.
> >>He proposes to host this effort with his company's equipement.
> >>Does Apache think it's possible to host Apache stuff on another server?
> >>
> >>Thank you in advance.
> >>
> >>
> >>--
> >>Nicola Ken Barozzi nicolaken@apache.org
> >> - verba volant, scripta manent -
> >> (discussions get forgotten, just code remains)
> >>---------------------------------------------------------------------
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Theodore W. Leung wrote:
> This sounds very much like a subproject to me. Can you explain why you
> think this isn't just a subproject?
- It depends very strongly on Cocoon.
- The code it starts with will, have parts come out of Cocoon.
- We would want the Cocoon committers have automatic karma to it.
- Other subprojects already have a similar this arrangement, albeit on
the sister project Jakarta, like Lucene, Avalon, Turbine.
- It doesn't have a project goal, but is more a repository of Cocoon
apps, a sort of Cocoon-Commons.
On the other hand it would seem to be another subproject, since there
would be a different community round it, but this has also happened with
the cocoon-docs mailing list without creating a Cocoon-docs subproject.
Besides we would probably still want to use the Cocoon-dev and
Cocoon-user lists for it, at least in the early stages.
Basically we are thinking about a Cocoon subproject, versus the fact
that the norm is to have Xml.Apache Sub-Projects.
Can it be arranged?
> On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>Ok, can someone of the PMC clarify this.
>>>
>>>We should not use the cocoon cvs for cocoon-apps, so a
>>>separate cvs is the way to go. I don't want to give all
>>>'cocoon-apps' committers also access to cocoon itself.
>>>So it must be separated.
>>
>>Dear PMC, we need your assistance.
>>
>>Cocoon is gaining more "sample" applications every day, and more are
>>being proposed.
>>
>>We are in the process of cleaning the repository by separating the core,
>>the implementation and the components in different directories.
>>We also need to remove those apps that are not part of Cocoon itself but
>>that are important to us and to the community.
>>Therefore, a consensus is forming towards the creation of a new CVS
>>module for cocoon-apps.
>>
>>The reason why I contact you is that this would not be a completely
>>separate project itself, since we want the Cocoon committers to be able
>>to commit, while having the possibility of voting in committers that do
>>not commit to Cocoon.
>>A kind of young-sister project.
>>
>>Now, this is not a subproject, but not really still Cocoon.
>>What is it? How can it be arranged?
>>Lucene has a similar arrangement IIUC...
>>
>>Also, we had the proposal of a Forrest committer, Steven Noels, who is
>>driving the effort, and hasalready made available equipement.
>>He proposes to host this effort with his company's equipement.
>>Does Apache think it's possible to host Apache stuff on another server?
>>
>>Thank you in advance.
>>
>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Theodore W. Leung wrote:
> This sounds very much like a subproject to me. Can you explain why you
> think this isn't just a subproject?
- It depends very strongly on Cocoon.
- The code it starts with will, have parts come out of Cocoon.
- We would want the Cocoon committers have automatic karma to it.
- Other subprojects already have a similar this arrangement, albeit on
the sister project Jakarta, like Lucene, Avalon, Turbine.
- It doesn't have a project goal, but is more a repository of Cocoon
apps, a sort of Cocoon-Commons.
On the other hand it would seem to be another subproject, since there
would be a different community round it, but this has also happened with
the cocoon-docs mailing list without creating a Cocoon-docs subproject.
Besides we would probably still want to use the Cocoon-dev and
Cocoon-user lists for it, at least in the early stages.
Basically we are thinking about a Cocoon subproject, versus the fact
that the norm is to have Xml.Apache Sub-Projects.
Can it be arranged?
> On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>Ok, can someone of the PMC clarify this.
>>>
>>>We should not use the cocoon cvs for cocoon-apps, so a
>>>separate cvs is the way to go. I don't want to give all
>>>'cocoon-apps' committers also access to cocoon itself.
>>>So it must be separated.
>>
>>Dear PMC, we need your assistance.
>>
>>Cocoon is gaining more "sample" applications every day, and more are
>>being proposed.
>>
>>We are in the process of cleaning the repository by separating the core,
>>the implementation and the components in different directories.
>>We also need to remove those apps that are not part of Cocoon itself but
>>that are important to us and to the community.
>>Therefore, a consensus is forming towards the creation of a new CVS
>>module for cocoon-apps.
>>
>>The reason why I contact you is that this would not be a completely
>>separate project itself, since we want the Cocoon committers to be able
>>to commit, while having the possibility of voting in committers that do
>>not commit to Cocoon.
>>A kind of young-sister project.
>>
>>Now, this is not a subproject, but not really still Cocoon.
>>What is it? How can it be arranged?
>>Lucene has a similar arrangement IIUC...
>>
>>Also, we had the proposal of a Forrest committer, Steven Noels, who is
>>driving the effort, and hasalready made available equipement.
>>He proposes to host this effort with his company's equipement.
>>Does Apache think it's possible to host Apache stuff on another server?
>>
>>Thank you in advance.
>>
>>
>>--
>>Nicola Ken Barozzi nicolaken@apache.org
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Theodore W. Leung" <tw...@sauria.com>.
This sounds very much like a subproject to me. Can you explain why you
think this isn't just a subproject?
Ted
On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> > Ok, can someone of the PMC clarify this.
> >
> > We should not use the cocoon cvs for cocoon-apps, so a
> > separate cvs is the way to go. I don't want to give all
> > 'cocoon-apps' committers also access to cocoon itself.
> > So it must be separated.
>
> Dear PMC, we need your assistance.
>
> Cocoon is gaining more "sample" applications every day, and more are
> being proposed.
>
> We are in the process of cleaning the repository by separating the core,
> the implementation and the components in different directories.
> We also need to remove those apps that are not part of Cocoon itself but
> that are important to us and to the community.
> Therefore, a consensus is forming towards the creation of a new CVS
> module for cocoon-apps.
>
> The reason why I contact you is that this would not be a completely
> separate project itself, since we want the Cocoon committers to be able
> to commit, while having the possibility of voting in committers that do
> not commit to Cocoon.
> A kind of young-sister project.
>
> Now, this is not a subproject, but not really still Cocoon.
> What is it? How can it be arranged?
> Lucene has a similar arrangement IIUC...
>
> Also, we had the proposal of a Forrest committer, Steven Noels, who is
> driving the effort, and hasalready made available equipement.
> He proposes to host this effort with his company's equipement.
> Does Apache think it's possible to host Apache stuff on another server?
>
> Thank you in advance.
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Theodore W. Leung" <tw...@sauria.com>.
This sounds very much like a subproject to me. Can you explain why you
think this isn't just a subproject?
Ted
On Thu, 2002-08-08 at 07:09, Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> > Ok, can someone of the PMC clarify this.
> >
> > We should not use the cocoon cvs for cocoon-apps, so a
> > separate cvs is the way to go. I don't want to give all
> > 'cocoon-apps' committers also access to cocoon itself.
> > So it must be separated.
>
> Dear PMC, we need your assistance.
>
> Cocoon is gaining more "sample" applications every day, and more are
> being proposed.
>
> We are in the process of cleaning the repository by separating the core,
> the implementation and the components in different directories.
> We also need to remove those apps that are not part of Cocoon itself but
> that are important to us and to the community.
> Therefore, a consensus is forming towards the creation of a new CVS
> module for cocoon-apps.
>
> The reason why I contact you is that this would not be a completely
> separate project itself, since we want the Cocoon committers to be able
> to commit, while having the possibility of voting in committers that do
> not commit to Cocoon.
> A kind of young-sister project.
>
> Now, this is not a subproject, but not really still Cocoon.
> What is it? How can it be arranged?
> Lucene has a similar arrangement IIUC...
>
> Also, we had the proposal of a Forrest committer, Steven Noels, who is
> driving the effort, and hasalready made available equipement.
> He proposes to host this effort with his company's equipement.
> Does Apache think it's possible to host Apache stuff on another server?
>
> Thank you in advance.
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Ok, can someone of the PMC clarify this.
>
> We should not use the cocoon cvs for cocoon-apps, so a
> separate cvs is the way to go. I don't want to give all
> 'cocoon-apps' committers also access to cocoon itself.
> So it must be separated.
Dear PMC, we need your assistance.
Cocoon is gaining more "sample" applications every day, and more are
being proposed.
We are in the process of cleaning the repository by separating the core,
the implementation and the components in different directories.
We also need to remove those apps that are not part of Cocoon itself but
that are important to us and to the community.
Therefore, a consensus is forming towards the creation of a new CVS
module for cocoon-apps.
The reason why I contact you is that this would not be a completely
separate project itself, since we want the Cocoon committers to be able
to commit, while having the possibility of voting in committers that do
not commit to Cocoon.
A kind of young-sister project.
Now, this is not a subproject, but not really still Cocoon.
What is it? How can it be arranged?
Lucene has a similar arrangement IIUC...
Also, we had the proposal of a Forrest committer, Steven Noels, who is
driving the effort, and hasalready made available equipement.
He proposes to host this effort with his company's equipement.
Does Apache think it's possible to host Apache stuff on another server?
Thank you in advance.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Carsten Ziegeler wrote:
>Ok, can someone of the PMC clarify this.
>
>We should not use the cocoon cvs for cocoon-apps, so a
>separate cvs is the way to go. I don't want to give all
>'cocoon-apps' committers also access to cocoon itself.
>So it must be separated.
>
>
Exactly. Jakarta-lucene is ALREADY doing this with lucene-scratchpad.
(it actually
serves the same purpose as cocon-apps rather than a general scratchpad).
committers
to the lucene-scratchpad are NOT committers to Lucene (necessarily)
>I think currently, the easiest solution is to start
>a project on sourceforge etc.
>
>
-1 - that would defeat the objective
-Andy
>Carsten
>
>
>
>>-----Original Message-----
>>From: Steven Noels [mailto:stevenn@outerthought.org]
>>Sent: Thursday, August 08, 2002 2:43 PM
>>To: cocoon-dev@xml.apache.org
>>Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>>
>>
>>Andrew C. Oliver wrote:
>>
>>
>>
>>>I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
>>>cocoon-apps. Which is for sample applications
>>>using cocoon. The bar for giving people commit access would be lower
>>>than the core. The main purpose would be
>>>to encourage folks to write example apps. Such usage example would be
>>>REALLY useful to me.
>>>
>>>
>>Please remember that you will need to provide *every* cocoon-app
>>committer with commit rights for that module. From
>>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&c
>>ontent-type=text/vnd.viewcvs-markup,
>>I gather it will be pretty debatable whether we want this or not.
>>
>>Warning: I'm not being the Apache commit status elitist here (I'm just a
>>neighbourhood Forrest committer anyhow), but I believe cocoon-apps
>>should be regarded as an xml.apache.org subproject, *or* that the PMC
>>should come up with a solution.
>>
>>Anyway, I shouldn't be posting anymore since I want to go home early
>>today, and I'll be off-list for two weeks anyhow. Just make sure that we
>>are able to live with the consequences of our decisions. We already have
>>a Hall of Fame of considerable weight
>>(http://xml.apache.org/cocoon/who.html), not sure whether we want to
>>open up the gates for *everybody* who comes up with some Cocoon-based
>>app. Even so, there should be rules laid out - *prior* to moving forward.
>>
>></Steven>
>>--
>>Steven Noels http://outerthought.org/
>>Outerthought - Open Source, Java & XML Competence Support Center
>>stevenn@outerthought.org stevenn@apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Ok, can someone of the PMC clarify this.
>
> We should not use the cocoon cvs for cocoon-apps, so a
> separate cvs is the way to go. I don't want to give all
> 'cocoon-apps' committers also access to cocoon itself.
> So it must be separated.
Dear PMC, we need your assistance.
Cocoon is gaining more "sample" applications every day, and more are
being proposed.
We are in the process of cleaning the repository by separating the core,
the implementation and the components in different directories.
We also need to remove those apps that are not part of Cocoon itself but
that are important to us and to the community.
Therefore, a consensus is forming towards the creation of a new CVS
module for cocoon-apps.
The reason why I contact you is that this would not be a completely
separate project itself, since we want the Cocoon committers to be able
to commit, while having the possibility of voting in committers that do
not commit to Cocoon.
A kind of young-sister project.
Now, this is not a subproject, but not really still Cocoon.
What is it? How can it be arranged?
Lucene has a similar arrangement IIUC...
Also, we had the proposal of a Forrest committer, Steven Noels, who is
driving the effort, and hasalready made available equipement.
He proposes to host this effort with his company's equipement.
Does Apache think it's possible to host Apache stuff on another server?
Thank you in advance.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [PROPOSAL] Cocoon-apps CVS module
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, can someone of the PMC clarify this.
We should not use the cocoon cvs for cocoon-apps, so a
separate cvs is the way to go. I don't want to give all
'cocoon-apps' committers also access to cocoon itself.
So it must be separated.
I think currently, the easiest solution is to start
a project on sourceforge etc.
Carsten
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Thursday, August 08, 2002 2:43 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [PROPOSAL] Cocoon-apps CVS module
>
>
> Andrew C. Oliver wrote:
>
> > I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
> > cocoon-apps. Which is for sample applications
> > using cocoon. The bar for giving people commit access would be lower
> > than the core. The main purpose would be
> > to encourage folks to write example apps. Such usage example would be
> > REALLY useful to me.
>
> Please remember that you will need to provide *every* cocoon-app
> committer with commit rights for that module. From
> http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&c
> ontent-type=text/vnd.viewcvs-markup,
> I gather it will be pretty debatable whether we want this or not.
>
> Warning: I'm not being the Apache commit status elitist here (I'm just a
> neighbourhood Forrest committer anyhow), but I believe cocoon-apps
> should be regarded as an xml.apache.org subproject, *or* that the PMC
> should come up with a solution.
>
> Anyway, I shouldn't be posting anymore since I want to go home early
> today, and I'll be off-list for two weeks anyhow. Just make sure that we
> are able to live with the consequences of our decisions. We already have
> a Hall of Fame of considerable weight
> (http://xml.apache.org/cocoon/who.html), not sure whether we want to
> open up the gates for *everybody* who comes up with some Cocoon-based
> app. Even so, there should be rules laid out - *prior* to moving forward.
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> stevenn@outerthought.org stevenn@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Cocoon-apps CVS module
Posted by Steven Noels <st...@outerthought.org>.
Andrew C. Oliver wrote:
> I'd like to see a seperate CVS module (irrelevant of Cocoblog) for
> cocoon-apps. Which is for sample applications
> using cocoon. The bar for giving people commit access would be lower
> than the core. The main purpose would be
> to encourage folks to write example apps. Such usage example would be
> REALLY useful to me.
Please remember that you will need to provide *every* cocoon-app
committer with commit rights for that module. From
http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup,
I gather it will be pretty debatable whether we want this or not.
Warning: I'm not being the Apache commit status elitist here (I'm just a
neighbourhood Forrest committer anyhow), but I believe cocoon-apps
should be regarded as an xml.apache.org subproject, *or* that the PMC
should come up with a solution.
Anyway, I shouldn't be posting anymore since I want to go home early
today, and I'll be off-list for two weeks anyhow. Just make sure that we
are able to live with the consequences of our decisions. We already have
a Hall of Fame of considerable weight
(http://xml.apache.org/cocoon/who.html), not sure whether we want to
open up the gates for *everybody* who comes up with some Cocoon-based
app. Even so, there should be rules laid out - *prior* to moving forward.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org