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
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 ma
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 the
-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]
-
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
Grzegorz Kossakowski (JIRA) wrote:
Grzegorz Kossakowski commented on COCOON-2079:
--
The most simple solution was to exclude pull-parser from scratchpad's
dependencies and it was exactly what I have
Ok with lots of help from Grzegorz, trunk now can be built *if you skip tests*.
There is still issue of three copies of XML APIs in WEB-INF/lib:
xml-apis-1.3.02.jar
xmlParserAPIs-2.0.2.jar
xmlParserAPIs-2.6.2.jar
And exceptions from deli:
java.lang.NullPointerException
at com.hp.hp
Vadim Gritsenko wrote:
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
It was missing dependency on cocoon-sitemap-impl, sorry for
inconvenience. Fixed in r563852.
Still does not build, but I don't get why - there is a dependency on
coc
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
It was missing dependency on cocoon-sitemap-impl, sorry for
inconvenience. Fixed in r563852.
Still does not build, but I don't get why - there is a dependency on
cocoon-expression-language-
Vadim Gritsenko pisze:
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
It was missing dependency on cocoon-sitemap-impl, sorry for
inconvenience. Fixed in r563852.
Still does not build, but I don't get why - there is a dependency on
cocoon-expression-language-api, that should be enough, i
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
Grzegorz Kossakowski (JIRA) wrote:
Grzegorz Kossakowski commented on COCOON-2079:
--
The most simple solution was to exclude pull-parser from scratchpad's
dependencies and it was exactly what I have
Vadim Gritsenko pisze:
Grzegorz Kossakowski (JIRA) wrote:
Grzegorz Kossakowski commented on COCOON-2079:
--
The most simple solution was to exclude pull-parser from scratchpad's
dependencies and it was exactly what I have done in r563174.
Could some
Grzegorz Kossakowski (JIRA) wrote:
Grzegorz Kossakowski commented on COCOON-2079:
--
The most simple solution was to exclude pull-parser from scratchpad's
dependencies and it was exactly what I have done in r563174.
Could someone check if trunk works
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on
Windows.
Now I can reproduce the problem. Sorry.
I think that my last commit (r552518) fixes the problem. It was a silly
mistake: JS and JEXL b
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on
Windows.
Now I can reproduce the problem. Sorry.
I think that my last commit (r552518) fixes the problem. It was a silly mistake: JS and JEXL beans where mixed up so initial
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: gkossakowski
Date: Sun Jul 1 16:13:44 2007
New Revision: 552371
URL: http://svn.apache.org/viewvc?view=rev&rev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Sp
Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on
Windows.
Now I can reproduce the problem. Sorry.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
Grzegorz Kossakowski pisze:
Reinhard Poetz pisze:
I'm not sure if it is really a JDK issue. I guess that your setup got
messed up by your refactorings. After fixing the compilation error
(see my commit) I was able to run the cocoon-template-sample using the
webapp produced by the rcl goal (I c
Reinhard Poetz pisze:
I'm not sure if it is really a JDK issue. I guess that your setup got
messed up by your refactorings. After fixing the compilation error (see
my commit) I was able to run the cocoon-template-sample using the webapp
produced by the rcl goal (I checked in the configuration)
Olivier Billard pisze:
Antonio, (all,)
FYI, we won the fight, we'll be using 6.0.
Yes-s-s :).
I still presume that I was not the only one, however there is one less
now !
Thanks for saying that. This really convinces me to opt for Java 1.5 as minimal
requirement for Cocoon in near future.
Antonio, (all,)
FYI, we won the fight, we'll be using 6.0.
Yes-s-s :).
I still presume that I was not the only one, however there is one less now !
--
Oliv_i_er
Antonio Gallardo wrote:
Oliver, I think we will stay at 1.4 Thank your for your feedback. :)
Best Regards,
Antonio Gallardo.
Oli
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: gkossakowski
Date: Sun Jul 1 16:13:44 2007
New Revision: 552371
URL: http://svn.apache.org/viewvc?view=rev&rev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Sp
[EMAIL PROTECTED] pisze:
Author: gkossakowski
Date: Sun Jul 1 16:13:44 2007
New Revision: 552371
URL: http://svn.apache.org/viewvc?view=rev&rev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Spring beans
* conversion Defau
On 6/26/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
On 26.06.2007 17:01, Peter Hunsberger wrote:
>> > And what some other people here seem to ignore is the increasing cost
>> > for our community to stay behind the rest of the world.
>> >
>> > And, BTW, what is your take on our Continuum proble
Joerg Heinicke skrev:
On 15.06.2007 09:32, Daniel Fagerstrom wrote:
And what some other people here seem to ignore is the increasing cost
for our community to stay behind the rest of the world.
And, BTW, what is your take on our Continuum problems?
Daniel, I don't think it makes any sense t
On 26.06.2007 17:01, Peter Hunsberger wrote:
> And what some other people here seem to ignore is the increasing cost
> for our community to stay behind the rest of the world.
>
> And, BTW, what is your take on our Continuum problems?
Daniel, I don't think it makes any sense to discuss this anym
On 6/25/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
On 15.06.2007 09:32, Daniel Fagerstrom wrote:
> And what some other people here seem to ignore is the increasing cost
> for our community to stay behind the rest of the world.
>
> And, BTW, what is your take on our Continuum problems?
Daniel
On 26.06.2007 01:45, Grzegorz Kossakowski wrote:
Joerg, let it be a consensus. However, don't be angry that I'll bring
this issue back again shortly after 2.2 is released. :-)
I'm not angry about the topic itself or won't be when it is put back
onto the table for the next major or minor relea
Joerg Heinicke pisze:
On 15.06.2007 09:32, Daniel Fagerstrom wrote:
And what some other people here seem to ignore is the increasing cost
for our community to stay behind the rest of the world.
And, BTW, what is your take on our Continuum problems?
Daniel, I don't think it makes any sense t
On 15.06.2007 09:32, Daniel Fagerstrom wrote:
And what some other people here seem to ignore is the increasing cost
for our community to stay behind the rest of the world.
And, BTW, what is your take on our Continuum problems?
Daniel, I don't think it makes any sense to discuss this anymore.
Joerg Heinicke skrev:
Well, for what it's worth (which isn't much) I for one am glad
Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US
datacentre is getting their act together so my team can plan to
migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd
about 9 mont
Oliver, I think we will stay at 1.4 Thank your for your feedback. :)
Best Regards,
Antonio Gallardo.
Olivier Billard escribió:
Hello there,
This is my humble case :), but we are planning to use Cocoon 2.2, and
cannot decide (customer does) on Java version, that is strongly likely
to be Java
Hello there,
This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be
Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1
Well, for what it's worth (which isn't much) I for one am glad Cocoon
2.2 still supports JDK 1.4. It's finally looking like our US
datacentre is getting their act together so my team can plan to
migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about
9 months ago!) onto a more re
> From: [EMAIL PROTECTED]
> Date: Fri, 8 Jun 2007 17:16:27 +0100
>
> Hi,
>
> (thanks for the reminder, Daniel - yes, I'd forgotten about the vote)
>
> On 8 Jun 2007, at 00:57, Andrew Stevens wrote:
>
> > Well, for what it's worth (which isn't much) I for one am glad
> > Cocoon 2.2 still supp
Hi,
(thanks for the reminder, Daniel - yes, I'd forgotten about the vote)
On 8 Jun 2007, at 00:57, Andrew Stevens wrote:
Well, for what it's worth (which isn't much) I for one am glad
Cocoon 2.2 still supports JDK 1.4. It's finally looking like our
US datacentre is getting their act togeth
Andrew Stevens escribió:
Date: Thu, 7 Jun 2007 22:37:02 +0200
From: [EMAIL PROTECTED]
Antonio Gallardo skrev:
Grzegorz Kossakowski escribió:
Antonio Gallardo pisze:
Grzegorz Kossakowski escribió:
Am I missing something, but IIRC cocoon 2.2. should compile and run
with j
Andrew Stevens wrote:
For those not remembering, we are waiting for Joerg to retract his veto
against switching to Java 1.5.
In the meantime the benefit of supporting Java 1.4 decreases each day
while the cost of doing so increases ...
/Daniel
Well, for what it's worth (which isn't
> Date: Thu, 7 Jun 2007 13:22:54 +0200
> From: [EMAIL PROTECTED]
>
> Andrew Savory pisze:
> > Hi,
> >
> > On 6 Jun 2007, at 23:23, Grzegorz Kossakowski wrote:
> >
> >> It's notable that Continuum has not informed us about incompatibility
> >> because it also runs newer Java version (1.5 AFAIR)
> Date: Thu, 7 Jun 2007 22:37:02 +0200
> From: [EMAIL PROTECTED]
>
> Antonio Gallardo skrev:
> > Grzegorz Kossakowski escribió:
> >> Antonio Gallardo pisze:
> >>> Grzegorz Kossakowski escribió:
> >>>
> >>> Am I missing something, but IIRC cocoon 2.2. should compile and run
> >>> with java 1.4. I
Antonio Gallardo skrev:
Grzegorz Kossakowski escribió:
Antonio Gallardo pisze:
Grzegorz Kossakowski escribió:
Am I missing something, but IIRC cocoon 2.2. should compile and run
with java 1.4. Is this correct?
Yes, even though it seems that only few souls living in solitude use
Java 1.4 th
Vadim Gritsenko pisze:
I have this great idea for a build system using Ant
I'm intrigued... Tell me more?!
:-P
Don't even try to approach to Pandora's box! :-P
--
Grzegorz Kossakowski
Andrew Savory wrote:
Hi,
On 7 Jun 2007, at 12:52, Grzegorz Kossakowski wrote:
Andrew Savory pisze:
Hi,
On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote:
This time it's problem at your side, you use a broken mirror.
mirrors.dotsrc.org seems to be not synchronized correctly with
repo1.mave
Hi,
On 7 Jun 2007, at 12:52, Grzegorz Kossakowski wrote:
Andrew Savory pisze:
Hi,
On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote:
This time it's problem at your side, you use a broken mirror.
mirrors.dotsrc.org seems to be not synchronized correctly with
repo1.maven.org where xreporte
Andrew Savory pisze:
Hi,
On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote:
This time it's problem at your side, you use a broken mirror.
mirrors.dotsrc.org seems to be not synchronized correctly with
repo1.maven.org where xreporter artifacts can be found.
Urrgh :-(
(insert rant abou
Hi,
On 7 Jun 2007, at 12:21, Grzegorz Kossakowski wrote:
This time it's problem at your side, you use a broken mirror.
mirrors.dotsrc.org seems to be not synchronized correctly with
repo1.maven.org where xreporter artifacts can be found.
Urrgh :-(
(insert rant about stupid maven and l
Andrew Savory pisze:
Hi,
On 6 Jun 2007, at 23:23, Grzegorz Kossakowski wrote:
It's notable that Continuum has not informed us about incompatibility
because it also runs newer Java version (1.5 AFAIR).
Hmm, perhaps continuum should use the minimum version of java that we
support?
We use sh
Andrew Savory pisze:
Hi,
On 6 Jun 2007, at 23:52, Grzegorz Kossakowski wrote:
Should be working again. Test, please.
Yes, that particular problem is fixed.
Meanwhile (sorry, don't have time right now to find a fix for the below):
INFO]
-
Hi,
On 6 Jun 2007, at 23:52, Grzegorz Kossakowski wrote:
Should be working again. Test, please.
Yes, that particular problem is fixed.
Meanwhile (sorry, don't have time right now to find a fix for the
below):
INFO]
---
Hi,
On 6 Jun 2007, at 23:23, Grzegorz Kossakowski wrote:
It's notable that Continuum has not informed us about
incompatibility because it also runs newer Java version (1.5 AFAIR).
Hmm, perhaps continuum should use the minimum version of java that we
support?
(Accidents like this aside, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Savory wrote:
> Hi,
>
> Trying to build Cocoon 2.2 trunk:
>
> rm -rf ~/.m2/repository/org/apache
> mvn clean
> mvn install -Dmaven.test.skip=true -P allblocks
>
> [ snip ]
>
> [INFO]
> --
Andrew Savory pisze:
Hi,
Trying to build Cocoon 2.2 trunk:
rm -rf ~/.m2/repository/org/apache
mvn clean
mvn install -Dmaven.test.skip=true -P allblocks
[INFO]
[ERROR] BUILD FAILURE
[INFO]
--
Grzegorz Kossakowski pisze:
I'm all for setting Java 1.5 as minimal but it's not my priority to
argue on this forever. There are more interesting things to do like
fixing COCOON-2066. :-)
It's notable that Continuum has not informed us about incompatibility because
it also runs newer Java v
Antonio Gallardo pisze:
Grzegorz Kossakowski escribió:
Antonio Gallardo pisze:
Grzegorz Kossakowski escribió:
Am I missing something, but IIRC cocoon 2.2. should compile and run
with java 1.4. Is this correct?
Yes, even though it seems that only few souls living in solitude use
Java 1.4 th
Grzegorz Kossakowski escribió:
Antonio Gallardo pisze:
Grzegorz Kossakowski escribió:
Am I missing something, but IIRC cocoon 2.2. should compile and run
with java 1.4. Is this correct?
Yes, even though it seems that only few souls living in solitude use
Java 1.4 these days...
Not my case,
Antonio Gallardo pisze:
Grzegorz Kossakowski escribió:
Am I missing something, but IIRC cocoon 2.2. should compile and run with
java 1.4. Is this correct?
Yes, even though it seems that only few souls living in solitude use Java 1.4
these days...
I'm already working on the solution that Dani
Grzegorz Kossakowski escribió:
Let me guess, you use Java 1.4? In Java 1.4 ThreadLocal does not have
remove() method and that's why the build fails. I have no idea how to
fix it, though.
Am I missing something, but IIRC cocoon 2.2. should compile and run with
java 1.4. Is this correct?
Be
On 06.06.2007 22:39, Grzegorz Kossakowski wrote:
Let me guess, you use Java 1.4? In Java 1.4 ThreadLocal does not have
remove() method and that's why the build fails. I have no idea how
to fix it, though.
set(null)? As long as we have no initialValue() it is easy.
Joerg
Andrew Savory pisze:
Hi,
Trying to build Cocoon 2.2 trunk:
rm -rf ~/.m2/repository/org/apache
mvn clean
mvn install -Dmaven.test.skip=true -P allblocks
[...]
/Users/savs/Development/svn-apache/cocoon-trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoo
Hi,
Trying to build Cocoon 2.2 trunk:
rm -rf ~/.m2/repository/org/apache
mvn clean
mvn install -Dmaven.test.skip=true -P allblocks
[ snip ]
[INFO]
[INFO] Building Cocoon Servlet Service Implementation
[IN
Joern Nettingsmeier wrote:
vadim,
Vadim Gritsenko wrote:
Yes it's a known problem. Please bear with me (us? :), I'll try to fix
it as soon as I can...
thanks for your quick reply. i rest assured that the problem is in
capable hands :)
in case it turns out to be a hard problem or you are sh
On 05.04.2007 18:09, Joern Nettingsmeier wrote:
in case it turns out to be a hard problem or you are short on time,
could you tell me at which revision the issue was introduced, so that i
can roll back?
Information can be found at http://marc.info/?t=11753452452&r=1&w=4.
Regards
Jörg
vadim,
Vadim Gritsenko wrote:
Yes it's a known problem. Please bear with me (us? :), I'll try to fix
it as soon as I can...
thanks for your quick reply. i rest assured that the problem is in
capable hands :)
in case it turns out to be a hard problem or you are short on time,
could you tell
Jörn Nettingsmeier wrote:
hi everyone!
i've just updated my lenya tree, and the servlet engine bails out on
startup with this error message:
org.apache.avalon.framework.service.ServiceException: Could not find
component (key
[org.apache.cocoon.template.expression.StringTemplateParser/jxtg])
hi everyone!
i've just updated my lenya tree, and the servlet engine bails out on
startup with this error message:
org.apache.avalon.framework.service.ServiceException: Could not find
component (key
[org.apache.cocoon.template.expression.StringTemplateParser/jxtg])
(Key='org.apache.cocoon.
Well, I created the eclipse project using "mvn eclipse:eclipse". Then I
imported it into my workspace (btw, I ony use the webapp now with the
SitemapServlet) and configured the Jetty Launcher to use my Jetty 5.1.12
installation (that defaults to Servlet 2.4, too) and set the webapp root
to "src
Philipp Zerelles wrote:
I just created a new webapp and block using the archetypes from trunk and I
get the same error when using the Jetty-Eclipse-Plugin to run the webapp:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an ac
I just created a new webapp and block using the archetypes from trunk and I
get the same error when using the Jetty-Eclipse-Plugin to run the webapp:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an actual web request? If you a
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Thanks Carsten and Jörg! After adding the
org.springframework.web.filter.RequestContextFilter, the reloading classloader
(works like the shielded cl) works for me again.
For some reasons the use of the
org.springframework.web.context.request.Req
Reinhard Poetz wrote:
>
> Thanks Carsten and Jörg! After adding the
> org.springframework.web.filter.RequestContextFilter, the reloading
> classloader
> (works like the shielded cl) works for me again.
>
> For some reasons the use of the
> org.springframework.web.context.request.RequestConte
On 27.12.2006 19:05, Reinhard Poetz wrote:
I removed our own implementation in favour of Spring's
RequestContextHolder. The attributes are used to keep track of poolable
components and to release them when the request is finished.
Therefore you should add the Spring's request context listener to
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
On 27.12.2006 13:48, Reinhard Poetz wrote:
Does anybody else see this error message when he tries to use the latest
snapshot from trunk?
java.lang.NullPointerException
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.in
Joerg Heinicke schrieb:
> On 27.12.2006 14:03, Carsten Ziegeler wrote:
>
Line 50 of the PoolableProxyHandler is
RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName,
RequestAttributes.SCOPE_REQUEST);
>
>> I removed our own implementation in fav
On 27.12.2006 14:03, Carsten Ziegeler wrote:
Line 50 of the PoolableProxyHandler is
RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName,
RequestAttributes.SCOPE_REQUEST);
I removed our own implementation in favour of Spring's
RequestContextHolder. The attributes a
Joerg Heinicke wrote:
> On 27.12.2006 13:48, Reinhard Poetz wrote:
>
>> Does anybody else see this error message when he tries to use the latest
>> snapshot from trunk?
>>
>> java.lang.NullPointerException
>> at
>> org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(Po
On 27.12.2006 13:48, Reinhard Poetz wrote:
Does anybody else see this error message when he tries to use the latest
snapshot from trunk?
java.lang.NullPointerException
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50)
Line 50 o
Does anybody else see this error message when he tries to use the latest
snapshot from trunk?
java.lang.NullPointerException
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50)
at $Proxy1.putBackIntoAvalonPool(Unknown Source)
Vadim Gritsenko wrote:
> Hi All,
>
> Noticed that SVN trunk is broken:
>
> $ svn proplist .
> Properties on '.':
> subversion/libsvn_subr/subst.c:643: (apr_err=135000)
> svn: Inconsistent line ending style
It was like that for me recently too.
After doing svn up today, i needed to manually
delet
Hi All,
Noticed that SVN trunk is broken:
$ svn proplist .
Properties on '.':
subversion/libsvn_subr/subst.c:643: (apr_err=135000)
svn: Inconsistent line ending style
All commands - proplist, propset, propget - fail with same message. Examining
contents of .svn/dir-props shows mixed line endi
Sorry, commited to much. It is gone now.
/Daniel
Antonio Gallardo wrote:
Hi Daniel:
In gump.xml there is:
What this means?
Can you review the changes Daniel? The trunk is broken.
Best Regards,
Antonio Gallardo
Hi Daniel:
In gump.xml there is:
What this means?
Can you review the changes Daniel? The trunk is broken.
Best Regards,
Antonio Gallardo
80 matches
Mail list logo
