Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
What does it need to get manual rsync calls working so that 2.2 and
portal docs are available at
http://cocoon.apache.org/2.2/ and
http://cocoon.apache.org/blocks/portal/1.0/
Rsync from where?
From the machine that
Carsten Ziegeler wrote:
Ralph Goers wrote:
My mistake. Portal is dependent upon forms. That dependency was
introduced when the portal tools were committed. However, I don't
believe cron is required.
As I said, cron is needed by the basket sample - if you're not using the
sample, you don't
David Crossley wrote:
Reinhard Poetz wrote:
See the notes at http://forrest.apache.org/proposal-asf-publish.html#notes
Remember that the Proposal is distilling comments from discussions on
[EMAIL PROTECTED] where people were adamant that there be human oversight
at every step in the deployment
Upayavira wrote:
/cocoon/blocks/forms
/cocoon/blocks/forms-samples
/cocoon/blocks/authentication-fw
/cocoon/blocks/authentication-fw-samples
/cocoon/blocks/core-samples
Come on, let's do it. It would simplify so many things dependency-wise.
Let's have the core samples as a block too, because you
It seems Revision *27956*
http://svn.apache.org/viewcvs.cgi?rev=27956view=rev was fixing the
enctype problem, this was removed in Revision *28123*
http://svn.apache.org/viewcvs.cgi?rev=28123view=rev to handle more
generally attributes. I builded with last revision ( Revision *122957*
Carsten Ziegeler wrote:
Ralph Goers wrote:
My mistake. Portal is dependent upon forms. That dependency was
introduced when the portal tools were committed. However, I don't
believe cron is required.
As I said, cron is needed by the basket sample - if you're not using the
sample, you don't
Reinhard Poetz wrote:
As you can see, my vision has nothing to do with Maven, Ant or any other
build tool. Personally, I like Ant more because *I* understand it and I
know exactly what it is doing. *My* personal experience is, that
whenever I used Maven, I ran into problems and it took me
Ralph Goers wrote:
Stefano Mazzocchi wrote:
The more I go around talking about what cocoon is, the more I think
that cforms should not be a block. This also requires the 'template'
system to reside in the core.
So, here is my proposal:
1) move cforms in core
I'd like to hear why you think
Hi,
Reinhard Poetz wrote:
time until it is ready to use. But having a virtual server
is a strong
argument for using Daisy as it could be used without
modifications and the
next release will contain Daisy books to create offline docs (see
Carsten Ziegeler wrote:
Upayavira wrote:
/cocoon/blocks/forms
/cocoon/blocks/forms-samples
/cocoon/blocks/authentication-fw
/cocoon/blocks/authentication-fw-samples
/cocoon/blocks/core-samples
Come on, let's do it. It would simplify so many things
dependency-wise. Let's have the core samples as a
On 23 Feb 2005, at 08:53, Reinhard Poetz wrote:
The best solution IMO ... as the online-editing sceanrio will take
some time until it is ready to use. But having a virtual server is a
strong argument for using Daisy as it could be used without
modifications and the next release will contain
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
snip/
So, here is my proposal:
1) move cforms in core
Absolutely a core block but not into core
2) stop considered 'alpha' and decide to release it when cocoon 2.2
is ready (how far are we from stabilizing cforms anyway?)
+1
3) rename
Giacomo Pati wrote:
Reinhard Poetz wrote:
As you can see, my vision has nothing to do with Maven, Ant or any
other build tool. Personally, I like Ant more because *I* understand
it and I know exactly what it is doing. *My* personal experience is,
that whenever I used Maven, I ran into
Daniel Fagerstrom wrote:
The main thing left to do in the invoker is to get rid of the code for
handling macros in the StartElement part of execute. My idea there is to
create a class that implements StartInstruction and contains all the
macro creation and execution code. So it is such classes
Steven Noels wrote:
On 23 Feb 2005, at 08:53, Reinhard Poetz wrote:
The best solution IMO ... as the online-editing sceanrio will take
some time until it is ready to use. But having a virtual server is a
strong argument for using Daisy as it could be used without
modifications and the next
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
The main thing left to do in the invoker is to get rid of the code
for handling macros in the StartElement part of execute. My idea
there is to create a class that implements StartInstruction and
contains all the macro creation and execution code.
Carsten Ziegeler wrote:
Do we have a solid contract for our flow context object?
The FlowContextHelper returns an object, so e.g. in the jxtg we
have something like:
if (contextObject instanceof Map) {
map.putAll((Map)contextObject);
} else if ( contextObject != null )
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
The main thing left to do in the invoker is to get rid of the code
for handling macros in the StartElement part of execute. My idea
there is to create a class that implements StartInstruction and
contains all the macro
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
The main thing left to do in the invoker is to get rid of the code
for handling macros in the StartElement part of execute. My idea
there is to create a class that implements StartInstruction and
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=33710.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Leszek Gawron wrote:
A cosmetic change but:
1. gives better encapsulation and Event based classes do not look that
stupid anymore (some of them were totally empty just to be matched by
instanceof)
2. Invoker looks much cleaner
The only thing that might be against is that instead of if else if
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
The main thing left to do in the invoker is to get rid of the
code for handling macros in the StartElement part of execute. My
idea there is to create a class
Carsten Ziegeler wrote:
|
I think that the recent discussions over the last weeks showed that
there isn't an opposition against maven here anymore. So, go ahead :)
Carsten
OK. It will take me a couple of weeks as I have to do this in my
infinite spare time, but I'll keep you all informed.
Ralph
On Wed, 23 Feb 2005 12:05:21 +0100, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Ralph Goers wrote:
Stefano Mazzocchi wrote:
The more I go around talking about what cocoon is, the more I think
that cforms should not be a block. This also requires the 'template'
system to reside in the
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
The main thing left to do in the invoker is to get rid of the
code for handling macros in the StartElement part of execute. My
idea
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
snip/
So, here is my proposal:
1) move cforms in core
Absolutely a core block but not into core
2) stop considered 'alpha' and decide to release it when cocoon 2.2
is ready (how far are we from stabilizing cforms
Peter Hunsberger wrote:
On Wed, 23 Feb 2005 12:05:21 +0100, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Ralph Goers wrote:
Stefano Mazzocchi wrote:
The more I go around talking about what cocoon is, the more I think
that cforms should not be a block. This also requires the 'template'
system to
Sylvain Wallez wrote:
Just like other people, I think distinguishing core blocks is a good
thing to show people where to look at while still keeping the core small.
I'm sorry, but I think the core block idea is plain wrong and smells
of over componentization.
If we *all* agree that something is
Reinhard Poetz wrote:
Mark asked me about my vision about blocks. Well, I think, its very
close to that what Stefano proposed 18 month ago.
- A block is a service provider (components, pipelines, flowscripts)
that other blocks can use.
- Blocks can depend on other blocks (use or extend
Peter Hunsberger wrote:
On Wed, 23 Feb 2005 14:54:12 +, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
On Wed, 23 Feb 2005 12:05:21 +0100, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Ralph Goers wrote:
Stefano Mazzocchi wrote:
snip/
I'd like to hear why you think cforms should
Ralph Goers wrote:
Reinhard Poetz wrote:
Mark asked me about my vision about blocks. Well, I think, its very
close to that what Stefano proposed 18 month ago.
- A block is a service provider (components, pipelines, flowscripts)
that other blocks can use.
- Blocks can depend on other blocks
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Just like other people, I think distinguishing core blocks is a good
thing to show people where to look at while still keeping the core small.
I'm sorry, but I think the core block idea is plain wrong and smells
of over componentization.
If we
Stefano Mazzocchi wrote:
Ralph Goers wrote:
...
I'd like to hear why you think cforms should not be a block.
Because having it as a block makes it really hard to answer the
question: what is cocoon and what does it provide me.
Hmmm...
I think it's useful to have a list of things that cocoon comes
Stefano Mazzocchi wrote:
Peter Hunsberger wrote:
On Wed, 23 Feb 2005 14:54:12 +, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
On Wed, 23 Feb 2005 12:05:21 +0100, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Ralph Goers wrote:
Stefano Mazzocchi wrote:
snip/
I'd like to hear why
On Mie, 23 de Febrero de 2005, 9:42, Stefano Mazzocchi dijo:
Sylvain Wallez wrote:
Just like other people, I think distinguishing core blocks is a good
thing to show people where to look at while still keeping the core
small.
I'm sorry, but I think the core block idea is plain wrong and
Reinhard Poetz wrote:
Ralph Goers wrote:
2. The cob. This would merge the block jar and the sample into an
installable or deployable block.
I wouldn't call it sample. It's a Cocoon application that provides
pipelines (via sitemap) and flowscripts. We will have to find a better
name than
Antonio Gallardo wrote:
pizza.jar. The project seems to be dead long time ago. There were no
releases since I can remember.
I requested long time ago to remove it. But seems like some people still
used it at that time. I think currenlty people is using the eclipse or the
javac compiler. Currently,
Antonio Gallardo wrote:
pizza.jar. The project seems to be dead long time ago. There were no
releases since I can remember.
I requested long time ago to remove it. But seems like some people still
used it at that time. I think currenlty people is using the eclipse or the
javac compiler. Currently,
Antonio Gallardo wrote:
pizza.jar. The project seems to be dead long time ago. There were no
releases since I can remember.
I requested long time ago to remove it. But seems like some people still
used it at that time. I think currenlty people is using the eclipse or the
javac compiler. Currently,
Hi:
Yesterday, on the user list was a post for a link of a project that use a
Collaborative License. This kind of license is not OSI aproved. I read
about this license and for my eyes is a closed source license.
We currently have this page:
http://cocoon.apache.org/link/projects.html
The
Ralph Goers wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
2. The cob. This would merge the block jar and the sample into an
installable or deployable block.
I wouldn't call it sample. It's a Cocoon application that provides
pipelines (via sitemap) and flowscripts. We will have to find a
Antonio Gallardo wrote:
pizza.jar. The project seems to be dead long time ago. There were no
releases since I can remember.
I requested long time ago to remove it. But seems like some people still
used it at that time. I think currenlty people is using the eclipse or the
javac compiler. Currently,
On 23 Feb 2005, at 17:12, Antonio Gallardo wrote:
The question is: we can allow software using non-OSI license to be
linked
from our site? To me the asnwer is a clear NO.
Why not? The core of our license beliefs as laid out in the Apache
license is the peaceful cohabitation between the open
Antonio Gallardo wrote:
On Mie, 23 de Febrero de 2005, 10:09, Reinhard Poetz dijo:
Antonio Gallardo wrote:
pizza.jar. The project seems to be dead long time ago. There were no
releases since I can remember.
I requested long time ago to remove it. But seems like some people still
used it at that
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Do we have a solid contract for our flow context object?
The FlowContextHelper returns an object, so e.g. in the jxtg we
have something like:
if (contextObject instanceof Map) {
map.putAll((Map)contextObject);
} else if (
Antonio Gallardo wrote:
The question is: we can allow software using non-OSI license to be linked
from our site? To me the asnwer is a clear NO. But I want to ping
community to be sure that this is the correct decision. ;-)
WDYT?
Frankly, it never would have occurred to me that each of the
Antonio Gallardo wrote:
On Mie, 23 de Febrero de 2005, 10:09, Reinhard Poetz dijo:
+1 for removing it in trunk, in 2.1 we should deprecate it
+1
Vadim
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=28973.
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=28973.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Mie, 23 de Febrero de 2005, 9:43, Ralph Goers dijo:
Reinhard Poetz wrote:
Mark asked me about my vision about blocks. Well, I think, its very
close to that what Stefano proposed 18 month ago.
- A block is a service provider (components, pipelines, flowscripts)
that other blocks can
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=33537.
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=33462.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi Stefano,
On Wed, 23 Feb 2005 17:01:41 +0100, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Paul Russell wrote:
So, let me know what you think! Am I mad? Is this a bad/good idea?
What have I missed? Is this something we should take further, or just
a distraction?
Paul,
first of all, I
On Thursday 24 February 2005 00:09, Ralph Goers wrote:
Unless we radically rearchitect how these things are
configured, there is no way to ship a block in a format that doesn't
have to be tailored.
Isn't this all about the long-winded SoC principles, along the axis of
'users'?
On Thursday 24 February 2005 00:01, Stefano Mazzocchi wrote:
I'm interested in solving real problems in the simplest possible way,
even if they end up feeling hacky at times.
And wasn't you just a few days ago warning against Cocoon crumbling under its
own burden?? (burden I assume == simplest
Currently scratchpad depends on XSP, but I can't find anything in
scratchpad that might use XSP. Am I just blind or is this an obsolete
dependency (which would be great as it is the last dependency on XSP -
apart from python).
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
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=25712.
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=25712.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Currently scratchpad depends on XSP, but I can't find anything in
scratchpad that might use XSP. Am I just blind or is this an obsolete
dependency (which would be great as it is the last dependency on XSP -
apart from python).
Carsten
Is that true? I noticed a check-in
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=33319.
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=33319.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Ralph Goers wrote:
Carsten Ziegeler wrote:
Currently scratchpad depends on XSP, but I can't find anything in
scratchpad that might use XSP. Am I just blind or is this an obsolete
dependency (which would be great as it is the last dependency on XSP -
apart from python).
Carsten
Is that true? I
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't think this should break much code, as that object (which BTW I
prefer to name view data rather than the ambiguous flow context --
we have enough contexts in Cocoon) is supposed to be a JS object. And
a JS object can easily be turned into a
Guys,
I see that there are changes which are (possibly) not applied to the trunk.
Please take a look at these, and reconcile:
- action dev=AG type=add
- Add lt;compiler-compliance-levelgt; parameter for java XSP compiler.
- This new parameter allow to specify the java code source
On Mie, 23 de Febrero de 2005, 16:02, Vadim Gritsenko dijo:
Hi all,
I'd like to propose following plan towards stable OJB block. Currently,
OJB
block has:
* OJB Logging integration with Cocoon logger
* OJB Connection pooling integration with Cocoon datasources
*
My company GeoSmart, www.geosmart.co.nz, is looking to hire another
developer to work on the development of our Location Based Services
platform. Our software provides intelligent mapping and routing services
through multiple channels and to multiple devices. The system is, of course,
implemented
On Thu, 24 Feb 2005 03:04:08 +0800, Niclas Hedhman [EMAIL PROTECTED] wrote:
[...]
But I am also with you that SilkWorm is a far too big step, which never will
get enough momentum to fly around here. But it IS fun to speculate, discuss
wild ideas and so on... All kids are setting out to
Le 23 févr. 05, à 15:54, Upayavira a écrit :
...I would even go a bit further - once we've got our blocks system
fully in place, we could have two distributions - core and complete...
+1 for the idea, assuming it's not too much work for the managing
releases.
-Bertrand
smime.p7s
Description:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't think this should break much code, as that object (which BTW
I prefer to name view data rather than the ambiguous flow context
-- we have enough contexts in Cocoon) is supposed to be a JS object.
And a JS object can
69 matches
Mail list logo
