Yeah, the Win32 client used to have all kinds of / vs. \ issues and they
tended to break the build a lot. However, nowadays, the windows client (at
least the command line one, which is what I first thought you meant) works
quite well. RapidSVN (a Win32 GUI) is probably buggy as all hell still.
Robert Simmons wrote:
Uhh .. I dont get how that FAQ answers me. I dont need the pretty print in
production, just in development. It would be cool if I could use a cocoon view
to do it.
This would be more to the point:
http://cocoon.apache.org/2.1/userdocs/serializers/xml-serializer.html
See
Getting the ball rolling on Phase One...
Stefano Mazzocchi wrote:
This is a collection of (more or less) random thoughts about the
implementation of Cocoon Blocks that I collected while talking with
Ricardo and Sylvain IRL.
Please note that anything proposed here, while organic and workable,
Sascha-Matthias Kulawik said:
we've developed a XML-based Content Management System based on
different technologies like Cocoon, XML, EJB and a WebStart Client
Application. It is in our interest, that we contribute this
project with about 200.000 Lines of Code to the Apache Foundation.
To
Hi all,
the recent comments about production build and binary builds have
caused me to think about Cocoon Distros and what must core Cocoon do
to allow for Cocoon Distros from 3rd parties.
Since this overlap quite a degree with the average Cocoon user's
need of upgrade running systems, I think
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22809.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Niclas Hedhman wrote, On 29/08/2003 6.51:
Sascha-Matthias Kulawik said:
we've developed a XML-based Content Management System based on
different technologies like Cocoon, XML, EJB and a WebStart Client
Application. It is in our interest, that we contribute this
project with about 200.000 Lines
On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul wrote:
Which is the whole point of my mail. Don't use dependency ranges, use
metadata specifying capabilities and requirements for this.
I think you greatly underestimate the complexity of the approach you
are proposing.
Last
On Wednesday, Aug 27, 2003, at 14:39 Europe/Rome, Berin Loritsch wrote:
[snip]
I would start with something like this, and see how far it can take
you--and
if there are new features required, add them.
This is (more or less) what I was planning to implement ;-)
--
Stefano.
On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi
wrote:
Calling a resource, inserting a virtual pipeline and using the
cocoon: protocol are for most uses equivalent.
I agree when you say that since the introduction of the cocoon:
protocol, map:resource is now redundant (and
Codehaus is another community, I'm sure its rules aren't exactly the
same. The information on the web site claims to place a firm priority
on the production of useful code, and less on non-coding exercises such
as voting, committee-forming and proposal-writing. Why would that have
an affect
You've read my mind, didn't you? ;-)
Seriously, I think you've brought many things down to the point.
Specifically the security issues you've mentioned were given too less
attention before.
Good work, I like it!
-- Andreas
Niclas Hedhman wrote:
Hi all,
the recent comments about production
Antonio Gallardo wrote:
Andrew Savory dijo:
On Fri, 29 Aug 2003, Antonio Gallardo wrote:
It seems like our server daedalus.apache.org is being blocked by the
black-hole list http://relays.osirusoft.com/.
The osirusoft black-hole list has been shut down due to a denial of
service
On Thu, 2003-08-28 at 08:12, Carsten Ziegeler wrote:
Hi,
as several of you have already pointed out, a 2.1.1 release seems
to make sense.
I can make a release next week, but I really would like to have the
scheduling (CommandManager) problem fixed in the release. Is anyone
working
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move already in bugzilla:
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move already in bugzilla:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move
Vadim Gritsenko wrote:
2.1.1, +1.
Or should it be 2.1.2? I thought you are going to release 2.1.1 Really
Soon Now? btw, what about 2.0.5?
:), yepp, we will see, we could rephrase it to 2.1.x then. I will not
release 2.1.1 without a fix for the event handling (commandmanager) bug.
It
Stefano Mazzocchi wrote, On 28/08/2003 17.27:
On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote:
Calling a resource, inserting a virtual pipeline and using the
cocoon: protocol are for most uses equivalent.
I agree when you say that since the introduction of the cocoon:
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move already in bugzilla:
On 29.Aug.2003 -- 02:20 PM, Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for
On Thursday, Aug 28, 2003, at 15:47 Europe/Rome, Niclas Hedhman wrote:
Nicola Ken Barozzi said:
Berin, I think that Robert has a valid point here, and that is
similar to what Avalon said about Logkit and Log4j.
When I was still in Avalon, Avalon had informally agreed to push
Logkit EOL in favor
I'll be offline for 2 weeks starting from now.
--
Stefano.
On Friday, Aug 29, 2003, at 08:12 Europe/Rome, Niclas Hedhman wrote:
Hi all,
the recent comments about production build and binary builds have
caused me to think about Cocoon Distros and what must core Cocoon do
to allow for Cocoon Distros from 3rd parties.
[snip]
*everything* about ease of
On Thursday, Aug 28, 2003, at 20:00 Europe/Rome, Jay Freeman ((saurik))
wrote:
So my eye finally caught on the Starting 2.2 thread today, it seemed
interesting, and I went to read through this... and I must say the main
reaction I ended up having to it is HUH?!?. :)
Is the reason you need a new
Stefano Mazzocchi wrote:
Carsten, forget beauty of versioning and let's start working on
cocoon-2.1 HEAD, this will:
1) reduce effort and duplication
2) keep people sane since every commit will have to keep the tree in
shape (it's entirely possible to implement real blocks with what
Have a look at this thread:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106189194527050w=2
and this bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131
Now, it seems that the CommandManager is not working in all environments.
In my it's not working but I don't have the shutdown
Lets try to fix the first issue on your list.
The last target in src/targets/webapp-build.xml is custom-conf.
This is the only place the customconf property is used.
Notice that the customconf property is applied to the included
filename, not to the srcdir attribute:
xpatch
Carsten Ziegeler wrote:
joke
Ah, btw. I will replace ECM with fortress over the weekend. Any problems
with that?
/joke
Don't tease me... Want I should do it?
--
They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-
upayavira2003/08/29 07:05:50
Modified:src/java/org/apache/cocoon/bean CocoonBean.java
Log:
Removing printing of timestamp - will re-add it properly by extending the
BeanListener interface
Revision ChangesPath
1.19 +3 -1
Berin Loritsch wrote:
joke
Ah, btw. I will replace ECM with fortress over the weekend. Any problems
with that?
/joke
Don't tease me... Want I should do it?
Hey, great!
I'm definitly +5 for this! So if you want to do it, you could start a vote
and see what will happen next...
On Fri, 2003-08-29 at 15:35, Berin Loritsch wrote:
Bruno Dumon wrote:
On Thu, 2003-08-28 at 08:12, Carsten Ziegeler wrote:
Hi,
as several of you have already pointed out, a 2.1.1 release seems
to make sense.
I can make a release next week, but I really would like to have the
Hi all,
I have implement for the Linotype block the editor that also works with
IE versions 5.0
For my self I had test it with MOZ and IE 5.0, 6.0
and here are some of the main changes:
- the image names on upload
there was an problem withe the name geneartion of the images
the old one
Klaus Bertram wrote:
Hi all,
I have implement for the Linotype block the editor that also works with
IE versions 5.0
For my self I had test it with MOZ and IE 5.0, 6.0
and here are some of the main changes:
- the image names on upload
there was an problem withe the name geneartion of the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22813.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=22813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
joke
Ah, btw. I will replace ECM with fortress over the weekend. Any problems
with that?
Yep. Aren't we supposed to use Merlin instead? I'm checking in the code
as we speak...
/joke
Vadim
...and please vote if this is a change for 2.1.1 or 2.2.
+1 for 2.1.1
-Bertrand
Geoff Howard wrote:
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
...
Ok, great. Does anybody have a problem with the proposed file
system layout?
AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories:
By default - but as I understood Stefano's last email, it should be
The new Cocoon should be able to use the new Fortress container. This should
have little to no impact on component writers. It boasts faster startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
--
They that give up essential liberty to obtain a
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This
should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1 for you.
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This
should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
I'm scared but I trust you.
From: Berin Loritsch
The new Cocoon should be able to use the new Fortress container.
This should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1 from me too :)
J.
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This
should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1, but I (still) would like
Bertrand Delacretaz wrote:
If I'm right, this would allow Cocoon to proxy most WebDAV operations to
a non-DASL WebDAV backend, and process the few operations that relate to
properties (PROPFIND, PROPPATCH, SEARCH) directly, storing properties in
a database.
This was an itch I just had to
On Fri, 29 Aug 2003, Berin Loritsch wrote:
Bruno Dumon wrote:
On Thu, 2003-08-28 at 08:12, Carsten Ziegeler wrote:
Hi,
as several of you have already pointed out, a 2.1.1 release seems
to make sense.
I can make a release next week, but I really would like to have the
scheduling
On Fri, 29 Aug 2003, Bruno Dumon wrote:
For me it works with Linux/Sun jdk 1.4.2, it doesn't work with 1.3.1.
For Carsten it doesn't work with Windows/jdk 1.4 either. I've done all
my testing with the Jetty which ships with Cocoon.
I've added some println's here and there and it appears
On Fri, 29 Aug 2003, Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move
+1
Carsten
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container.
This should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
Vadim Gritsenko wrote:
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This
should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1,
asavory 2003/08/29 11:54:37
Modified:src/documentation/xdocs/userdocs/generators
search-generator.xml
Log:
Fixing capitalisation
Revision ChangesPath
1.2 +1 -1
cocoon-2.0/src/documentation/xdocs/userdocs/generators/search-generator.xml
asavory 2003/08/29 11:54:50
Modified:src/documentation/xdocs/userdocs/generators
search-generator.xml
Log:
Fixing capitalisation
Revision ChangesPath
1.3 +1 -1
cocoon-2.1/src/documentation/xdocs/userdocs/generators/search-generator.xml
mpo 2003/08/29 15:11:25
Modified:src/blocks/apples/java/org/apache/cocoon/components/flow/apples
ApplesProcessor.java
Log:
Let logging include the continuation id.
Revision ChangesPath
1.5 +3 -2
mpo 2003/08/29 15:12:50
cocoon-2.1/src/blocks/apples/samples/calc - New directory
mpo 2003/08/29 15:22:18
cocoon-2.1/src/blocks/apples/samples/guess - New directory
mpo 2003/08/29 15:22:05
Added: src/blocks/apples/samples/calc getNumberA.xsp
getOperator.xsp getNumberB.xsp displayResult.xsp
src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples
mpo 2003/08/29 15:33:00
Modified:src/blocks/apples/samples sitemap.xmap welcome.xml
Log:
Adding the new samples to the sitemap and the welcome page.
Revision ChangesPath
1.3 +131 -65 cocoon-2.1/src/blocks/apples/samples/sitemap.xmap
Index: sitemap.xmap
Vadim Gritsenko dijo:
FYI:
http://slashdot.org/article.pl?sid=03/08/27/0214238mode=threadtid=111tid=126
Vadim
Thank you for the link :)
Best Regards,
Antonio Gallardo
On Fri, 2003-08-29 at 19:55, Giacomo Pati wrote:
On Fri, 29 Aug 2003, Bruno Dumon wrote:
For me it works with Linux/Sun jdk 1.4.2, it doesn't work with 1.3.1.
For Carsten it doesn't work with Windows/jdk 1.4 either. I've done all
my testing with the Jetty which ships with Cocoon.
I've
Seybold organizers just told me that they want to cancel the
OSCOM hackathon/sprint @ Seybold if there aren't enough participants
which have signed up until tomorrow Friday (western times).
The reason seems to be that room and internet connection are too expensive
for hosting just a few people.
60 matches
Mail list logo
