Re: building trunk
Jorg Heymans wrote:
Reinhard Poetz wrote:
Do we need any svn:externals in trunk? I don't think they are
required.
The archetype svn:external links to the static data from the cocoon webapp.
If nobody objects, I will remove it.
Please move it back to the whiteboard instead. I still believe
archetypes will become useful for us, but probably not before both
cocoon and maven have stabilized again.
It's not that I think that we don't need archetypes but this
cocoon-archetype-core reflects the "old", monolytic Cocoon and not what we want
to get. It's only that different archetypes will be required as outlined in my
two block deployer tutorials. I will make the first one work very soon and
rewrite the cocoon-archetype-block for this purpose.
Do you still want to keep the cocoon-archetype-core archetype?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [Jobs] MORE Cocoon / XSLT People Needed !
> Agile Partners is growing yet again ... > > About 80% of our work revolves around Cocoon. We're based in the U.S., and > our current projects are in the New York City / New Jersey area. We're > looking to add one or more full-time contractors with Cocoon / XSLT / > CForms / Ajax skills Sorry, I neglected the obvious, Java -- we need both back-end and front-end skill sets -- though not necessarily in the same person ;-). >, see http://www.agilepartners.com/about/jobs.html for > more info. While we'd entertain remote contracting, living in the New > York City / New Jersey / Philadelphia area is a major plus. > > If you are interested, just drop us an e-mail: [EMAIL PROTECTED] > > Thanks everyone -- > > Jack Ivers > http://www.agilepartners.com > > >
[Jobs] MORE Cocoon / XSLT People Needed !
Agile Partners is growing yet again ... About 80% of our work revolves around Cocoon. We're based in the U.S., and our current projects are in the New York City / New Jersey area. We're looking to add one or more full-time contractors with Cocoon / XSLT / CForms / Ajax skills, see http://www.agilepartners.com/about/jobs.html for more info. While we'd entertain remote contracting, living in the New York City / New Jersey / Philadelphia area is a major plus. If you are interested, just drop us an e-mail: [EMAIL PROTECTED] Thanks everyone -- Jack Ivers http://www.agilepartners.com
Re: building trunk
Are you trying to tell me that it isn't needed and it should be removed? Jorg Heymans said: > > Ralph Goers wrote: > >> [INFO] Failed to resolve artifact. >> >> GroupId: org.apache.cocoon >> ArtifactId: cocoon-plugins >> Version: 1.0-SNAPSHOT >> > > cocoon-plugins is the parent pom of cocoon-deployer-minimal-webapp. It's > not referenced from any other pom so i guess this is a leftover of the > latest module relocations. > > Jorg > >
Re: building trunk
Reinhard Poetz wrote: > Do we need any svn:externals in trunk? I don't think they are > required. The archetype svn:external links to the static data from the cocoon webapp. > If nobody objects, I will remove it. Please move it back to the whiteboard instead. I still believe archetypes will become useful for us, but probably not before both cocoon and maven have stabilized again. Thanks Jorg
Re: building trunk
Ralph Goers wrote: > [INFO] Failed to resolve artifact. > > GroupId: org.apache.cocoon > ArtifactId: cocoon-plugins > Version: 1.0-SNAPSHOT > cocoon-plugins is the parent pom of cocoon-deployer-minimal-webapp. It's not referenced from any other pom so i guess this is a leftover of the latest module relocations. Jorg
Re: building trunk
OK. Under the assumption that I don't need that I reran it again. Here is the output. rago2483[/projects/cocoon/trunk] export MAVEN_HOME=/opt/maven-2.0.2/ rago2483[/projects/cocoon/trunk] export PATH=/opt/maven-2.0.2/bin:$PATH rago2483[/projects/cocoon/trunk] export MAVEN_HOME_LOCAL=/projects/cocoon/trunk/.maven rago2483[/projects/cocoon/trunk] mvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-plugins Version: 1.0-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-plugins:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: POM 'org.apache.cocoon:cocoon-plugins' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon-plugins:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon-plugins' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon-plugins:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:429) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:986) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:593) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:303) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:274) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon-plugins:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:136) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:386) ... 20 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:260) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) ... 22 more [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Mon Feb 06 10:07:25 PST 2006 [INFO] Final Memory: 1M/3M [INFO] Reinhard Poetz said: > Ralph Goers wrote: >> Well darn. I tried to check out trunk at work so I could recreate the >> log, >> but I can't get a successful checkout. At work I am behind a firewall >> and >> checkouts only work when using https. Can s
Re: building trunk
Ralph Goers wrote:
Well darn. I tried to check out trunk at work so I could recreate the log,
but I can't get a successful checkout. At work I am behind a firewall and
checkouts only work when using https. Can somebody fix this - or tell me
how?
Fetching external item into
'trunk/cocoon-archetypes/cocoon-archetype-core/src/main/resources/archetype-resources/src/main/webapp'
svn: PROPFIND request failed on
'/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp'
svn: PROPFIND of '/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp':
501 Not Implemented (http://svn.apache.org)
Do we need any svn:externals in trunk? I don't think they are required. The
cocoon-archetype-core module can be removed (IMO) anyway as this will not be the
way how to start a Cocoon 2.2 (3.0) project.
If nobody objects, I will remove it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: building trunk
Well darn. I tried to check out trunk at work so I could recreate the log,
but I can't get a successful checkout. At work I am behind a firewall and
checkouts only work when using https. Can somebody fix this - or tell me
how?
Fetching external item into
'trunk/cocoon-archetypes/cocoon-archetype-core/src/main/resources/archetype-resources/src/main/webapp'
svn: PROPFIND request failed on
'/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp'
svn: PROPFIND of '/repos/asf/cocoon/trunk/cocoon-webapp/src/main/webapp':
501 Not Implemented (http://svn.apache.org)
Reinhard Poetz said:
> Ralph Goers wrote:
>> Sorry. The commands below should be "mvn" and "mvn install".
>>
>> Ralph Goers wrote:
>>
>>> I am trying to build trunk. First I got the latest from svn.
>>>
>>> I tried must doing "maven" and "maven install" but I get a failure
>>> saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT
>>> cannot be found in the repository and can't be located in any
>>> repository. What do I need to do? INSTALL.txt still says to use
>>> build.sh which I know is wrong.
>
> cocoon-plugins was removed by me a couple of days ago. Can you provide
> more
> information (stacktrace, which module is failing, ...)?
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
>
>
>
>
>
>
> ___
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
Re: error while building trunk
* Doug Chestnut: > Hi simon, just noticed this as well. This should fix it: > > -verbose = Boolean.parseBoolean(verboseProperty); > +verbose = Boolean.valueOf(verboseProperty).booleanValue(); Mea culpa, Indeed parseBoolean is only available in JDK 1.5. I committed your fix, thanks! -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: error while building trunk
thanks doug.
On Mon, 2006-02-06 at 10:53 -0500, Doug Chestnut wrote:
> Hi simon, just noticed this as well. This should fix it:
>
> Index: C:/src/cocoon-2.1.x/tools/src/loader/Loader.java
> ===
> --- C:/src/cocoon-2.1.x/tools/src/loader/Loader.java (revision 375296)
> +++ C:/src/cocoon-2.1.x/tools/src/loader/Loader.java (working copy)
> @@ -89,7 +89,7 @@
>
> String verboseProperty = System.getProperty(VERBOSE_PROPERTY);
> if (verboseProperty != null)
> -verbose = Boolean.parseBoolean(verboseProperty);
> +verbose = Boolean.valueOf(verboseProperty).booleanValue();
> String classPath = System.getProperty(CLASSPATH_PROPERTY);
>
> if (verbose) System.out.println(" Loading
> ");
>
>
> simon wrote:
> > hi devs
> >
> > i checked out cocoon 2.1.x and get following build error.
> >
> > init-tasks:
> > Created dir: /home/simon/src/cocoon-2.1.x-test/tools/anttasks
> > Compiling 5 source files
> > to /home/simon/src/cocoon-2.1.x-test/tools/anttasks
> > Created dir: /home/simon/src/cocoon-2.1.x-test/tools/loader
> > Compiling 1 source file
> > to /home/simon/src/cocoon-2.1.x-test/tools/loader
> > /home/simon/src/cocoon-2.1.x-test/tools/src/loader/Loader.java:92:
> > cannot resolve symbol
> > symbol : method parseBoolean (java.lang.String)
> > location: class java.lang.Boolean
> > verbose = Boolean.parseBoolean(verboseProperty);
> > ^
> > 1 error
> >
> > BUILD FAILED
> >
> > is this my fault?
> >
> > simon
> >
>
--
Simon Litwan [EMAIL PROTECTED]
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
Re: building trunk
Ralph Goers wrote:
Sorry. The commands below should be "mvn" and "mvn install".
Ralph Goers wrote:
I am trying to build trunk. First I got the latest from svn.
I tried must doing "maven" and "maven install" but I get a failure
saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT
cannot be found in the repository and can't be located in any
repository. What do I need to do? INSTALL.txt still says to use
build.sh which I know is wrong.
cocoon-plugins was removed by me a couple of days ago. Can you provide more
information (stacktrace, which module is failing, ...)?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: error while building trunk
Hi simon, just noticed this as well. This should fix it:
Index: C:/src/cocoon-2.1.x/tools/src/loader/Loader.java
===
--- C:/src/cocoon-2.1.x/tools/src/loader/Loader.java(revision 375296)
+++ C:/src/cocoon-2.1.x/tools/src/loader/Loader.java(working copy)
@@ -89,7 +89,7 @@
String verboseProperty = System.getProperty(VERBOSE_PROPERTY);
if (verboseProperty != null)
-verbose = Boolean.parseBoolean(verboseProperty);
+verbose = Boolean.valueOf(verboseProperty).booleanValue();
String classPath = System.getProperty(CLASSPATH_PROPERTY);
if (verbose) System.out.println(" Loading
");
simon wrote:
hi devs
i checked out cocoon 2.1.x and get following build error.
init-tasks:
Created dir: /home/simon/src/cocoon-2.1.x-test/tools/anttasks
Compiling 5 source files
to /home/simon/src/cocoon-2.1.x-test/tools/anttasks
Created dir: /home/simon/src/cocoon-2.1.x-test/tools/loader
Compiling 1 source file
to /home/simon/src/cocoon-2.1.x-test/tools/loader
/home/simon/src/cocoon-2.1.x-test/tools/src/loader/Loader.java:92:
cannot resolve symbol
symbol : method parseBoolean (java.lang.String)
location: class java.lang.Boolean
verbose = Boolean.parseBoolean(verboseProperty);
^
1 error
BUILD FAILED
is this my fault?
simon
error while building trunk
hi devs i checked out cocoon 2.1.x and get following build error. init-tasks: Created dir: /home/simon/src/cocoon-2.1.x-test/tools/anttasks Compiling 5 source files to /home/simon/src/cocoon-2.1.x-test/tools/anttasks Created dir: /home/simon/src/cocoon-2.1.x-test/tools/loader Compiling 1 source file to /home/simon/src/cocoon-2.1.x-test/tools/loader /home/simon/src/cocoon-2.1.x-test/tools/src/loader/Loader.java:92: cannot resolve symbol symbol : method parseBoolean (java.lang.String) location: class java.lang.Boolean verbose = Boolean.parseBoolean(verboseProperty); ^ 1 error BUILD FAILED is this my fault? simon -- Simon Litwan [EMAIL PROTECTED] Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org
Re: building trunk
Ralph Goers schrieb: > I am trying to build trunk. First I got the latest from svn. > > I tried must doing "maven" and "maven install" but I get a failure > saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT cannot > be found in the repository and can't be located in any repository. What > do I need to do? INSTALL.txt still says to use build.sh which I know is > wrong. > Don't know what the correct way is (didn't try it for weeks) but have you really used "maven" and not "mvn"? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: building trunk
Sorry. The commands below should be "mvn" and "mvn install". Ralph Goers wrote: I am trying to build trunk. First I got the latest from svn. I tried must doing "maven" and "maven install" but I get a failure saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT cannot be found in the repository and can't be located in any repository. What do I need to do? INSTALL.txt still says to use build.sh which I know is wrong. Ralph
building trunk
I am trying to build trunk. First I got the latest from svn. I tried must doing "maven" and "maven install" but I get a failure saying that org.apache.cocoon:cocoon-plugins version 1.0-SNAPSHOT cannot be found in the repository and can't be located in any repository. What do I need to do? INSTALL.txt still says to use build.sh which I know is wrong. Ralph
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 56 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A "jcr:" protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-06022006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-06022006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-06022006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-06022006.jar -Dbuild=build/cocoon-06022006 gump-core [Working Directory: /usr/local/gump/public/workspace
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 56 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A "jcr:" protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-06022006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-06022006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-06022006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-06022006.jar -Dbuild=build/cocoon-06022006 gump-core [Working Directory: /usr/local/gump/public/workspace
Re: Global component registry
Reinhard Poetz wrote: Daniel Fagerstrom wrote: Reinhard Poetz wrote: Daniel Fagerstrom wrote: This requires a component declarations with explicit dependencies. Unfortunately ECM doesn't support this at all as it is based on getting the dependencies through the service manager in the program code. But OSGi declarative services support declarative component dependencies e.g. Unfortunatly the OSGi spec doesn't say much about declarative services. Did I overlook them or do you know of any source of information that is more helpful (e.g. show some examples)? They are new in R4 and part of the services specification (the R4 is split into a core and a service specification). The specification contains some examples, other than that I haven't found any examples. There are two open source implementations, the reference implementation from IBM that now is part of Eclipse/Equinox and one from Knopflerfish. In the meantime I found http://oscar-osgi.sourceforge.net/tutorial/ex7.html and http://gravity.sourceforge.net/servicebinder/ It is similar but not exactly the same. The declarative services is a development of the service binder. But IIUC, they are rather close, so it is probably a good starting point to read about the service binder. Standard documents are not that easy going ;) even if the OSGi ones are well written. I succeed to make a minimal example running in the Equinox framework. I'll start an experimental integration in Cocoon soon. The main problem is how to make all the dependencies bundles. The correct way, is to make all the jars bundles separately, but that is a lot of work, and we need to cooperate with other communities to be able to maintain it. This has been discussed at the Felix list, and there are some interest e.g. for Excalibur. But someone have to take the first step. The other option is to package all dependent jars inside the Cocoon-core bundle, but that makes startup slow, and I don't know how to maintain two separate packaging of Core with Maven. Maven knows the concept of "profiles" that are helpful to use different build strategies Ok, will take a look at that. /Daniel
[jira] Closed: (COCOON-1715) [PATCH] Allow ContinuationsManagerImpl to run in CLI
[ http://issues.apache.org/jira/browse/COCOON-1715?page=all ] Jean-Baptiste Quenot closed COCOON-1715: Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed Fixed in 2.1. Loader now recognizes two additional system properties: * loader.verbose * loader.class.path > [PATCH] Allow ContinuationsManagerImpl to run in CLI > > > Key: COCOON-1715 > URL: http://issues.apache.org/jira/browse/COCOON-1715 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.9-dev (current SVN) > Reporter: Jean-Baptiste Quenot > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > Attachments: 20051216-continuationsmanager, contierror > > Build Cocoon without any block. > When starting Cocoon with "cocoon.sh cli" there is an error: > NoClassDefFoundError javax/servlet/http/HttpSessionBindingListener, see error > log attached. The attached patch fixes this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Global component registry
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on
getting the dependencies through the service manager in the program
code. But OSGi declarative services support declarative component
dependencies e.g.
Unfortunatly the OSGi spec doesn't say much about declarative
services. Did I overlook them or do you know of any source of
information that is more helpful (e.g. show some examples)?
They are new in R4 and part of the services specification (the R4 is
split into a core and a service specification). The specification
contains some examples, other than that I haven't found any examples.
There are two open source implementations, the reference implementation
from IBM that now is part of Eclipse/Equinox and one from Knopflerfish.
In the meantime I found http://oscar-osgi.sourceforge.net/tutorial/ex7.html and
http://gravity.sourceforge.net/servicebinder/
I succeed to make a minimal example running in the Equinox framework.
I'll start an experimental integration in Cocoon soon. The main problem
is how to make all the dependencies bundles. The correct way, is to make
all the jars bundles separately, but that is a lot of work, and we need
to cooperate with other communities to be able to maintain it. This has
been discussed at the Felix list, and there are some interest e.g. for
Excalibur. But someone have to take the first step.
The other option is to package all dependent jars inside the Cocoon-core
bundle, but that makes startup slow, and I don't know how to maintain
two separate packaging of Core with Maven.
Maven knows the concept of "profiles" that are helpful to use different build
strategies
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Closed: (COCOON-1681) Generator "directory": Caching too much
[ http://issues.apache.org/jira/browse/COCOON-1681?page=all ] Jean-Baptiste Quenot closed COCOON-1681: Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Committed, thanks! See http://svn.apache.org/viewcvs.cgi?rev=375255&view=rev > Generator "directory": Caching too much > --- > > Key: COCOON-1681 > URL: http://issues.apache.org/jira/browse/COCOON-1681 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8, 2.1.7 > Reporter: Antonio Fiol > Assignee: Jean-Baptiste Quenot > Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Attachments: DirectoryGenerator.java.patch, stack1, stack2, stack3 > > In some cases, an update to the directory is not detected by the > DirectoryGenerator. > Debugging the issue, I discovered that isValid() is called twice on the same > DirValidity, but it returns different values (-1 the first time, 1 the second > time). > Apparently, the reason for the inconsistency would be solved by removing the > first of the two lines that update the expiry time in the isValid() method in > DirValidity, but I am not sure whether this could cause problems in other > places. > A possibility would be that a DirValidity stores the fact that it already > detected it is invalid, and is changed so that it always return -1. But... > Are DirValidity objects reused? Could this change cause problems? I have not > tested, so I don't know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: making pipelines wait for each other
> -Original Message- > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > Sent: Monday, February 06, 2006 12:06 > To: dev@cocoon.apache.org > Subject: Re: making pipelines wait for each other > > > Le 6 févr. 06, à 10:44, Max Pfingsthorn a écrit : > > > ...We see that if a second request for exactly the same > pipeline comes > > in before the first request is done, it takes again as long because > > the first pipeline did not put its result in the cache yet > and it is > > recomputed. This is quite obvious, but hurts our > performance a lot... > > FYI, a while ago I had some performance issues and I was > wondering what > happens if you're using a front-end cache (mod_cache, Squid or > something): do these caches optimize simultaneous requests by making > all but one wait until the first response is generated? > > In the end my issues where much more stupid than that (some > pages were > not stored in the front-end cache due to incorrect headers), so I > didn't analyze in detail and don't have the answer. > > From your analysis it sounds like what you're seeing is really > Cocoon-specific, but I thought I'd share my questioning, in > case you're > using a front-end cache as well. Yes, we are using squid in front of cocoon, but we are seeing the same problem anyway. It doesn't seem like squid has any options to configure this kind of behaviour... Bye! max
[jira] Closed: (COCOON-1238) Improvements for CustomJXPathBinding
[ http://issues.apache.org/jira/browse/COCOON-1238?page=all ] Jean-Baptiste Quenot closed COCOON-1238: Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Committed, thanks! See http://svn.apache.org/viewcvs.cgi?view=rev&rev=375253 > Improvements for CustomJXPathBinding > > > Key: COCOON-1238 > URL: http://issues.apache.org/jira/browse/COCOON-1238 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms > Versions: 2.1.5 > Environment: Operating System: All > Platform: All > Reporter: Bart Molenkamp > Assignee: Jean-Baptiste Quenot > Priority: Minor > Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Attachments: 20060201-cocoon-forms-1238, AbstractCustomBinding.java.patch, > CustomJXPathBinding.java.patch, CustomJXPathBindingBuilder.java, > CustomJXPathBindingBuilder.java.patch > > 2 improvements: > 1. Custom bindings get a service manager when they implement Serviceable. > 2. Relative JXPath context is not created. Instead, the current context, and > the > xpath query are passed to the custom binding. This allows bindings to set > values > for objects that are null (whereas a getRelativeContext() will throw an > exception). Custom bindings now can do a > context.createPathAndSetValue(getXpath(), ...) to set a value that was null > before setting it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: making pipelines wait for each other
> I think this topic has been discussed several times, so you might want > to search through the archives to see what others did say about it. I had a look and the only thing I found was a conversation in the beginning of 2004 about eventcaching and the CachedSource [1]. Unico started it back then, but it was about asynchronously recreating sources instead of making pipelines wait if another is already recreating the same content. I think I will try the approach I outlined before and see what happens :) Bye! max [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107822781408011&w=2
Re: Global component registry
Reinhard Poetz wrote: Daniel Fagerstrom wrote: This requires a component declarations with explicit dependencies. Unfortunately ECM doesn't support this at all as it is based on getting the dependencies through the service manager in the program code. But OSGi declarative services support declarative component dependencies e.g. Unfortunatly the OSGi spec doesn't say much about declarative services. Did I overlook them or do you know of any source of information that is more helpful (e.g. show some examples)? They are new in R4 and part of the services specification (the R4 is split into a core and a service specification). The specification contains some examples, other than that I haven't found any examples. There are two open source implementations, the reference implementation from IBM that now is part of Eclipse/Equinox and one from Knopflerfish. I succeed to make a minimal example running in the Equinox framework. I'll start an experimental integration in Cocoon soon. The main problem is how to make all the dependencies bundles. The correct way, is to make all the jars bundles separately, but that is a lot of work, and we need to cooperate with other communities to be able to maintain it. This has been discussed at the Felix list, and there are some interest e.g. for Excalibur. But someone have to take the first step. The other option is to package all dependent jars inside the Cocoon-core bundle, but that makes startup slow, and I don't know how to maintain two separate packaging of Core with Maven. /Daniel
Re: making pipelines wait for each other
Le 6 févr. 06, à 10:44, Max Pfingsthorn a écrit : ...We see that if a second request for exactly the same pipeline comes in before the first request is done, it takes again as long because the first pipeline did not put its result in the cache yet and it is recomputed. This is quite obvious, but hurts our performance a lot... FYI, a while ago I had some performance issues and I was wondering what happens if you're using a front-end cache (mod_cache, Squid or something): do these caches optimize simultaneous requests by making all but one wait until the first response is generated? In the end my issues where much more stupid than that (some pages were not stored in the front-end cache due to incorrect headers), so I didn't analyze in detail and don't have the answer. From your analysis it sounds like what you're seeing is really Cocoon-specific, but I thought I'd share my questioning, in case you're using a front-end cache as well. -Bertrand smime.p7s Description: S/MIME cryptographic signature
New imageop block in 2.1
About the [1]imageop contribution, could someone explain how I can add a block in Cocoon 2.1? Does it involve adding the new block in gump.xml? Does the build depend on gump.xml directly, or is there an intermediate step required? Please find attached the current patch against gump.xml. Thanks in advance, -- Jean-Baptiste Quenot http://caraldi.com/jbq/ [1] http://issues.apache.org/jira/browse/COCOON-1301 Index: gump.xml === --- gump.xml(revision 369409) +++ gump.xml(working copy) @@ -1663,6 +1663,27 @@ + + +org.apache.cocoon + +ImageOp - Image Operations + + + + + + + + + + + + + + + +
RE: making pipelines wait for each other
> -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Monday, February 06, 2006 11:35 > To: dev@cocoon.apache.org > Subject: Re: making pipelines wait for each other > > Max Pfingsthorn wrote: > > Hello! > > ... > > > > WDYT? Would that solve it? Is there a better way? > > > I think this topic has been discussed several times, so you might want > to search through the archives to see what others did say about it. > > We usually solve this problem by pre-caching, so before the first real > user can invoke the pipeline, we already invoked it (using cron etc.) > and therefore the content is always cached. Yes, that is one solution, but we have dynamic content, and a vast range of possible http requests, so we can't precompute everything. Additionally, when content changes while cocoon is running, it is still possible to get this effect while the background task refreshes the cache... Unless we do some double buffering, i.e. keep the previous cachedresponse valid while we recreate the content. I'll have another look through the archive before I take some steps to solve this. max
Re: making pipelines wait for each other
Max Pfingsthorn wrote: > Hello! > > I am not sure what has been done about this so far, but we are still > experiencing some not-so-great behavior from the CachingPipeline: > We have some pipelines which take a long time to complete processing, like > generating a homepage from many different sources. We see that if a second > request for exactly the same pipeline comes in before the first request is > done, it takes again as long because the first pipeline did not put its > result in the cache yet and it is recomputed. This is quite obvious, but > hurts our performance a lot. > > I was thinking that we might implement some thread synchronization by sharing > some objects and calling wait() and notify() on them. > > First I thought putting an empty CachedResponse into the Cache when we start > generating the data. Any pipeline trying to access that CachedResponse will > notice that it is empty and call wait() on it. As soon as the first pipeline > is done saving its content to the cache, it calls notify(). Then I remembered > that the Cache puts these on disk, and I am not sure what happens to the > locks when an object is serialized... > So, what about doing the same with a store instead? We push an empty response > into a store, preferrably a transient, in-memory one without size limits, and > do the same as I outlined above. > > WDYT? Would that solve it? Is there a better way? > I think this topic has been discussed several times, so you might want to search through the archives to see what others did say about it. We usually solve this problem by pre-caching, so before the first real user can invoke the pipeline, we already invoked it (using cron etc.) and therefore the content is always cached. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1681) Generator "directory": Caching too much
[ http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12365255 ] Jean-Baptiste Quenot commented on COCOON-1681: -- Apparently, what is causing the two isValid() invocations is that you use along with a cocoon: URL. The latter is handled by SitemapSource which is known to call the pipeline twice, one time for getting the validity, and another time for retrieving pipeline result. So yes, we need to have a consistent way of handling isValid() in DirectoryGenerator. Checking lastModified() twice is not a big problem provided that this check is only performed when all of the following conditions are met: 1) the expiry time has been reached 2) a file was removed or modified > Generator "directory": Caching too much > --- > > Key: COCOON-1681 > URL: http://issues.apache.org/jira/browse/COCOON-1681 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8, 2.1.7 > Reporter: Antonio Fiol > Assignee: Jean-Baptiste Quenot > Attachments: DirectoryGenerator.java.patch, stack1, stack2, stack3 > > In some cases, an update to the directory is not detected by the > DirectoryGenerator. > Debugging the issue, I discovered that isValid() is called twice on the same > DirValidity, but it returns different values (-1 the first time, 1 the second > time). > Apparently, the reason for the inconsistency would be solved by removing the > first of the two lines that update the expiry time in the isValid() method in > DirValidity, but I am not sure whether this could cause problems in other > places. > A possibility would be that a DirValidity stores the fact that it already > detected it is invalid, and is changed so that it always return -1. But... > Are DirValidity objects reused? Could this change cause problems? I have not > tested, so I don't know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Allow ContinuationsManagerImpl to run in CLI
Jean-Baptiste Quenot wrote: > Hello, > > About http://issues.apache.org/jira/browse/COCOON-1715 > > What is the best way to deal with this? Add servlet.jar in > the Loader's classpath when running the CLI? Or remove the > continuations-manager from cocoon.xconf by creating a new optional > "flow" block? > > Your feedback will be appreciated. Just add servlet.jar to the CLI's classpath. It won't be soon that it gets the attention it needs to make sure it can work without servlet.jar, and it will make life easy for a lot of CLI users. Upayavira
Re: Global component registry
Daniel Fagerstrom wrote:
This requires a component declarations with explicit dependencies.
Unfortunately ECM doesn't support this at all as it is based on getting
the dependencies through the service manager in the program code. But
OSGi declarative services support declarative component dependencies e.g.
Unfortunatly the OSGi spec doesn't say much about declarative services. Did I
overlook them or do you know of any source of information that is more helpful
(e.g. show some examples)?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: making pipelines wait for each other
* Max Pfingsthorn: > We see that if a second request for exactly the same pipeline > comes in before the first request is done, it takes again as > long because the first pipeline did not put its result in the > cache yet and it is recomputed. Same here. > First I thought putting an empty CachedResponse into the Cache > when we start generating the data. Any pipeline trying to access > that CachedResponse will notice that it is empty and call wait() > on it. I won't comment on the *way* to do it, but I'd be glad if you could do it, because we need that feature. Thanks a lot, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Allow ContinuationsManagerImpl to run in CLI
Hello, About http://issues.apache.org/jira/browse/COCOON-1715 What is the best way to deal with this? Add servlet.jar in the Loader's classpath when running the CLI? Or remove the continuations-manager from cocoon.xconf by creating a new optional "flow" block? Your feedback will be appreciated. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
making pipelines wait for each other
Hello! I am not sure what has been done about this so far, but we are still experiencing some not-so-great behavior from the CachingPipeline: We have some pipelines which take a long time to complete processing, like generating a homepage from many different sources. We see that if a second request for exactly the same pipeline comes in before the first request is done, it takes again as long because the first pipeline did not put its result in the cache yet and it is recomputed. This is quite obvious, but hurts our performance a lot. I was thinking that we might implement some thread synchronization by sharing some objects and calling wait() and notify() on them. First I thought putting an empty CachedResponse into the Cache when we start generating the data. Any pipeline trying to access that CachedResponse will notice that it is empty and call wait() on it. As soon as the first pipeline is done saving its content to the cache, it calls notify(). Then I remembered that the Cache puts these on disk, and I am not sure what happens to the locks when an object is serialized... So, what about doing the same with a store instead? We push an empty response into a store, preferrably a transient, in-memory one without size limits, and do the same as I outlined above. WDYT? Would that solve it? Is there a better way? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
