Automated Cocoon Unit tests failed!
Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20050119.log
Last messages from the log file:
==
[foreach] reader-mime-type.xml:39
After the long thread about splitting cocoon.xconf I can't find the reason, why
wildcard includes in cocoon.xconf are not supported. Any hints, or am I wrong here?
--
Reinhard
Stefano Mazzocchi wrote:
Bertrand Delacretaz wrote:
Le 18 janv. 05, à 09:59, Reinhard Poetz a écrit :
...as *I* have to do it, I'll take the road that's the fastest for
*me*...
+1, whoever does the work gets to decide (and later the community
decides to use the stuff or not, but in this case
Reinhard Poetz wrote:
After the long thread about splitting cocoon.xconf I can't find the
reason, why wildcard includes in cocoon.xconf are not supported. Any
hints, or am I wrong here?
They are supported, have a look at the latest 2.2, you will find a
wildcard include there:
include
It's been a while since I built the trunk last time and I just did an
svn update and tried to build it, but it seems something is broken:
/home/ugo/workspace/cocoon-trunk/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java:25:
package
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
After the long thread about splitting cocoon.xconf I can't find the
reason, why wildcard includes in cocoon.xconf are not supported. Any
hints, or am I wrong here?
They are supported, have a look at the latest 2.2, you will find a
wildcard include
Il giorno 19/gen/05, alle 12:06, Carsten Ziegeler ha scritto:
I just updated trunk and it now uses the improved jar handling from
2.1.x; therefore I had to make some changes to gump.xml; don't know
what gump is saying about it, so be warned if gump chokes.
Now it builds fine. Thanks.
Ugo
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33150.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33150.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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-block-template has an issue affecting its community integration.
This
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-block-portal has an issue affecting its community integration.
This issue
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Bertrand Delacretaz wrote:
Le 18 janv. 05, à 09:59, Reinhard Poetz a écrit :
...as *I* have to do it, I'll take the road that's the fastest for
*me*...
+1, whoever does the work gets to decide (and later the community
decides to use the stuff or
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
After the long thread about splitting cocoon.xconf I can't find the
reason, why wildcard includes in cocoon.xconf are not supported. Any
hints, or am I wrong here?
They are supported, have a look at the latest 2.2, you will find a
wildcard include
Actually, and I'm not joking, I think we should have a hero plate on our
web page and put the name and have a nomination!... some ego stimulation
goes a lng way... h
Wow, employee^H^H^H^H^H^H^H^Hcommitter of the month! Now that would
feel like working at McDonald's :-)
--
Carsten Ziegeler wrote:
I'm currently thinking about making the build system able to include
blocks from external locations, which means blocks that are not
directly in the cocoon directory.
I'm thinking of a simple but working solution: I guess the easiest way
would be to just add the root
Stefano Mazzocchi wrote:
what about reusing the code from the Wildcard matchers and have a
context://WEB-INF/xconf/*.xconf instead? alternatively, the traverse
code is already there... so you just need to do convert the above * into
.* and use a regexp package, voila'...
Yepp, sounds good to
Gianugo Rabellino wrote:
Actually, and I'm not joking, I think we should have a hero plate on our
web page and put the name and have a nomination!... some ego stimulation
goes a lng way... h
Wow, employee^H^H^H^H^H^H^H^Hcommitter of the month! Now that would
feel like working at
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
what about reusing the code from the Wildcard matchers and have a
context://WEB-INF/xconf/*.xconf instead? alternatively, the traverse
code is already there... so you just need to do convert the above *
into .* and use a regexp package, voila'...
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
After the long thread about splitting cocoon.xconf I can't find the
reason, why wildcard includes in cocoon.xconf are not supported. Any
hints, or am I wrong here?
They are supported, have a look at the latest 2.2, you will find a
wildcard include
On Mie, 19 de Enero de 2005, 13:18, Stefano Mazzocchi dijo:
Gianugo Rabellino wrote:
Actually, and I'm not joking, I think we should have a hero plate on our
web page and put the name and have a nomination!... some ego stimulation
goes a lng way... h
Wow,
Stefano Mazzocchi wrote:
Gianugo Rabellino wrote:
Actually, and I'm not joking, I think we should have a hero plate on
our
web page and put the name and have a nomination!... some ego
stimulation
goes a lng way... h
Wow, employee^H^H^H^H^H^H^H^Hcommitter of the month! Now that would
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
what about reusing the code from the Wildcard matchers and have a
context://WEB-INF/xconf/*.xconf instead? alternatively, the traverse
code is already there... so you just need to do convert the above *
into .* and use a
[EMAIL PROTECTED] wrote:
Author: rgoers
Date: Wed Jan 19 11:58:55 2005
New Revision: 125646
URL: http://svn.apache.org/viewcvs?view=revrev=125646
Log:
executor attribute was never being set. Fix NPE.
Modified:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: rgoers
Date: Wed Jan 19 11:58:55 2005
New Revision: 125646
URL: http://svn.apache.org/viewcvs?view=revrev=125646
Log:
executor attribute was never being set. Fix NPE.
Modified:
Sylvain Wallez wrote:
WOAA! ROTFLMAO!!
Dude, discovering this when coming back home from the airport made me
laugh so loud
Now you'll have to do it for each and every Cocoon hero!!! A good way
to recycle all these old comic-book super-heros ;-)
BTW, I saved the picture on my
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: rgoers
Date: Wed Jan 19 11:58:55 2005
New Revision: 125646
URL: http://svn.apache.org/viewcvs?view=revrev=125646
Log:
executor attribute was never being set. Fix NPE.
Modified:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Won't it fail later on here?
final Boolean canRunConcurrentlyB = ((Boolean)
data.get(QuartzJobScheduler.DATA_MAP_RUN_CONCURRENT));
Vadim
No. There are multiple versions of the put method. The one that takes
boolean actually creates a Boolean and
Ralph Goers wrote:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Won't it fail later on here?
final Boolean canRunConcurrentlyB = ((Boolean)
data.get(QuartzJobScheduler.DATA_MAP_RUN_CONCURRENT));
No. There are multiple versions of the put method. The one that takes
boolean actually creates a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33172.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Who knows, maybe I'll convince a professor here at MIT too ;-)
http://www.eli.sdsu.edu/courses/fall04/cs683/notes/index.html
What I like even better is that the instructor (Roger Whitney) seems to
be a hardcore Smalltalk guy (thus the reason why he also teaches
Seaside, which is a web framework
Howdy,
I was browsing around the awesome www.jdocs.org web site and was pleased
to find cocoon there, but your version number is completely bogus.
Cocoon 1.2.5.1 never even existed, I think you mean 2.1.5, which is the
latest released version.
Anyway, thanks much for the service, it's a minor
On Mie, 19 de Enero de 2005, 23:55, Stefano Mazzocchi dijo:
Howdy,
I was browsing around the awesome www.jdocs.org web site and was pleased
to find cocoon there, but your version number is completely bogus.
Cocoon 1.2.5.1 never even existed, I think you mean 2.1.5, which is the
latest
On Mie, 19 de Enero de 2005, 23:09, Stefano Mazzocchi dijo:
Who knows, maybe I'll convince a professor here at MIT too ;-)
http://www.eli.sdsu.edu/courses/fall04/cs683/notes/index.html
What I like even better is that the instructor (Roger Whitney) seems to
be a hardcore Smalltalk guy (thus
Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Howdy,
I was browsing around the awesome www.jdocs.org web site and was pleased
to find cocoon there, but your version number is completely bogus.
Cocoon 1.2.5.1 never even existed, I think you mean 2.1.5, which is the
latest released
I got no response on the user list...so:
We are the same problems outlined in this post to the FOP mailing-list (an
error message from Adobe Reader 7 when opening FOP generated documents):
http://marc.theaimsgroup.com/?l=fop-userm=110554914401671w=2
Does anyone know of a solution?
Thanks
35 matches
Mail list logo
