--- Joerg Heinicke [EMAIL PROTECTED] schrieb:
On 17.08.2005 11:22, Andrew Stevens wrote:
Although as a mere user my vote probably doesn't
count,
It's a so-called non-binding vote, but your opinion
is important though.
from my
perspective I'm extremely grateful that Cocoon
still
Ralph Goers wrote:
Well, I see blocks a little differently. For example, in the portal
block you want to build the block independently of the portal
configuration (at least I do). I want the block available to someone
who wants to create a portal. They then take the portal block and
Vadim Gritsenko schrieb:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out of our download.
Ralph Goers wrote:
The only concern I would have in bringing CoWarp into Cocoon (beside the
name making me think it is an add-on for OS/2 :-) ) is that I'd want to
evaluate it against using acegi as the standard authentication
mechanism. Having said that, I have no familiarity with CoWarp and
if the request isn't the
standard wrapper class...
Andrew.
From: Vadim Gritsenko [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: CoWarp (was Re: svn commit: r232855...)
Date: Tue, 16 Aug 2005 23:27:30 -0400
Antonio Gallardo wrote:
If ..., I will like
Leszek Gawron wrote:
Acegi is a very robust framework. Although the author states it could be
used without Spring [1] he strongly encourages not to :). I quite got
the point when I implemented the first application context which just
secures a single method in a dummy business service:
Andrew Stevens schrieb:
Besides, wouldn't something like that justify a bigger change in version
number i.e. if you're going to drop it, do it in 2.2? Also, when you do
drop the 1.3 support, why not drop the servlet 2.2 support as well and start
using standard
That is a lot of Spring definitions. Frankly, I suspect that to use
Acegi we would require something like CoWarp in front of it anyway. The
thing is, we ended up writing something like Acegi for our use and it
would be nice to use an open source framework instead.
I looked at CoWarp last
Ralph Goers schrieb:
That is a lot of Spring definitions. Frankly, I suspect that to use
Acegi we would require something like CoWarp in front of it anyway. The
thing is, we ended up writing something like Acegi for our use and it
would be nice to use an open source framework instead.
hepabolu wrote:
I came across XACML (by OASIS) [1] and it's implementation by Sun [2].
Priorities changed and I haven't looked into it further, but this at
least doesn't rely on Spring. Maybe something to consider.
I've heard about XACML too. IMHO CAuth should support XACML as one of the
Carsten Ziegeler wrote:
Vadim Gritsenko schrieb:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
Vadim Gritsenko wrote:
Antonio Gallardo wrote:
/me hoping we can also create a shell script that will be able to
download maven before maven start to build cocoon. ;-)
You mean script should download maven source, build it, and start maven?
Sounds good... and if this script uses ant, it
On 17.08.2005 11:22, Andrew Stevens wrote:
Although as a mere user my vote probably doesn't count,
It's a so-called non-binding vote, but your opinion is important though.
from my
perspective I'm extremely grateful that Cocoon still supports 1.3 and
hope that remains the case for the 2.1.x
Carsten Ziegeler wrote:
For the demo portal, I replaced the authentication framework with CoWarp
which provides imho a much nicer and cleaner way for plugging in your
authentication mechanism.
CoWarp is a 35 kb jar file containing 25 classes which seem highly tied
to Cocoon and Avalon. Do
Sylvain Wallez schrieb:
Carsten Ziegeler wrote:
For the demo portal, I replaced the authentication framework with CoWarp
which provides imho a much nicer and cleaner way for plugging in your
authentication mechanism.
CoWarp is a 35 kb jar file containing 25 classes which seem highly
On 16 Aug 2005, at 11:27, Carsten Ziegeler wrote:
And I think currently we have way too many blocks and adding another
one
makes Cocoon even complexer. It seems everyone who has a good idea just
adds another block (with no or minimal community). Just adding a jar
dependency is much simpler
Carsten Ziegeler wrote:
And I think currently we have way too many blocks and adding another one
makes Cocoon even complexer. It seems everyone who has a good idea just
adds another block (with no or minimal community). Just adding a jar
dependency is much simpler from the complexity point of
Carsten Ziegeler wrote:
Sylvain Wallez schrieb:
Carsten Ziegeler wrote:
For the demo portal, I replaced the authentication framework with CoWarp
which provides imho a much nicer and cleaner way for plugging in your
authentication mechanism.
CoWarp is a 35 kb jar file containing
Sylvain Wallez wrote:
It's not really here about adding a new block, but about providing a
simple and unified way of solving a common problem in Cocoon, which the
current pipeline-based auth-framework doesn't seem to solve (I
personally never used it).
The interfaces could be in core,
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
snip/
Hmm... chicken and egg. How can one create a community around a one
man show hosted as SF.net? Furthermore, can there be a community
around a bunch of interface and their default implementations?
There can at least be community
Daniel Fagerstrom wrote:
Thinking further about it, I completely agree about that we have to many
blocks rigth now. But that is not an argument against adding more,
rather about removing or at least make optional, blocks that lacks
community support. You might remember
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out of our download.
Ralph
Carsten Ziegeler wrote:
If there is *high* community interest in hosting it at Apache I'm willing to
move. In fact, lack of a community was one of the main reasons in
creating Cowarp outside of Apache.
I have no idea how to become part of a community at sourceforge. Most
seem to have no
Ralph Goers schrieb:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out of our download.
I think we
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
need
to get the 3rd party jars out of our download.
I think we should start removing the links to the blocks from
Carsten Ziegeler wrote:
Ralph Goers schrieb:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out of our download.
-1: Complete download
Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
need to get the 3rd party jars out of our
On 16.08.2005, at 17:31, Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A
royal PITA. Unfortunately, I also think it is very necessary. We
really need to get the 3rd
Ralph Goers wrote:
Vadim Gritsenko wrote:
Ralph Goers wrote:
We really need to get the 3rd party jars out of our download.
-1: Complete download must stay.
Out of curiosity, why?
Comparing lots of other software out there, Cocoon is among the best one with
regards to the effort needed
Torsten Curdt wrote:
I also think we should get rid of this huge
amount of jars.
0: Does not bother me but whatever :-)
It should be a piece of cake to build a full
distribution with all dependencies and provide
that to make people like Vadim happy :)
That's my point exactly; do whatever
Torsten Curdt wrote:
So let's switch Cocoon to Maven ;-)
+1
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really need
to get the 3rd party jars out of our download.
+1, but using maven should not stop us
Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
need to get the 3rd party jars out of our
Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
need to get the 3rd party jars out of our
Torsten Curdt wrote:
On 16.08.2005, at 17:31, Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
I am often working using a lousy GPRS internet connection (like
now :)). I download big things while connected to LAN and I need
to be sure that I have all deps fetched when going on holiday. If
I had to fetch all dependencies manually (and not only from cocoon)
I would always miss
Leszek Gawron wrote:
-(-(-1)) ! :)
I am often working using a lousy GPRS internet connection (like now
:)). I download big things while connected to LAN and I need to be
sure that I have all deps fetched when going on holiday. If I had to
fetch all dependencies manually (and not only from
Torsten Curdt wrote:
I am often working using a lousy GPRS internet connection (like now
:)). I download big things while connected to LAN and I need to be
sure that I have all deps fetched when going on holiday. If I had
to fetch all dependencies manually (and not only from cocoon) I
On 16.08.2005 17:51, Vadim Gritsenko wrote:
Comparing lots of other software out there, Cocoon is among the best one
with regards to the effort needed to get up and running. All you need is:
download/unzip
build.bat
cocoon.bat
No need to fight with dependency-fetching-tools, hunt for
On 16.08.2005 15:04, Carsten Ziegeler wrote:
It's not really here about adding a new block, but about providing a
simple and unified way of solving a common problem in Cocoon, which the
current pipeline-based auth-framework doesn't seem to solve (I
personally never used it).
The interfaces
Joerg Heinicke wrote:
On 16.08.2005 15:04, Carsten Ziegeler wrote:
It's not really here about adding a new block, but about providing a
simple and unified way of solving a common problem in Cocoon, which
the current pipeline-based auth-framework doesn't seem to solve (I
personally never used
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez schrieb:
Carsten Ziegeler wrote:
For the demo portal, I replaced the authentication framework with
CoWarp
which provides imho a much nicer and cleaner way for plugging in your
authentication mechanism.
CoWarp is a 35
Antonio Gallardo wrote:
If ..., I will like to propose for the next cocoon 2.1.x
release to set the monimal JVM requirement to 1.4.
Can I start a vote about moving to 1.4?
-1 for change of JVM requirement in the 2.1.8 release, which should be released
ASAP anyway - it is delayed too much
43 matches
Mail list logo
