Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jan 2006, Jorg Heymans wrote: Date: Thu, 12 Jan 2006 00:19:47 +0100 From: Jorg Heymans <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati wrote: In a big multiproject Maven 1 project we solved this by an entity file in the root directory where all dependant jar had entities for their groupId, artifactId and version (strictly sorted by groupId and artifactId) and each (sub) project.xml file included it and used those entity to define their individual dependency. This way we prevented version clashes easily and relatively early. This has worked fine (even if not recommended by Maven itself. In another project it has hit us hard when we used automated integration tests with Continuum which wasn't able to locate the entity file anymore because of relative paths in the project.xml. I've never actually used it, but the dependencyManagement [1] element is all about centrally managing dependency versions. Thanks. I've probably overlooked that. Seems to be a possibility we have to keep an eye on in case we do have to manage dependencies in a more general and centralized way for all our blocks to prevent version clashes (until we have classloader isolation for blocks). - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxgp4LNdJvZjjVZARAjzkAJ9kJEL46BDHw3wX5C6MF2igeCXKEQCgtXda PSOLSfpogxJMT22sEfdtJho= =LIJM -END PGP SIGNATURE-
Re: [M10N] JCL and webapp classloader issues
Reading Ceki Gülcü's trashing of commons-logging [1], i'm wondering if we have other options as to what our usage of JCL is concerned (slf4j [2] ?). I'm by no means an expert on classloaders and logging , but Ceki's wording at the end is clear enough for everyone to understand : As demonstrated above, JCL's discovery mechanism invents new and original ways of shooting yourself in the foot. For example, with JCL you can shoot yourself in the foot while aiming at the sky. Thanks to JCL you can be hit by lightning in the middle of the desert when it's not raining. If your computing life is too dull and trouble is what you are looking for, then JCL is the way to go. Thoughts? (has this been hashed over before?) Without getting into any holy logging wars here I would suggest maybe nudging over at jakarta commons a bit. AFAIK quite a few of the JCL issues are resolved in trunk ...but there has not been a new release yet. Maybe you give the trunk build a try? cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: > In a big multiproject Maven 1 project we solved this by an entity file > in the root directory where all dependant jar had entities for their > groupId, artifactId and version (strictly sorted by groupId and > artifactId) and each (sub) project.xml file included it and used those > entity to define their individual dependency. This way we prevented > version clashes easily and relatively early. This has worked fine (even > if not recommended by Maven itself. In another project it has hit us > hard when we used automated integration tests with Continuum which > wasn't able to locate the entity file anymore because of relative paths > in the project.xml. I've never actually used it, but the dependencyManagement [1] element is all about centrally managing dependency versions. HTH Jorg [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Re: Block deployment: working with blocks from a user's point of view
Giacomo Pati wrote:
Ok, I was wondering when I saw the commit mail what those hard coded
dependencies would be all about in the Mojo. :-)
The Mojo only contains some code to learn how I can use Maven 2 dependency
resolution and download artifacts.
It will use org.apache.cocoon.deployer.BlockDeployer that will do all the
deployment stuff.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Block deployment: working with blocks from a user's point of view
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Reinhard Poetz wrote: Date: Wed, 11 Jan 2006 22:47:43 +0100 From: Reinhard Poetz <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Block deployment: working with blocks from a user's point of view As mentioned in a mail a couple of days ago, I've started to work on the block deployment mechanism. This forced me to think a lot about how I (and hopefully others) want to develop Cocoon 2.2 applications. Great! Count me in. I wrote two tutorials that guide a developer step by step through the process of - creating a block[1] and - creating a web application that uses blocks[2]. I'll have a look at it. At the time of writing this, the functionality described in both documents has only been implemented partly. Nevertheless I publish them at this early stage in order to get feedback from you to make the first contact with Cocoon 2.2 as simple as possible. Ok, I was wondering when I saw the commit mail what those hard coded dependencies would be all about in the Mojo. :-) This should also give everybody the chance of getting involved without having to dig into the code (though I would be more than pleased if somebody does). I have also committed the IDE and build tool independant block deployer[3] and a skeleton for the block deployer mojos[4] that will wrap the general block deployer. [1] http://cocoon.zones.apache.org/daisy/documentation/g2/796.html [2] http://cocoon.zones.apache.org/daisy/documentation/g2/797.html [3] http://svn.apache.org/repos/asf/cocoon/whiteboard/deployer/ [4] http://svn.apache.org/repos/asf/cocoon/whiteboard/deployer-maven-plugin/ I'll look into those as well (but not this night ;-) Thanks and Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD4DBQFDxYAkLNdJvZjjVZARAqUiAJjUPu5BUzTQ8Mg9ieCkMHdNcakmAJ9gdokg wMGCKUf2aQkS/9UmV8aiJw== =S8Qf -END PGP SIGNATURE-
Block deployment: working with blocks from a user's point of view
As mentioned in a mail a couple of days ago, I've started to work on the block
deployment mechanism. This forced me to think a lot about how I (and hopefully
others) want to develop Cocoon 2.2 applications.
I wrote two tutorials that guide a developer step by step through the process of
- creating a block[1] and
- creating a web application that uses blocks[2].
At the time of writing this, the functionality described in both documents has
only been implemented partly. Nevertheless I publish them at this early stage in
order to get feedback from you to make the first contact with Cocoon 2.2 as
simple as possible.
This should also give everybody the chance of getting involved without
having to dig into the code (though I would be more than pleased if somebody
does).
I have also committed the IDE and build tool independant block deployer[3] and a
skeleton for the block deployer mojos[4] that will wrap the general block deployer.
[1] http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
[2] http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
[3] http://svn.apache.org/repos/asf/cocoon/whiteboard/deployer/
[4] http://svn.apache.org/repos/asf/cocoon/whiteboard/deployer-maven-plugin/
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Giacomo Pati wrote: Date: Wed, 11 Jan 2006 21:19:22 +0100 (CET) From: Giacomo Pati <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr --[PinePGP]--[begin]-- On Wed, 11 Jan 2006, Daniel Fagerstrom wrote: Date: Wed, 11 Jan 2006 16:48:10 +0100 From: Daniel Fagerstrom <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Carsten Ziegeler wrote: ... > (And it would be good if people would not forget about the licence file > when they add jars) > > With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. I was to write a mail about it but you raised it before. We are at the same trap as Maven 1 multiproject concerning dependencies. We will fall into it as well (maybe even faster because of transitive deps). BlockA depends on jarB-1.0 which depends on jarC-1.0 BlockD depends on jarE-1.0 which depends on jarC-2.0 BlockF depends on BlockA and depends on BlockD Version 1.0 and 2.0 of jarC are incompatible wrt backward compatibility. And voila we have the desaster. The above chain might look overseeable but imagine the chain is 5 times deeper. You might exclude jarC-2.0 from dependency resolution, after a possibly excessive debugging session where you finally figured you have a version problem, and hope all still runs well. OSGI blocks may solve this (with classloader isolation) but ATM we don't have it. Anybody solved this in an elegant way In a big multiproject Maven 1 project we solved this by an entity file in the root directory where all dependant jar had entities for their groupId, artifactId and version (strictly sorted by groupId and artifactId) and each (sub) project.xml file included it and used those entity to define their individual dependency. This way we prevented version clashes easily and relatively early. This has worked fine (even if not recommended by Maven itself. In another project it has hit us hard when we used automated integration tests with Continuum which wasn't able to locate the entity file anymore because of relative paths in the project.xml. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxW5OLNdJvZjjVZARAnB8AKDGx4MFW2/BX3oXdr+KPySYzQV0lQCfRl7n B/CJ8ikMJjRF8RqQ1J9wXOo= =bmDr -END PGP SIGNATURE-
AW: Access to the AuthenticationContext
Hmpf, I don't get it to work. Btw, I get the context from the
SessionManager, but you made me curious about the session-context input
module (mainly because the XPath). Here's my method (I have the manager
object as an instance variable and only use the session-context, so it
slightly differs from the method proposed by John):
private String getInputModuleAttribute(String path) {
ServiceSelector selector = (ServiceSelector)
manager.lookup(InputModule.ROLE + "Selector");
InputModule inputModule = (InputModule)
selector.select("session-context");
return (String) inputModule.getAttribute(path, null, null);
}
Of course I handle the exceptions (and none is thrown btw), but I left that
out for readability purposes.
So I tried many ways to get just one parameter:
getInputModuleAttribute("//id"));
getInputModuleAttribute("/authentication/ID"));
getInputModuleAttribute("//ID"));
getInputModuleAttribute("session-context:authentication/ID"));
getInputModuleAttribute("session-context:authentication//ID"));
getInputModuleAttribute("session-context:authentication/authentication/ID"))
;
but all I get in return is null.
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/webapps/session/compo
nents/ContextInputModule.html#getAttribute(java.lang.String,%20org.apache.av
alon.framework.configuration.Configuration,%20java.util.Map) says, that null
is returned if the value doesn't exist. Huh?
The value is there - I can get it by calling
sessionManager.getContextFragment("authentication", "/authentication/ID")).
Where's my daily mistake this time? :)
Cheers,
Stefan
| -Ursprüngliche Nachricht-
| Von: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED]
| Gesendet: Montag, 9. Januar 2006 13:15
| An: dev@cocoon.apache.org
| Betreff: Re: Access to the AuthenticationContext
|
| * Stefan Pietschmann:
| > | You can also use the « session-context » input module to retrieve
| > | the piece of information more nicely:
| >
| > I would actually call this like
| > getInputModuleAttribute(manager,"session-context","/authentication/id")?
| And
| > it would return the id?
|
| Yes, quite: getInputModuleAttribute(manager,"session-
| context","authentication/authentication/id")
|
| > Even if so, I don't always have the full xpath and have to search for
| the
| > node, which would be kinda hard this way.
|
| You can use an XPath expression like:
|
| getInputModuleAttribute(manager,"session-context","//id")
|
| Best regards,
| --
| Jean-Baptiste Quenot
| Systèmes d'Information
| ANYWARE TECHNOLOGIES
| Tel : +33 (0)5 61 00 52 90
| Fax : +33 (0)5 61 00 51 46
| http://www.anyware-tech.com/
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Daniel Fagerstrom wrote: Date: Wed, 11 Jan 2006 16:48:10 +0100 From: Daniel Fagerstrom <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Carsten Ziegeler wrote: ... (And it would be good if people would not forget about the licence file when they add jars) With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. I was to write a mail about it but you raised it before. We are at the same trap as Maven 1 multiproject concerning dependencies. We will fall into it as well (maybe even faster because of transitive deps). BlockA depends on jarB-1.0 which depends on jarC-1.0 BlockD depends on jarE-1.0 which depends on jarC-2.0 BlockF depends on BlockA and depends on BlockD Version 1.0 and 2.0 of jarC are incompatible wrt backward compatibility. And voila we have the desaster. The above chain might look overseeable but imagine the chain is 5 times deeper. You might exclude jarC-2.0 from dependency resolution, after a possibly excessive debugging session where you finally figured you have a version problem, and hope all still runs well. OSGI blocks may solve this (with classloader isolation) but ATM we don't have it. Anybody solved this in an elegant way - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxWhMLNdJvZjjVZARAtLnAJ0VcA+4JV4/jrOfzkKCXIeOGz+YZwCeM/Df WRP4gWw6BIHKVCQQXLwOI8U= =z4gn -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Jorg Heymans wrote: Date: Wed, 11 Jan 2006 14:40:02 +0100 From: Jorg Heymans <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread "Making a redist of all the javax.* packages") Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? Geronimo has all kinds of spec jars but not JCR :-( - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxWBaLNdJvZjjVZARAoO3AJ41ArVEvT9kzyk5mg6NUtRJuH5EUACgrO2R 348Fm6cqb6AOGYftxp1fFgs= =5yXD -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Carsten Ziegeler wrote: Date: Wed, 11 Jan 2006 13:26:35 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati schrieb: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? Dumb question, but why don't you use version 1.0 of tje jcr? We have this in our distribution for a very long time and I think it's also on the apache repository. I must have had blinders on when looking into lib/optional. Sure we use jcr-1.0 not jcr-1.1. But anyway, couldn't find one on our repos nor on ibiblio. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxV8ELNdJvZjjVZARAgyGAJ9rd0jXjlFUj1yFVWUvRTqCOj+AkQCePUUc gSW65lpAX7Ci+fa8zeyrL5s= =svDF -END PGP SIGNATURE-
jetty6:run is working now (was Re: [M10N] JCL and webapp classloader issues)
Jorg Heymans wrote: > > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: No suitable Log > constructor [Ljava.lang.Class;@c7c7bc for > org.apache.commons.logging.impl.Log4JLogger > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272) > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) > at net.sf.ehcache.CacheManager.(CacheManager.java:86) > ... 44 more > Caused by: org.apache.commons.logging.LogConfigurationException: No > suitable Log constructor [Ljava.lang.Class;@c7c7bc for > org.apache.commons.logging.impl.Log4JLogger > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:432) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525) > ... 47 more > Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:1618) > at java.lang.Class.getConstructor0(Class.java:1930) > at java.lang.Class.getConstructor(Class.java:1027) > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:429) > > > ... which is a classloader issue AFAICT. > It turned out to be a jetty-solvable issue. They have updated their snapshots again for us, the jetty6 plugin now runs our 2.2 core! Read [1], section "How to use the webapp" for instructions on how to get it running (improvements on the documentation always welcome) Regards Jorg [1] http://cocoon.zones.apache.org/daisy/documentation/g2/756.html
Re: [M10N] cocoon-jcr
Jorg Heymans wrote: Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread "Making a redist of all the javax.* packages") Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? careful. JCR is *NOT* part of J2EE, so looking for them in Geronimo is the wrong place. The reference implementation of JCR is JackRabbit, currently under incubation. NOTE: unlike much of the sun stuff, JCR is released under a compatible license that was written by our very own Roy Fielding and is very similar to the Apache License 2.0, and designed to be compatible with it. I don't know the status of the licensing releasing of JCR, though, but I'm sure the email I copied on jackrabbit will give us the answers we want. -- Stefano.
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? I'm copying this to jackrabbit-dev because I honestly don't have an answer for this. -- Stefano.
Re: [M10N] cocoon-jcr
Jorg Heymans wrote: Daniel Fagerstrom wrote: With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. Check out the sample reports in [1]. The dependencies report turns up empty for cocoon-core though, there might be some additional info still missing. Yes, that is the kind of report I'm looking for. So besides getting any content in the reports, we would need a dynamically updated Maven site for Cocoon. Then the project dependencies report should contain a licence URL by default, with some really disturbing visual desing for the case when the POM doesn't contain license info, so that it creates a social pressure to include licens info in all POMs ;) /Daniel [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/
Re: [M10N] cocoon-jcr
Daniel Fagerstrom wrote: > With M2s transitive dependence handling it is harder to keep track of > what we actually depend on. Is there some reporting plugin or switch, so > that one can get a report of all dependencies of a block or a multi > project POM? > > Otherwise we risk to get an unwelcome suprise when we genrate a binary > release. > Check out the sample reports in [1]. The dependencies report turns up empty for cocoon-core though, there might be some additional info still missing. Jorg [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/
Re: [M10N] cocoon-jcr
Daniel Fagerstrom schrieb: > Carsten Ziegeler wrote: > ... > > >>(And it would be good if people would not forget about the licence file >>when they add jars) >> >> > > With M2s transitive dependence handling it is harder to keep track of > what we actually depend on. Actually, I meant 2.1.x where it is easy to see on what we depend and which licenses we have. But from time to time it just happens. > Is there some reporting plugin or switch, so > that one can get a report of all dependencies of a block or a multi > project POM? > > Otherwise we risk to get an unwelcome suprise when we genrate a binary > release. > Yepp. I guess the site plugin with the reports is the way to go. It should list all dependencies. I tried it out before 2.0 was out, but it failed...perhaps it's now working? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] cocoon-jcr
Carsten Ziegeler wrote: ... (And it would be good if people would not forget about the licence file when they add jars) With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. /Daniel
[M10N] JCL and webapp classloader issues
I am trying to get the webapp to work again now that the jetty folks kindly produced new snapshots for us. Good news is they are keen to support us getting our core running : > Jan Bartel wrote: > > ... Snapshot is on it's way to the repository now. A beta release > will also follow shortly. Let us know if there is anything else we > can do to help Cocoon on it's way. Now about the webapp: - IMPORTANT : "mvn war:inplace" never removes dependencies in WEB-INF/lib. So if you remove/upgrade a lib and you'ld like to test the webapp then you should remove WEB-INF/lib before war:inplace to start from a clean state. Trying mvn jetty6:run in cocoon-webapp i get : Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@c7c7bc for org.apache.commons.logging.impl.Log4JLogger at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) at net.sf.ehcache.CacheManager.(CacheManager.java:86) ... 44 more Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@c7c7bc for org.apache.commons.logging.impl.Log4JLogger at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:432) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525) ... 47 more Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1618) at java.lang.Class.getConstructor0(Class.java:1930) at java.lang.Class.getConstructor(Class.java:1027) at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:429) ... which is a classloader issue AFAICT. Reading Ceki Gülcü's trashing of commons-logging [1], i'm wondering if we have other options as to what our usage of JCL is concerned (slf4j [2] ?). I'm by no means an expert on classloaders and logging , but Ceki's wording at the end is clear enough for everyone to understand : > As demonstrated above, JCL's discovery mechanism invents new and > original ways of shooting yourself in the foot. For example, with JCL > you can shoot yourself in the foot while aiming at the sky. Thanks to > JCL you can be hit by lightning in the middle of the desert when it's > not raining. If your computing life is too dull and trouble is what > you are looking for, then JCL is the way to go. Thoughts? (has this been hashed over before?) Jorg [1] http://www.qos.ch/logging/classloader.jsp [2] http://www.slf4j.org/
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: > > I'm trying to get the cocoon.jcr block compiling but cannot find a > jcr-1.1.jar to download from any of the maven repos I know of. > > Anybody knows of one? I've found a jcr-1.0.jar at > http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day > server in our poms. > > I also don't know whether that one is publically redistributable and the > Maven 2 docs suggests downloading it from the official Sun site and > installing it into each ones local Maven2 repository. > > Any ideas how to solve this? > This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread "Making a redist of all the javax.* packages") Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? Jorg
[M10N] GroupId for blocks and layering of Cocoon
Was: Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/ Carsten Ziegeler wrote: Daniel Fagerstrom schrieb: Jorg Heymans skrev: Giacomo Pati wrote: ... Each block should have the same groupId yes. Should we make it o.a.c.blocks ? (in analogy with [1]) Everything will be a block, the core included, in analogy with [2]. So it would be redundant to introduce an extra level in the groupId. Hmm, don't we need some "bootstrapping", for example the cocoon servlet or the cli main class etc? I think these are not really blocks. Even if they are from an implementation pov, they are not from a functionality pov. So personally, I would distinguish between blocks and "bootstrapping" which could be core. One of the goals from the NG discussions during the end of the last year was to make Cocoon less monolithic, and make it easier to reuse parts of it. At the top layer in an layered Cocoon architecture I envision that we have "controllers" (that implement Servlet). The controller chain for large Cocoon systems would be: BlocksManager -> BlockManager -> [SitemapServlet | FlowscriptServlet | JavaFlowServlet | ... ] In a small application with less need for modularization the controller chain might be just: FlowscriptServlet If we want the different controllers to be reusable it makes less sense to consider one of them a bootstrap layer. The blocks framework is under refactoring to implement this vision. --- o0o --- Until things has settled a little bit more I suggest that we keep the current flat layout with o.a.c as GroupId. I also think that GroupId should reflect community structure rather than function. If we start to grow as a community and get clear sub communities that work on disjunct set of artifacts, it would make sense to have a more fine grained GroupId structure. /Daniel
Re: (Re)Licensing question
On 1/10/06, David Crossley <[EMAIL PROTECTED]> wrote: > This plain language FAQ is helpful: > http://www.apache.org/foundation/licence-FAQ.html#WhatDoesItMEAN > and follow through to the preFAQ which has a good overview, Any idea why this is stated in the pre-FAQ? 9. You have questions specifically about the Apache XML projects. If you have sent us mail about one of the Apache XML software projects (Xerces, FOP, Cocoon, et cetera), please use the following contact instead: http://xml.apache.org/mail.html> I imagine they can remove Cocoon from that list? Geoff
[jira] Created: (COCOON-1730) [Link] Computer Science Department 2 - University of Erlangen-Nuremberg
[Link] Computer Science Department 2 - University of Erlangen-Nuremberg --- Key: COCOON-1730 URL: http://issues.apache.org/jira/browse/COCOON-1730 Project: Cocoon Type: Wish Components: * Cocoon Core Versions: 2.1.8 Reporter: Thorsten Meinl URL of the website: http://www2.informatik.uni-erlangen.de/ Title of the website: Computer Science Department 2 Cocoon version used: 2.1.8 Short summary: Webpages of the programming systems group at the Friedrich-Alexander University Erlangen-Nuremberg How can we verify this site is actually built with Cocoon? http://www2.informatik.uni-erlangen.de/cocoon-status.xml - How much time did it take to build the site from design to publication? 2 months - How much traffic does the site handle? ~300MB/day, ~15,000 hits/day - What made you choose Cocoon to build the site? Our university-wide information system (UnivIS, http://univis.uni-erlangen.de/) offers an XML export of all data (lecture, publications, person, projects, ...) To avoid maintaining the data at multiple places we import these data and use Cocoon to produce our webpages more or less automatically - What other information do you want to disclose (e.g. how does it work, how didyou build it, what parts of Cocoon did you use)? Most importantly, we use eXist as XML database to store the imported data and use the XMLDBTransformer to include it into the pipeline. - Can you provide a contact email address if people want further information? [EMAIL PROTECTED] -- 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: [M10N] cocoon-jcr
Carsten Ziegeler wrote: > Giacomo Pati schrieb: > >>I'm trying to get the cocoon.jcr block compiling but cannot find a >>jcr-1.1.jar to download from any of the maven repos I know of. >> >>Anybody knows of one? I've found a jcr-1.0.jar at >>http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day >>server in our poms. >> >>I also don't know whether that one is publically redistributable and the >>Maven 2 docs suggests downloading it from the official Sun site and >>installing it into each ones local Maven2 repository. >> >>Any ideas how to solve this? >> > > Dumb question, but why don't you use version 1.0 of tje jcr? We have > this in our distribution for a very long time and I think it's also on > the apache repository. > Ah ok, sorry for my too fast response. Although we have the 1.0 version in svn, the corresponding licence file is missing. So, if we are not allowed to redistribute this we should remove it asap. (And it would be good if people would not forget about the licence file when they add jars) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] cocoon-jcr
Giacomo Pati schrieb: > > I'm trying to get the cocoon.jcr block compiling but cannot find a > jcr-1.1.jar to download from any of the maven repos I know of. > > Anybody knows of one? I've found a jcr-1.0.jar at > http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day > server in our poms. > > I also don't know whether that one is publically redistributable and the > Maven 2 docs suggests downloading it from the official Sun site and > installing it into each ones local Maven2 repository. > > Any ideas how to solve this? > Dumb question, but why don't you use version 1.0 of tje jcr? We have this in our distribution for a very long time and I think it's also on the apache repository. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxPfnLNdJvZjjVZARAgjwAKComo2a5T2m/37CGYnCxX5IzDxSvQCfU0FO 6EQ/PEkqszPi4uUu8/BNg48= =igIG -END PGP SIGNATURE-
[jira] Created: (COCOON-1729) [PATCH] Add multiple rows to a Repeater (fd:repeater-action).
[PATCH] Add multiple rows to a Repeater (fd:repeater-action). - Key: COCOON-1729 URL: http://issues.apache.org/jira/browse/COCOON-1729 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.8 Reporter: Rolf Metternich Priority: Trivial Attachments: patch.txt To add a certain numbers of Repeater.Rows (more than 1) to a Repeater with one Action, use the attribute "number-of-rows" in the definition of a repeater-action. Example: Add 5 rows Add 1 row -- 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: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Jorg Heymans wrote: Date: Wed, 11 Jan 2006 12:22:24 +0100 From: Jorg Heymans <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/ Giacomo Pati wrote: Should this distinction be on the groupId? Isn't the groupId just saying that all stuff in it belongs to the same project? I had a discussion a while ago with Brett Porter about this when i was converting excalibur. Outcome was that ideally a groupId points to the root package of that module's sources, but ofcourse practically this is not always viable. So it's not only an indication of which project a module belongs to, it can also express something about the submodule/project/logical grouping within the application. The maven guys haven't nailed down the exact semantics of the groupId yet and they are aware of this. So let's not worry about it too much for now, we can always change it later. Don't we need to decided that before a first release of 2.2? Is it wise to release a block into different groupIds? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxPEGLNdJvZjjVZARAv22AKC4RFb5lSoCfoqIAQ68QYkxaO+n3ACgqzcF 5CFhnUXnrIGFcq64CnAWAig= =DFje -END PGP SIGNATURE-
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
Carsten Ziegeler wrote: > personally would add "blocks" to the groupId to distinguish this from > other parts/subprojects, like o.a.c.tools etc. But if we choose just > o.a.c, I'm fine as well. > +1, either way is fine by me (but i agree about the bootstrapping in your previous mail) Jorg
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
Giacomo Pati wrote: > > Should this distinction be on the groupId? > Isn't the groupId just saying that all stuff in it belongs to the same > project? > I had a discussion a while ago with Brett Porter about this when i was converting excalibur. Outcome was that ideally a groupId points to the root package of that module's sources, but ofcourse practically this is not always viable. So it's not only an indication of which project a module belongs to, it can also express something about the submodule/project/logical grouping within the application. The maven guys haven't nailed down the exact semantics of the groupId yet and they are aware of this. So let's not worry about it too much for now, we can always change it later. Jorg
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
Giacomo Pati wrote: > > Should this distinction be on the groupId? > Isn't the groupId just saying that all stuff in it belongs to the same > project? > Yes, I think so - but what about sub projects? :) Now, I guess this can turn into a philosphical discussion about what the best approach is. I personally would add "blocks" to the groupId to distinguish this from other parts/subprojects, like o.a.c.tools etc. But if we choose just o.a.c, I'm fine as well. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CForms slower with JXTemplateGenerator
Leszek Gawron wrote: > roy huang wrote: > >> In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than >> FormTransformer >> > For 2.1.x it is probably true because it still contains unrefactored > version of jxtg. > So what about adding the new Template block to 2.1? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: (Re)Licensing question
On 10 Jan 2006, at 17:22, Andrew Stevens wrote: From: Helma van der Linden <[EMAIL PROTECTED]> Date: Tue, 10 Jan 2006 17:31:25 +0100 Guys, I usually keep away from licensing issues, but this time I'd like to know if it is done correctly. I'm looking at a project that is made up of several other open source projects, cocoon is one of them, another (sub)project is licensed under BSD. This project is licensed under GPL. It doesn't say that only their part is GPL and others are licensed differently. Looks like they included the entire Cocoon source tree with licensing files for all external jars used and they also left in the ASF license headers in the various files. Is this correct? Given that GNU [1] list the Apache licenses as "GPL-Incompatible, Free Software Licenses", I've always interpreted that to mean that you can't link to (i.e. make use of) Apache-licensed libraries (jars) in a project that you're releasing under the GPL. They don't appear to have an equivalent list for LGPL compatibility, unfortunately. I do recall that previous discussions on this list have stated that Apache-hosted projects aren't allowed to [L]GPL libraries in their CVS repositories. If I've got this all backwards, someone please let me know; I've a project of my own [2] that I would have licensed under GPL if not for the fact that I made use of libraries that were released under Apache and BSD licenses. Instead I went for LGPL on the grounds that I can find a lot of other LGPL'd projects that use the same libraries, so it looks like that's okay... I personally think you've got it upside down... You can write a piece of software distributed with a (L)GPL license and using ASL licensed software... The main problem for us (the ASF) is to "incorporate" software based on GPL/LGPL licenses (not the other way around). Basically, as we (ASF) don't impose any restriction on our software (it's a kind of do-whatever-you-want-with-it), if we were to include (L)GPL software we would force you (end user of Cocoon) to redistribute your project under a (L)GPL license: the ASF doesn't permit it, so that's why you won't find any reliance or use of (L)GPL software in ASL licensed projects. The other way around, is, on the other hand (and in my very personal non-lawyer idea), totally possible (Mr. Stallman still says it's not, but I don't believe he's right on this one). As your software is going to be (L)GPLed, yours is the choice of how to re-license the changes you make to OUR (cocoon's) classes: if you choose to distribute the changes you make to the Cocoon classes under the (L)GPL, then we (as the ASF) won't be able to redistribute them and you'll have to maintain your changes yourself. If you re-license your chages under the Apache Software License and we (as the ASF) are able to include them, we'll integrate them and ship them in our next release (hopefully). I know that in the past there were some issues dealing with the advertising clause in the Apache license 1.1 that Mr. Stallman didn't particularly like (and claimed were uncompatible), and now he's claiming that the version 2.0 of the Apache license is incompatible because of some patenting issue: those are subjective issues that were never tried in a court of law. Personally, not being a lawyer, I think the GNU approach (Mr. Stallman's) is over-zealous onto those issues, but, at the end-of-the- day, it's your gut-feeling that will have to tell you whether you can combine the two licenses or not. As far as my personal instinct goes, I wouldn't release anything under the (L)GPL, go straight to the ASL (or even better, BSD) and not care about it... Try to Google up "ASL LGPL GPL": you'll find links to a number of blogs on this subject, especially by those who are on the licensing committee in the ASF (they might explain you in more "legal" terms what my gut feeling is all about!!!) :-P :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Carsten Ziegeler wrote: Date: Wed, 11 Jan 2006 11:18:08 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/ Daniel Fagerstrom schrieb: Jorg Heymans skrev: Giacomo Pati wrote: ... Each block should have the same groupId yes. Should we make it o.a.c.blocks ? (in analogy with [1]) Everything will be a block, the core included, in analogy with [2]. So it would be redundant to introduce an extra level in the groupId. Hmm, don't we need some "bootstrapping", for example the cocoon servlet or the cli main class etc? I think these are not really blocks. Even if they are from an implementation pov, they are not from a functionality pov. So personally, I would distinguish between blocks and "bootstrapping" which could be core. Should this distinction be on the groupId? Isn't the groupId just saying that all stuff in it belongs to the same project? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxNzjLNdJvZjjVZARAu59AJsFb2e/fmbg+/AuTfuAMyVq7+VF3ACg6v8V GNg4i4QG4i+kTFMUofIH5Ik= =G6Eq -END PGP SIGNATURE-
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
Daniel Fagerstrom schrieb: > Jorg Heymans skrev: > >>Giacomo Pati wrote: > > ... > >>Each block should have the same groupId yes. Should we make it >>o.a.c.blocks ? (in analogy with [1]) > > > Everything will be a block, the core included, in analogy with [2]. So > it would be redundant to introduce an extra level in the groupId. > Hmm, don't we need some "bootstrapping", for example the cocoon servlet or the cli main class etc? I think these are not really blocks. Even if they are from an implementation pov, they are not from a functionality pov. So personally, I would distinguish between blocks and "bootstrapping" which could be core. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CForms slower with JXTemplateGenerator
roy huang wrote: > In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than > FormTransformer For 2.1.x it is probably true because it still contains unrefactored version of jxtg. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: CForms slower with JXTemplateGenerator
In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than FormTransformer Roy Huang
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
Jorg Heymans skrev: Giacomo Pati wrote: ... Each block should have the same groupId yes. Should we make it o.a.c.blocks ? (in analogy with [1]) Everything will be a block, the core included, in analogy with [2]. So it would be redundant to introduce an extra level in the groupId. /Daniel > [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml [2] http://dev.eclipse.org/viewcvs/index.cgi/
Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./ pom.xml src/ src/main/ src/test/
Giacomo Pati wrote: > Shouldn't each block belong to the same groupId? > > I've seen you have put each block to a different groupId: Each block should have the same groupId yes. Should we make it o.a.c.blocks ? (in analogy with [1]) Also note that when a pom has a parent, it will automatically inherit the groupId from that parent unless you override it (saves one line in the pom :) ) Regards Jorg [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml
[EMAIL PROTECTED]: Module cocoon success, but with warnings.
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] Module cocoon contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/cocoon/gump_work/update_cocoon.html Work Name: update_cocoon (Type: Update) Work ended in a state of : Failed Elapsed: 38 secs Command Line: svn --quiet update --non-interactive cocoon [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: Failed to add directory 'cocoon/cocoon-ajax/cocoon-ajax-impl/src/main/resources/WEB-INF': object of the same name already exists - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/cocoon/rss.xml - Atom: http://vmgump.apache.org/gump/public/cocoon/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2111012006, vmgump.apache.org:vmgump-public:2111012006 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
[EMAIL PROTECTED]: Module cocoon success, but with warnings.
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] Module cocoon contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/cocoon/gump_work/update_cocoon.html Work Name: update_cocoon (Type: Update) Work ended in a state of : Failed Elapsed: 38 secs Command Line: svn --quiet update --non-interactive cocoon [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: Failed to add directory 'cocoon/cocoon-ajax/cocoon-ajax-impl/src/main/resources/WEB-INF': object of the same name already exists - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/cocoon/rss.xml - Atom: http://vmgump.apache.org/gump/public/cocoon/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2111012006, vmgump.apache.org:vmgump-public:2111012006 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
