On 15 Aug 2005, at 16:56, Berin Loritsch wrote:
I'm registered, but I can't add documents in any logical place. Its
not forms or portal related.
It looks like you found out how to edit the navigation tree as well.
Feel free to expand the section you created - if a better place is
found in
Ralph Goers schrieb:
Is there something more detailed about what this enhancement provides?
It sounds interesting.
Not yet. I just started to integrate the portals bridges project, so you
can plugin
your (don't be scared now) JSF, Struts, PHP application as a JSR 168
portlet into
the
Upayavira schrieb:
One point, for general reference: there are negligible differences
between 2.1 and trunk docs. I did a diff across the two versions, and
IIRC I merged the changes, so 2.1 and 'site' is all we need at the
moment, until we want the docs for 2.1 and trunk to diverge.
Il giorno 15/ago/05, alle 20:21, Sylvain Wallez ha scritto:
Fixed! Please cross-check!
Looks good!
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine Food Blog: http://www.divinocibo.it/
Carsten Ziegeler wrote:
Upayavira schrieb:
One point, for general reference: there are negligible differences
between 2.1 and trunk docs. I did a diff across the two versions, and
IIRC I merged the changes, so 2.1 and 'site' is all we need at the
moment, until we want the docs for 2.1 and
hepabolu wrote:
Once that process is done, I want to figure out how to get the info from
Daisy onto the website (preferably through an easier route/procedure
than the current one). If that works, I'm planning on updating the
website once every one or two months, depending on the number of
Hi,
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. I'm currently
thinking of using our hsqldb as the user database (for the
demo). Again if someone wants to do this
On 16 Aug 2005, at 08:48, Carsten Ziegeler wrote:
So, I think, yes, it makes sense to have different versions.
That's variants in Daisy-speak.
See this example: http://cocoondev.org/daisy/13.html and this
explanation:
http://cocoondev.org/daisydocs-1_3/repository/general/155.html
/Steven
Steven Noels wrote:
On 16 Aug 2005, at 08:48, Carsten Ziegeler wrote:
So, I think, yes, it makes sense to have different versions.
That's variants in Daisy-speak.
See this example: http://cocoondev.org/daisy/13.html and this
explanation:
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
hepabolu wrote:
Guys,
I don't know if a vote for this is required, but I'd like to have
consensus/feedback, before I do something drastic.
As written earlier today there are gaps in the current version of the
website, e.g. FAQs are missing. What I'd like to do is restore the
current
Carsten Ziegeler wrote:
Upayavira schrieb:
One point, for general reference: there are negligible differences
between 2.1 and trunk docs. I did a diff across the two versions, and
IIRC I merged the changes, so 2.1 and 'site' is all we need at the
moment, until we want the docs for 2.1 and
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
Upayavira wrote:
Can you remember where these differences occur? In what pages? I'd like
to look at how it is now - I've a feeling I may have edited the pages to
account for this, but would like to see what is actually the case.
Hmm, actually now - there were several. I think I searched
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:
Upayavira wrote:
Can you remember where these differences occur? In what pages? I'd like
to look at how it is now - I've a feeling I may have edited the pages to
account for this, but would like to see what is actually the case.
Hmm, actually now - there were
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
Ross Gardler wrote:
I'll test the Forrest plugin on the Daisy docs today.
I'm not sure why my first version never made it to the list, so here it
goes again:
I want the first new version of the website to be as it was when the
reported missing docs were there, i.e. the old navigation
hepabolu wrote:
Ross Gardler wrote:
I'll test the Forrest plugin on the Daisy docs today.
I'm not sure why my first version never made it to the list, so here it
goes again:
I want the first new version of the website to be as it was when the
reported missing docs were there, i.e. the
I'm just testing the Forrest Daisy plugin for publishing your docs.
Unfortunately there is a limitation with Daisy at present that means
only users with admin rights can access the repository directly.
Since I don't have admin rights I can't test things out.
There are two solutions:
1) give me
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
Ross Gardler wrote:
I'm just testing the Forrest Daisy plugin for publishing your docs.
Unfortunately there is a limitation with Daisy at present that means
only users with admin rights can access the repository directly.
Since I don't have admin rights I can't test things out.
There are two
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
Ross Gardler wrote:
1) give me admin rights (I'm not a committer on Cocoon though so not
sure if you would want to do this)
Now I guess it's much easier to give you the admin rights. So +1 for that.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
Michael Wechner wrote:
Sylvain Wallez wrote:
Michael Wechner wrote:
Hi
I have two questions re the JCR Block
1) How can one actually access the content of properties?
You cannot access them directly with the JCRNodeSource, which is meant
to represent file-like abstractions which are
Carsten Ziegeler wrote:
Ross Gardler wrote:
1) give me admin rights (I'm not a committer on Cocoon though so not
sure if you would want to do this)
Now I guess it's much easier to give you the admin rights. So +1 for that.
+1
Do you just need adding to the administrator role?
Regards,
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
Ross Gardler wrote:
1) give me admin rights (I'm not a committer on Cocoon though so not
sure if you would want to do this)
2) someone with admin rights does the testing with my assistance
Just to clarify, that's admin rights to the daisy instance only.
For the time being I've added admin
I am currently trying to tune our fairly large cocoon app. I am
spending quite a bit of time in the cocoon.xconf file getting pool
sizes right, etc. One area I am a little unsure of is the
runnable-manager. I haven't found a lot of documentation on the best
way to tune this. Does anybody have
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
Ross Gardler wrote:
So, if you can run the Daisy-to-Forrest export, can you use the old
navigation structure documents or should I be rewriting these in Daisy?
Yes, just tell me which version of the navigation document you want me
to use. In fact this goes for any focuments, by default it
hepabolu wrote:
Ross Gardler wrote:
So, if you can run the Daisy-to-Forrest export, can you use the old
navigation structure documents or should I be rewriting these in Daisy?
Yes, just tell me which version of the navigation document you want me
to use. In fact this goes for any
Ross Gardler wrote:
Ah, I see I misunderstood your question. The Forrest plugin can use the
old site.xml files or new ones defined in Daisy or even a mix of the two
(i.e. new ones imported into the old ones).
More on this when I have an iniital demo working. In the first instance
I'll use
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
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=34696.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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
On Tuesday 16 August 2005 13:37, Upayavira wrote:
Thor Heinrichs-Wolpert wrote:
Is cocoon going to use knopflerfish or oscar for its default OSGI
container?
Probably Oscar, or whatever it becomes. However, it may take some time
for the Oscar 2.0 code to mature enough for us to be able to
I'm trying to get approval from my employer to attend. Do you know what
the conference cost will be? Can you recommend any hotels? I've never
been to Amsterdam (or Europe for that matter) so any help is appreciated.
Ralph
Arje Cahn wrote:
Cocoon
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
http://cocoon.zones.apache.org/daisy/documentation/components/664.html
Please note that I am still working on stuff there, but I am taking a
break for today. I wanted to cover the really basic root level stuff
first so that it is easier to reference that when I get to the higher
level
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
Hi Ralph,
I'm trying to get approval from my employer to attend.
great! :-)
Do you
know what
the conference cost will be? Can you recommend any hotels?
The costs will be displayed on the site this week, and you'll be able to sign
up right away. Since this is a community effort, we're
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
Philippe Guillard wrote:
Hi,
Hope i'm not wrong, but i seems to me that the
FlowJXPathSelectionListBuilder
(/src/blocks/forms/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListBuilder.java)
is missing something to add the html tag selected for the item
selected in a
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
I've got the core contracts for the sitemap documented (need some sanity
checking there), and documentation for creating a simple Action up and
ready for review. You can view it here:
http://cocoon.zones.apache.org/daisy/documentation/components/664.html
I'm going to have to take a break
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
I have a few questions about pooling
1. Where is the code that creates all the poolable objects and loads
them into a pool? It seems like there is some avalon class that
controls the pool and implements the pool.
2. Does anyone have any insight into what methods are used to
determine if the
Irv Salisbury wrote:
I have a few questions about pooling
1. Where is the code that creates all the poolable objects and loads
them into a pool? It seems like there is some avalon class that
controls the pool and implements the pool.
Thanks!
On 8/16/05, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Irv Salisbury wrote:
I have a few questions about pooling
1. Where is the code that creates all the poolable objects and loads
them into a pool? It seems like there is some avalon class that
controls the pool and implements
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
65 matches
Mail list logo
