Re: [Fwd: [proposal] Oscar OSGi Project]
Hmm. The email would lead one to think otherwise... We have established a list for discussions. Unless your comment is directed to the general Incubator community or the Incubator PMC, please post everything to : [EMAIL PROTECTED] You can subscribe by sending an email to [EMAIL PROTECTED] Until this proposal has been accepted by the Apache Incubator PMC, these lists are provisional. Ralph Reinhard Poetz wrote: Ralph Goers wrote: Well, I'm very much in favor of this. Unfortunately, my messages sent to [EMAIL PROTECTED] are failing with no such mailbox. The project has been proposed but not been accepted yet. Therefore no mailing lists yet.
Re: [Fwd: [proposal] Oscar OSGi Project]
Ralph Goers wrote:
Hmm. The email would lead one to think otherwise...
We have established a list for discussions. Unless your comment is
directed
to the general Incubator community or the Incubator PMC, please post
everything to :
[EMAIL PROTECTED]
You can subscribe by sending an email to
[EMAIL PROTECTED]
Until this proposal has been accepted by the Apache Incubator PMC, these
lists
are provisional.
hmmm, have tried it myself without success. I will ask on Incubator about this
issue.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: DirectoryGenerator using abstract Source
Joerg Heinicke wrote: On 14.07.2005 10:59, Gianugo Rabellino wrote: 1. move TraversableGenerator to src/core, +1 +1 deprecate DirectoryGenerator leaving it untouched Read below. 2. insert some log.xxx(DG is now deprecated, please use TG instead), where xxx is promoted from debug to error in a few release cycles 3. optionally start introducing XMLGenerator the same way (though the only path I can foresee is via cp) In any case, avoid extends like the plague. If anything, the hassle we're going to have because of that bunch of generators extending DG should prove how extends can be harmful. Actually, it might be worth thinking about refactoring the whole stuff using composition. Yeah, I know: prefer composition over inheritance. And it might improve the DGs we have. But when we make DG extending TG just for a naming issue I see no advantage in composition and adding so many delegating methods. And why do you want to leave DG untouched at all? Couldn't TG do the same? what implementing the DG XML syntax into TG if the Source is a FileSource? Regarding 3.: +1 for doing it the same way - what ever we will decide. I think the name XMLGenerator is not very clear, although I have to admit as was pointed out that ResourceGenerator is also not very clear. But I think it would make sense to generalize it somehow anyway. btw, I made a note within the javadoc of DirectoryGenerator pointing to the TraversableGenerator Michi Joerg -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DirectoryGenerator using abstract Source
On 7/14/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I don't think it is a good idea to deprecate things that have been
arround in Cocoon from the very beginning and is part of about every
book, tutorial and article that have been written about Cocoon.
I can clearly see your point. Being DG so much part of core Cocoon,
it's tough stuff to handle. However, it's also very clear how much TG
is more flexible: if you consider that a guy like Michi, a Cocoon and
Lenya committer, was unaware of its existence, you'll realize how
we're doing a very bad job in promoting our stuff, and how having
old stuff lying around stops the way to evolution and might become a
maintenance nightmare.
If they where considered harmfull in some way, hard to maintain or was
in the way for developing new important stuff I would agree in
deprecating them. But I don't see that it is the case.
Could well be. DG is solid stuff indeed, much like XSP who have been
there almost forever with little to no need for maintainance.
A much better way to handle old stuff where we have found better ways of
achieving what they are intended for is IMO doing like we did for XSP,
remove it from core and move it to a block.
For the DirectoryGenerator we could have a certain DirectoryGenerator
block, or put it together with some other obsololete stuff that belong
together in some way in a block. Or we could have an
backcompability2.1 block, with everything that we find old fashoned
and want to move away from core.
I like that. It would be a nice way of migrating stuff. However, to
make it happen, we should make sure first that TG does everything DG
and relatives can do (images, Mp3, etc...).
In any case, avoid extends like the plague. If anything, the hassle
we're going to have because of that bunch of generators extending DG
should prove how extends can be harmful.
I don't follow you here, care to expand on it?
It's just the old fart of favoring composition over inheritance. This
stuff (taken from o.a.c.generation.ImageDirectoryGenerator) smells
Fragile Base Class:
protected void setNodeAttributes(File path) throws SAXException {
super.setNodeAttributes(path);
[...]
}
(wherever I see super(), I tend to frown :-)). I'd much rather see a
different pattern based on source descriptors and inspectors, much
like what has been done in the repository block with
InspectableSource, SourceDescriptor and SourceInspector.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
JCR samples added
Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Any feedback is very welcome. Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: JCR samples added
Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? Any help on this is appreciated Michi Carsten -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
[Forms] Protected methods in o.a.c.forms.datatype.typeimpl.AbstractDatatype
Folks, I'm trying to write a custom CForms datatype. I'd have some general considerations about how hard this is, considering the need to patch cocoon.xconf to extend the forms type system, which makes me want to go growing vineyards in the hillsides (do we really need all this Avalon stuff just to configure a set of factories?), but I'll leave that for another thread. Anyway, my problem at the moment is that I started by copying StringType and StringTypeBuilder and trying to modify them for my needs. I also copied them to a package belonging to my application and outside of o.a.c.forms.datatype.typeimpl. This datatype is peculiar to my app and it makes no sense as part of Cocoon. Unfortunately, this breaks StringTypeBuilder (which is now called, say, MyTypeBuilder) because it does things like: type.setArrayType(arrayType); type.setBuilder(this); those methods are inherited from AbstractDatatype, where they are declared as protected. Thus, I was painfully reminded that protected members in Java are visible not only to subclasses, but to all other classes in the same package as well! As long as StringTypeBuilder is in the same package as AbstractDatatype, all is well, but as soon as I copy it to com.example.mypackage.MyTypeBuilder, it doesn't compile anymore. Now, there's a quick workaround to that: I could just override the methods in MyType and delegate to super. Somehow I think this is not very elegant. I'd like to make them public, but this bugs me a little, as it means increasing the surface complexity of AbstractDatatype. However, I cannot think of a better solution. Do you? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: JCR samples added
Michael Wechner wrote: Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: JCR samples added
On Jul 15, 2005, at 6:04 PM, Carsten Ziegeler wrote: Michael Wechner wrote: Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/ samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. Carsten With current build I still get an Initialization Problem when accessing to the server: java.io.FileNotFoundException: /home/leo/BRANCH_2_1_X/build/webapp/ samples/repository.xml (No such file or directory) org.apache.avalon.framework.configuration.ConfigurationException: Cannot access configuration information at file:/home/leo/ BRANCH_2_1_X/build/webapp/WEB-INF/cocoon.xconf:2076:106 at org.apache.cocoon.jcr.JackrabbitRepository.configure (JackrabbitRepository.java:93) at org.apache.avalon.framework.container.ContainerUtil.configure (ContainerUtil.java:240) So, the sync isn't all done already, or is it? /Leo
Re: JCR samples added
Leo Leonid wrote: On Jul 15, 2005, at 6:04 PM, Carsten Ziegeler wrote: Michael Wechner wrote: Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/ samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. Carsten With current build I still get an Initialization Problem when accessing to the server: java.io.FileNotFoundException: /home/leo/BRANCH_2_1_X/build/webapp/ samples/repository.xml (No such file or directory) org.apache.avalon.framework.configuration.ConfigurationException: Cannot access configuration information at file:/home/leo/ BRANCH_2_1_X/build/webapp/WEB-INF/cocoon.xconf:2076:106 at org.apache.cocoon.jcr.JackrabbitRepository.configure (JackrabbitRepository.java:93) at org.apache.avalon.framework.container.ContainerUtil.configure (ContainerUtil.java:240) So, the sync isn't all done already, or is it? no, this is something else. When one enables the jcr block within blocks.properties or local.blocks.properties then one needs to copy the src/blocks/jcr/samples into build/webapp/ such that the compenent can find the repository.xml file. But I just realize that blocks.properties has jcr block enabled by default, but the samples won't be copied automatically. Sorry for this. I will do a quick fix by disabling the block by default. I am not sure if this was the reason that Sylvain didn't put in the xconf of the component. Is there a possibility that if the jcr block is enabled, that also the samples are being copied? Michi /Leo -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Michael Wechner wrote: Is there a possibility that if the jcr block is enabled, that also the samples are being copied? Please ignore my last message. I was totally confused, because I used a local.build.properties where the samples were disabled and copied the samples of jcr by hand. I have fixed the paths within src/blocks/jcr/conf/jcr-component.xconf and it should work now (please update your local workspace and clean/build Cocoon again). Please apologize for any inconvenience Michi Michi /Leo -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Carsten Ziegeler wrote: X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. ok, will do that. Michi Carsten -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [OT] Top 10-1 (was Top 10) things to do in Stuttgart
Hi all, a short correction: Jochen Kuhnle [EMAIL PROTECTED] wrote on 14.07.2005 15:16:46: 1. Visit the Fernsehturm (TV-Tower): Touristy, but nice view. http://www.fernsehturm-stuttgart.de/index_en.html Sorry, missed that: The Fernsehturm (TV-Tower) is closed due to renovations. Regards, Jochen
adding a block
Can someone point me at the doc that accurately describes how to add a new block to Cocoon (for both 2.1.x and trunk). My stumbling block seems to be that I have no idea how gump resolves the depend elements. Also, doesn't it strike anyone as strange that the blocks are now off in their own little world in svn but can't be built unless they are defined in Cocoon's root directory? Ralph
Xerces 2.7.0 in 2.1.8-dev (was Re: svn commit: r201870 - in /cocoon/branches/BRANCH_2_1_X/src/blocks: forms/java/org/apache/cocoon/forms/util/DomHelper.java woody/java/org/apache/cocoon/woody/util/DomHelper.java)
Antonio Gallardo wrote: On Lun, 27 de Junio de 2005, 11:45, Vadim Gritsenko dijo: Antonio Gallardo wrote: On Lun, 27 de Junio de 2005, 8:34, Vadim Gritsenko dijo: [EMAIL PROTECTED] wrote: Author: antonio Date: Sun Jun 26 08:34:51 2005 New Revision: 201870 URL: http://svn.apache.org/viewcvs?rev=201870view=rev Log: Use org.w3c.dom.UserDataHandler instead of org.apache.xerces.dom3.UserDataHandler. Xerces now uses DOM Level 3. It means 2.1 won't run on older Xerces anymore. I think this is not acceptable - not at this moment anyway, when many containers are running with older Xerces. Please revert, for 2.1. The problem is the old org.apache.xerces.dom3.UserDataHandler does not exists in the new Xerces version. What to do? There are at least two options: * Go back to older xerces :-) * Check presense of the new xerces using reflection, and make sure code works with both old xerces and new one. The easier is to go back. :-) I will revert xerces today at night in cocoon 2.1.x. I didn't the reversion because I was very busy + Sylvain suggested another way instead of reversion. I am planning this weekend to do the job. Here is the Sylvain mail: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111990875625491 I wonder if somebody is having troubles with the new xerces version 2.7.0. I found we need to place the new xerces.jar and xml-apis.jar m in java/lib/endorsed to make use of it. All in all, please step up if the change is not desired at all. Comments? Best Regards, Antonio Gallardo
add getHeaderFields to LinkStatusGenerator?
Hello, I was wondering if you might find a configuration option like: parameter name=get-header-fields value=true/ for org/apache/cocoon/generation/LinkStatusGenerator.java to be useful to the community. Basically, if this option is set to true, we could call http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLConnection.html#getHeaderFields() from the http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/generation/LinkStatusGenerator.html#processURL(java.net.URL,%20java.lang.String) method and add the name/value pairs as attributes to the xml output for each link crawled. Regards, Rus http://www.discountdracula.com
Lucene Index
Hello all, I've been digging through the Lucene project and Lucene block docs, but can't seem to get what I want to work or find much that references it. So I've got a few more dumb questions to ask. What I'm trying to do is get a crawler to walk through all the links that the current refdoc code generates and have the Lucene block index them and allow me to search them through Cocoon pipelines and grab matching results for transforming and serializing. The sitemap has the necessary views in place for Lucene and all the documents and directories have crawler friendly sets of links to follow to each file. I've even gotten the Lucene block samples page to generate something from what I've got there (showing up as an 'index' folder in /WEB-INF/work/), but searching it seems ineffectual for whatever reasons. I would like to be able to specify in the sitemap for the indexing to be done and what sorts of searches I want to do, which I can't figure out. I'd also like to be able to configure the indexing to index and/or store certain elements and while I've seen some minimal examples of this in the XMLSearching documentation I can't figure out how to make it work for me. I feel very stupid asking all this, but I can't seem to find enough resources to sort it all out. Thanks for all the help. Robert
[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 50 projects. 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-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-chaperon : Java XML Framework - 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-faces : 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-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : 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-repository : Java XML Framework - cocoon-block-scratchpad : 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-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... 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] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15072005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-15072005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15072005/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: 14 secs 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-15072005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15072005.jar -Dbuild=build/cocoon-15072005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[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 50 projects. 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-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-chaperon : Java XML Framework - 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-faces : 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-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : 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-repository : Java XML Framework - cocoon-block-scratchpad : 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-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... 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] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15072005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-15072005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15072005/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: 14 secs 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-15072005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15072005.jar -Dbuild=build/cocoon-15072005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
