Trunk Broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can't build the trunk with allblocks. Did I missed something? INFO] Compiling 29 source files to /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/target/classes [INFO] - [ERROR] BUILD FAILURE [INFO] - [INFO] Compilation failure /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[45,47] cannot find symbol symbol : class EncodingSerializer location: package org.apache.cocoon.components.serializers /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[370,16] cannot find symbol symbol : variable EncodingSerializer location: class org.apache.cocoon.portal.wsrp.adapter.WSRPAdapter Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwAgt2lZVCB08qHERAsnJAJ9vN0MlfZor0AEhzZ15EhD6e+1DdACg0v0Z 4pSEgfk9UTFt1QrYWejH+vk= =CY1V -END PGP SIGNATURE-
Re: Trunk Broken
Felix Knecht skrev: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can't build the trunk with allblocks. Did I missed something? I had the same problem yesterday. It remained after having cleaned the local maven repository for Cocoon artifacts. When loading it into Eclipse it seemed like there where a lot of missing dependencies. /Daniel INFO] Compiling 29 source files to /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/target/classes [INFO] - [ERROR] BUILD FAILURE [INFO] - [INFO] Compilation failure /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[45,47] cannot find symbol symbol : class EncodingSerializer location: package org.apache.cocoon.components.serializers /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[370,16] cannot find symbol symbol : variable EncodingSerializer location: class org.apache.cocoon.portal.wsrp.adapter.WSRPAdapter Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwAgt2lZVCB08qHERAsnJAJ9vN0MlfZor0AEhzZ15EhD6e+1DdACg0v0Z 4pSEgfk9UTFt1QrYWejH+vk= =CY1V -END PGP SIGNATURE-
Re: Trunk Broken
Sorry, that's my fault - I thought the wsrp block was excluded... I'll fix this asap. Carsten Daniel Fagerstrom wrote: Felix Knecht skrev: Can't build the trunk with allblocks. Did I missed something? I had the same problem yesterday. It remained after having cleaned the local maven repository for Cocoon artifacts. When loading it into Eclipse it seemed like there where a lot of missing dependencies. /Daniel INFO] Compiling 29 source files to /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/target/classes [INFO] - [ERROR] BUILD FAILURE [INFO] - [INFO] Compilation failure /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[45,47] cannot find symbol symbol : class EncodingSerializer location: package org.apache.cocoon.components.serializers /home/felix/svn/apache/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-wsrp-impl/src/main/java/org/apache/cocoon/portal/wsrp/adapter/WSRPAdapter.java:[370,16] cannot find symbol symbol : variable EncodingSerializer location: class org.apache.cocoon.portal.wsrp.adapter.WSRPAdapter Regards Felix -- Carsten Ziegeler [EMAIL PROTECTED]
[SOLVED] Re: Trunk Broken
Carsten Ziegeler schrieb: Sorry, that's my fault - I thought the wsrp block was excluded... I'll fix this asap. That was it, works again. Thanks Carsten
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
Joerg Heinicke pisze:
I wonder what exactly will it be when everything is unified: {} or ${}?
I thought it's the latter, also the issue description seems to point on
this.
The latter one because it's already used in Template and this way new expressions can be evaluated
alongside old ones. This way we can provide smooth migration path.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [vote result] Let our environment abtractions extend the http servlet ones
Daniel Fagerstrom skrev: Daniel Fagerstrom skrev: I would like o.a.c.environment.[Request|Response|Session] to extend javax.servlet.http.Http[ServletRequest|ServletResponse|Session] respectively. ... So I will implement my proposal with Alfred's deprecation scheme in the beginning of next week. I have commited the changes to the trunk. Everything compiles (removed the cocoon artifacts in them maven rep first) and all tests runs (except ZipSourceTestCase which is unrelated to this change). I tested a couple of samples as well and they still works. But I modified a lot of code so I would be surprised if I didn't miss anything. Please report if there are any problems. For the actual changes I followed Alfred's proposal. A small thing that I missed concerning possibly incompatible changes is the former method: org.apache.cocoon.environment.Cookie Response.createCookie(String name, String value); Which I replaced with: javax.servlet.http.Cookie createCookie(String name, String value); /* * @deprecated use [EMAIL PROTECTED] #createCookie(String, String)} instead. */ org.apache.cocoon.environment.Cookie createCocoonCookie(String name, String value); But thinking about it having a factory method for javax.servlet.http.Cookie seem quite pointless, we should probably just deprecate the factory method and recomend them to use the constructor instead: /* * @deprecated use codenew [EMAIL PROTECTED] javax.servlet.http.Cookie(String, String)}/code instead. */ org.apache.cocoon.environment.Cookie createCocoonCookie(String name, String value); WDYT? For all the javax.servlet.http methods that wasn't part of our environment instructions I added methods that throws UnsupportedOperationException to the AbstractRequest, AbstractRespose and the AbstractSession classes. We can implement these methods later if people need them. For the back incompatibilities in the rest of the code I switched most uses of Session to HttpSession and most uses of org.apache.cocoon.environment.Cookie to javax.servlet.http.Cookie. In the few cases where it would have affected the api of the classes I downcasted getSession() to Session respectively used getCocoonCookie instead. I haven't fixed 2.1 yet. As I haven't worked on 2.1 for years I would happy if someone volunteered to do it. Otherwise I'll fix it in a few days when we are certain that the trunk works. I saw that trunk/commons/status.xml hasn't been touched for nearly a year. Should I document the change there or do we have some new place for documenting changes in the trunk? Do we have some special area in the 2.2 documentation for upgrade how to? /Daniel
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
Grzegorz Kossakowski skrev:
Joerg Heinicke pisze:
I wonder what exactly will it be when everything is unified: {} or
${}? I thought it's the latter, also the issue description seems to
point on this.
The latter one because it's already used in Template and this way new
expressions can be evaluated alongside old ones. This way we can provide
smooth migration path.
As I wrote about in
http://marc.info/?l=xml-cocoon-devm=118683052219287w=2 we already
(since maybe two years ago) has a migration path from the old to the new
syntax. As the string template readers in template is plugable. In that
implementation we actually use {} for the new syntax (following XSLT) as
people seemed to prefer that back then. This is of course not written in
stone, we could use ${} instead if that is what people prefer now. If we
use ${} we more or less have to have JEXL as default expression language
implementation, otherwise it will be highly confusing.
/Daniel
Sorry for multiple commits
Hello, Sorry for multiple commits (r565569-565574). Seems like Subversive for Eclipse freaked out for some reason... -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
