http://web.archive.org/web/19991012034854/java.apache.org/cocoon/index.html
This is close to be 6 years ago.
It seems s far away, technologically speaking, there wasn't even ant
nor tomcat around!
Makes you wonder what it will be 6 years from now...
--
Stefano.
[EMAIL PROTECTED] wrote:
Author: joerg
Date: Sat Jul 23 05:18:39 2005
New Revision: 224461
URL: http://svn.apache.org/viewcvs?rev=224461view=rev
Log:
fixing and synchronizing Cocoon's gump descriptor in gump and Cocoon trunk
Modified:
cocoon/trunk/gump.xml
Upayavira, what happened
Bertrand Delacretaz wrote:
== Intro ==
This is not really an [RT] but a summary of a discussion that we
(Gianugo, Upayavira, Reinhard, Daniel, Alfred, Bertrand, Marcus,
Carsten, Giacomo, Sylvain and Torsten) just had at the Blockathon. See
also
Upayavira wrote:
I've just had chats with Stefan Bodewig and Leo Simons from Gump, about
the location of the gump.xml file.
At the moment, they've got a _copy_ of our gump.xml in
http://svn.apache.org/repos/asf/gump/metadata/project/cocoon.xml
which is far from preferable.
Here's what we
Stefan Bodewig wrote:
Hi,
after we've migrated Gump's metadata over to svn as well, there
shouldn't be any need to keep the Cocoon descriptor inside of the
cocoon tree.
I've just committed
,
| Added:
| gump/metadata/project/cocoon.xml
| - copied unchanged from r216130,
Stefano Mazzocchi wrote:
Stefan Bodewig wrote:
Hi,
after we've migrated Gump's metadata over to svn as well, there
shouldn't be any need to keep the Cocoon descriptor inside of the
cocoon tree.
I've just committed
,
| Added:
| gump/metadata/project/cocoon.xml
| - copied
Upayavira wrote:
Reinhard Poetz wrote:
As you all know, Max Pfingsthorn is one of our Google Summer of Code
students and he will work on the implementation of the cforms library.
In order to make his life and the life of his two mentors (Sylvain and
I) easier, I want to give him
Bertrand Delacretaz wrote:
Le 27 juin 05, à 09:47, Max Pfingsthorn a écrit :
...I got this from google this weekend, seems like I'm going to spent
some time on CForms this summer ;)..
Welcome Max - looking forward to this development, and all the best for
your exams!
Welcome on board!
Daniel Fagerstrom wrote:
Give me a 3 lines description of where to start looking and I'll get
going.
A good starting point is the BlocksManager and sitemap component
configurations in the test cases:
src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.
all right,
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Yey!!
Daniel,
you rock! Thanks so much for your continuous work on this!
Thanks :)
See my comments inlined.
Daniel Fagerstrom wrote:
snip/
The super block of a block is identified by
/wiring/block/connections/connection
We should try to make it easier for gump to work with us. Our build
system is a little hacky in that regard since it uses partial gump
information to build cocoon.
Gump strongly suggests people to move their gump descriptors over to the
gump repository, so that all apache committers have access
Stefan Bodewig wrote:
On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Stefan Bodewig wrote:
On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
it's not a matter of being annoyed enough (we are already!), it's
the fact that cocoon needs that file at build time
Stefan Bodewig wrote:
On Thu, 16 Jun 2005, Upayavira [EMAIL PROTECTED] wrote:
I've committed this patch to Cocoon trunk.
Many thanks.
I presume that is the correct place.
Until the Cocoon project is annoyed enough by our patches and moves
the descriptor over to Gump land, I
Stefan Bodewig wrote:
On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
it's not a matter of being annoyed enough (we are already!), it's
the fact that cocoon needs that file at build time.
Hmm, so why don't you realize that you have a typo in it for many
days? Like when
Peter Hunsberger wrote:
On 6/15/05, Ugo Cei [EMAIL PROTECTED] wrote:
Il giorno 15/giu/05, alle 16:32, Tony Collen ha scritto:
snip/
Actually, what I am trying to come up is an algorithm for determining
whether two texts refer (more or less) about similar subjects.
Eee, then you may
Ugo Cei wrote:
Il giorno 15/giu/05, alle 18:27, Stefano Mazzocchi ha scritto:
I've been working on this for the past few months. There is no clearcut
solution, but using LSI is probably the best approach for the above
LSI == ?
latent semantic indexing
As for string distance, you might
Bertrand Delacretaz wrote:
Le 10 juin 05, à 18:23, Daniel Fagerstrom a écrit :
...I will be offline the comming week (sailing). Feel free to finish
the OSGi stuff while I'm away ;)
hmmm...this OSGI stuff is cool, but if we have a choice, I'd rather go
sailing ;-)
Which, in fact, I did
Nathaniel Alfred wrote:
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 9. Juni 2005 11:52
To: dev@cocoon.apache.org
Subject: [VOTE] Document Editors, and a new Committer
On this basis, I'd like to propose Helma Van Der Linden as a Cocoon
committer, and
Yey!!
Daniel,
you rock! Thanks so much for your continuous work on this!
See my comments inlined.
Daniel Fagerstrom wrote:
I have added a first, hopefully working, version of the sitemap aspect
of real blocks to the trunk. No functionality to get components (not
even VPCs) yet from the
David Casal wrote:
That's what I'm after. So you see a roadmap whereby first you work on
easy kernel installation -then- play semantics.
Correct. The other way around would make the goal even harder to
bootstrap. No advancement in an open source software happens if you
don't capture some
David Casal wrote:
Do you see a point where they'll be
able to put together semi-complex webapps in LEGO style?
Dude, can you read?
http://cocoon.apache.org/ [very first paragraph]
:-)
[nobody is responding because that's like asking: do you see a future of
open source for this project? WTF
Sebastien Arbogast wrote:
2005/5/24, Gerald Aichholzer [EMAIL PROTECTED]:
Hello Sebastien,
Sebastien Arbogast wrote:
you can see the aliased edges in the letters a, b, o and c. This
is causing a very blurry presentation when viewing in normal size.
It rather looks like ClearType is on. I
Unico Hommes wrote:
BTW. Where *is* Linotype? I found this
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110705988801725w=2 but
looking at http://simile.mit.edu/ I can't seem to find it. Linotype in
the 2.1 branch seems to be somewhat broken.
on betaversion.org svn I host the version that
Mark Leicester wrote:
Sorry, that link again is:
http://www.planetcocoon.com/hof
Mark, are you aware of
http://cocoon.apache.org/mail/dev/
?
--
Stefano.
Steven Noels wrote:
On 18 May 2005, at 04:58, Mark Leicester wrote:
I've installed a Hall of Fame module into PlanetCocoon. This module
summarises activity on the site: active users, active commenters,
popular content, etc. It's not exact, but it gives an idea of mailing
list traffic. I say
Jorg Heymans wrote:
Hi Mark,
Mark Leicester wrote:
I've been thinking about incentives for community members. The main
community incentive - beyond sharing the fruits of our labour - is
committership. That goal is a long way off for a newbie. I have
wondering about the possibility of setting other
Sylvain Wallez wrote:
So we need other kinds of indirect measurements. Some of them are in
Stefano's agora, such as the variety of people one talks to, which shows
some level of community implication.
I spent months trying to visualize a community in a way that was not
subjectively polarized
Linden H van der (MI) wrote:
I'm interested in hearing why you think that committership is
*the* incentive for people to contribute?
Same here. I may not be a representative of the average user population,
but I don't WANT committership until I'm fully convinced that I can
submit something
Vadim Gritsenko wrote:
Antonio Gallardo wrote:
On Mie, 18 de Mayo de 2005, 8:20, Stefano Mazzocchi dijo:
http://cocoon.apache.org/mail/dev/
Can someone tell why the 1st 2 files are not .gziped?
Too small. Can't see any other reason.
historical... and nobody managed to get
Steven Noels wrote:
On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:
But it's also true that editing xml files in a svn repository sucks as
an editing tool. Using wiki (or daisy or other solutions) is much better.
I like the notion of
daisy - forrest - out
makes very good sense.
It does, yet
Nicola Ken Barozzi wrote:
Steven Noels wrote:
...
What do people think?
I think that we need people that write documentation, not a tool.
I can hardly disagree more.
I wrote my blog *before* I wrote its posts. Without it, I could have
written them by hand, but god, that always made me go nah.
Sebastien Arbogast wrote:
I think that we need people that write documentation, not a tool.
I can hardly disagree more.
I wrote my blog *before* I wrote its posts. Without it, I could have
written them by hand, but god, that always made me go nah.
MDR ! This discussion is really funny. No offense
Niclas Hedhman wrote:
On Thursday 12 May 2005 10:56, Stefano Mazzocchi wrote:
So, stop wasting your words ranting and tell me how you would solve the
problems we have if you had commit access.
Although I sympathize with your situation, but the 'tone' is a bit harsh,
wouldn't you say.
FYI, approx
Linden H van der (MI) wrote:
As explained in a private mail to Sebastien, I've taken up the http://www.cocoondev.org/handbook site that Steven graciously set up for me. I intend to work on the mid-level tutorial that was the initial goal for the Cocoon In Action project.
Doing it in Daisy is much
Mark Leicester wrote:
I think you are right, I probably have dismissed the existing stuff a
bit early. In that case, I pledge to keep in touch with the current
effort. I certainly value ongoing dialogue. However, I wonder out loud:
should we be putting documentation behind the barrier of
Sebastien Arbogast wrote:
Such management tools should allow people that have the responsibility
to validate and publish content on the website to quickly grasp the job
they have to do. For example, I may want to have a quick look at all
changed documents that have the forms flowscript or sitemap
Mark Leicester wrote:
I want to adopt some community health indicators. Does anyone have any
prior knowledge in this field?
Oh man, stay away from there, it's a mine field :-)
http://nagoya.apache.org/~stefano/
--
Stefano.
Mark Leicester wrote:
On 11 May 2005, at 13:10, Ross Gardler wrote:
Mark Leicester wrote:
Hello everyone,
I've been looking at various statistical representations of community
activity:
GMANE:
http://dir.gmane.org/gmane.text.xml.cocoon.devel
http://dir.gmane.org/gmane.text.xml.cocoon.user
Vadim:
Mark Leicester wrote:
Hi Sebastien,
Goodness me. There's plenty of strength of feeling expressed in this
email. I'm grateful to you for talking this way. I think my motivation
for working on spreadcocoon and planetcocoon comes from a similar place
so perhaps I can empathise.
I've been thinking
Sebastien Arbogast wrote:
It already applies here. Where do you think I learnt it ;-)
It is the conspet of lazy consensus Upayavira was referring to.
Well then obviously it's not always as efficient as expected :-P Or
once more it's not enough...
Of course is not enough. If everything was enough,
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 1 mai 05, à 22:46, Sylvain Wallez a écrit :
...So, I think it's really time to do some cleanup and remove these
tags everywhere...
Fine with me
IIRC Bertrand ran a script to extract the current tags to build a
credits file. Bertrand, any
Sylvain Wallez wrote:
Hi all,
We discussed more that one year ago the removal of @author tags in our
source files (see [1] and [2]) but although the consensus was to remove
them, we never actually did it. Now most if not all new classes added
since then have no @author tag, leading to a strange
Antonio Gallardo wrote:
Hi:
This is only related to the time format in the access output. Currently we
use:
Processed by Apache Cocoon 2.1.8-dev in 3.612 seconds.
Processed by Apache Cocoon 2.1.8-dev in 3 milliseconds.
New format (an ISO8601-like):
Processed by Apache Cocoon 2.1.8-dev in
Daniel Fagerstrom wrote:
Bertrand Delacretaz wrote:
Le 27 avr. 05, à 16:41, Daniel Fagerstrom a écrit :
...Then we need a name for sitemap blocks. I propose to call them
cocoonlets...
Frankly, I don't like the name - most of these -let names sound bad
to me.
But I don't think the names
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Our current (controversial ;) ) plan is to consider the sitemap and
the component aspect of the original block proposal as separate
concerns and (at least initially) solve them separately.
I propose less controversial plan.
As the first step,
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Our current (controversial ;) ) plan is to consider the sitemap and
the component aspect of the original block proposal as separate
concerns and (at least initially) solve them separately.
I propose less controversial
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy
Leszek Gawron wrote:
creating a single cocoon.log is a good idea. Still it was very good to
have a separate error.log. It is really annoying to search the file for
ERROR string. Is anybody against reintroducing error.log?
I am, just change the log level or use tail -f cocoon.log | grep ERROR
--
Ralph Goers wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I just committed a new JCR block. This block provides two features: a
Repository component, and a jcr: protocol.
Awesome news!
The Repository component is nothing more than the standard
javax.jcr.Repository interface
Daniel Fagerstrom wrote:
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it easy
to share jars and to download only the ones needed.
Ivy was proposed as a possible solution, but I suggested
Sylvain Wallez wrote:
Hi all,
I just committed a new JCR block. This block provides two features: a
Repository component, and a jcr: protocol.
Awesome news!
The Repository component is nothing more than the standard
javax.jcr.Repository interface, but provides a way to centrally define
how to
Nathaniel Alfred wrote:
I counted eighteen +1s and no other votes, welcome Alfred!
-Bertrand
With my account in the works, it's time to introduce myself.
I am team leader of Internet Service Development at SWX Swiss Exchange.
Our business unit SWX e-Services (current staff 18, half of them
Michael McGrady wrote:
SNIP
On 4/21/05, Sylvain Wallez [EMAIL PROTECTED] wrote:
(stupid Struts people that think the whole world reads their articles
and mailing lists)
/SNIP
What I like most about your writing, Sylvain, is your almost poetic
innate sense of assonance. The article was quoted by
Stefano Mazzocchi wrote:
Michael McGrady wrote:
SNIP
On 4/21/05, Sylvain Wallez [EMAIL PROTECTED] wrote:
(stupid Struts people that think the whole world reads their articles
and mailing lists)
/SNIP
What I like most about your writing, Sylvain, is your almost poetic
innate sense of assonance
Michael McGrady wrote:
Well, my real interest was in letting Frank Zammetti on the Struts
list know about the work on Cocoon. I did not know I had to be real
careful to make sure that Sylvain's sense of under-privilege was not
hurt. I did not even notice he was part of the equation, frankly. I
Erik Bruchez wrote:
Stefano Mazzocchi wrote:
o We do strongly believe that the XML pipeline language in OPS beats
the ... out of Cocoon pipelines ;-)
Oh, that's a bold statement :-)
Yes ;-)
eheh, one step up and two step back. Your pipeline language feels
turing complete (haven't
Erik Bruchez wrote:
[snip]
I don't believe the comparison can be all wrong, or even all unfair,
even if there is certainly subjectivity in it, and even if we mainly
mention OPS's strengths rather than weaknesses.
Well, tell you what: rule number one of any CTO/CIO is never to believe
in what a
Antonio Gallardo wrote:
A fast checking to the matrix in:
http://www.orbeon.com/community/cocoon
Antonio: enough.
Let's move on.
--
Stefano.
I just hit a limitation of cocoon that I never thought I would encounter
on a server framework: it's too big!
We (at MIT) are implementing a pretty complex web application for RDF
search and browse interface (Longwell) and I'm about to start the work
to support our work done on RDF
Sylvain Wallez wrote:
Hi all,
The Lepido project is in the proposal phase at Eclipse, and during that
phase the only provided resource is a newsgroup. We need however to
setup plans, feature list, participants, etc.
That's why I kindly ask the Cocoon developers if we can create a few
pages for
Pier Fumagalli wrote:
On 14 Apr 2005, at 13:32, Daniel Fagerstrom wrote:
snip/
After having read your mails I agree that we at least for the time
being, should consider component management with classloader
isolation, a separate concern. By _assuming_ independence between
blocks and component
Ralph Goers wrote:
Daniel Fagerstrom wrote:
For the portal block, which I still don't know that much about, I
would assume that it would become a number of components with some
kind of dependency description for each and a block with sitemap
functionality and a list on what components it depend
Pier Fumagalli wrote:
IMO, we should start simple and add functionality when needed. Remove
things is much harder. Also even if we chose to go for alternative 4.
an important message from Pier that we should take into account is
that component exposure adds complexity. So if we go that way, we
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do you have any link or example?
no. But AFAIK there
Geoff Howard wrote:
On Apr 12, 2005 2:33 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
Antonio Gallardo wrote:
Is posible to change the name from:
block.xml - cob.xml
ATM everything is possible ;-)
I see the analogy to WEB-INF/ -- web.xml.
IMHO this is to keep the same name and avoid confusions.
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+--
Gianugo Rabellino wrote:
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
what about describing the sitemap in LDAP directly, you could use
netinfo to edit it! hmmm, no, wait, what about sitemap via email
Ugo Cei wrote:
While we're talnking about exceptions, what about NOT logging a
stacktrace whenever no sitemap match is found? With the current
behavior, we get a stacktrace, for example, everytime a browser requests
/favicon.ico, which happens quite frequently. Can't we just log a
one-line
Jochen Kuhnle wrote:
Hi Sylvain,
I agree that generated sitemaps are a somewhat more sophisticated use of
Cocoon. However, I think it is a nice feature to have. My main reason for
this is that I want to hide the nuts and bolts of sitemaps from site
maintainers and just want to give them a
Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
So, if you think there is a functionality missing in the sitemap,
propose a way to fix it, don't propose a way for you to route around it.
I agree with Stefano. And AFAIU the problem that has led to this
discussion will go away with real blocks
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
map:transformers default=xslt
map:transformer name=virtual2
src=org.apache.cocoon.transformation.VirtualPipelineTransformer
map:source param=src2/
map:transform src=vpc-include.xsl
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
map:transformers default=xslt
map:transformer name=virtual2
src=org.apache.cocoon.transformation.VirtualPipelineTransformer
map:source param=src2/
map:transform
Upayavira wrote:
Antonio Gallardo wrote:
On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
Jochen Kuhnle wrote:
map:mount src=usersitemap.xmap prefix=~{1}/
context=/home/{1}/pages//
I'm +1 for this form; and IIUC Antonio has similar use case: same
sitemap
for
different directories.
Yep.
Sylvain Wallez wrote:
Hi all,
While trying to fix an annoying but in EHCacheStore when cocoon is
reloaded, I found that all cache implementations accept parameters to
specify if the cache should go to either cache-dir or work-dir.
The question is: why oh why do we have a cache-dir setting if we
Daniel Fagerstrom wrote:
I have continued Vadim's and Sylvain's work and added a first, hopefully
working version of virtual sitemap components (VPCs) to the trunk.
Awesome!!!
You (and Vadim) rock!
I'm a happy camper.
Use
===
To use VPCs one define them in the components section in the sitemap,
Sylvain Wallez wrote:
Hi all,
The src/core directory was initially created to clearly separate the
development of ECM++ and ensure it had no dependencies of other parts of
Cocoon.
All went well until we added some fancy features like includes, variable
expansion, etc, which led an increasing
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
I disagree. You have a world-wide unique identifier (the URI) and a
local name in a well isolated context, and a wiring table to glue
these together (using the URIs) that's all you need.
Consider the following case: One of my applications use
Daniel Fagerstrom wrote:
You probably meant here BlocksManager
No I meant BlockManager. In my discussion I assumed that a BlockManager
is responsible for the information within a block element in the wiring
(http://wiki.apache.org/cocoon/BlocksWiring) and that the BlocksManager
correspond to
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
Daniel Fagerstrom wrote:
Portal block
- requires MyProfile that implements profile
Correction:
- Requires implementation of profile interface.
profile is implemented by MyProfile1,
Daniel Fagerstrom wrote:
As Stefano doesn't work fulltime at Cocoon anymore, the rest of us must
take our reponsibilty and make shure that our individual ideas actually
intgrates with others ideas and are benefical for Cocoon as a whole.
Daniel,
I have never worked fulltime on Cocoon and I have
Pier Fumagalli wrote:
The only problem I have with block:super://blah.xml is that // in an
URI indicates the start of the authority part, and this is defined as
[EMAIL PROTECTED]:port, and no matter how you see it, block:...anything...
_is_ a URI, and thus should follow its spec...
Pier
Pier Fumagalli wrote:
On 1 Apr 2005, at 15:40, Torsten Curdt wrote:
[X] there is a chance I gonna make it
Same here.
--
Stefano.
Daniel Fagerstrom wrote:
Concerning the skin I find it somewhat burocratic to need to define a
new block for beeing able to extend it but I'm ok with it for the time
beeing, we will see when we start to use the things.
Cool.
What I would prefer
would be to do something like:
MyPortal Sitemap
Daniel Fagerstrom wrote:
[snip]
Can you describe how you would prefer to adress the building a webapp
from several blocks scenario that I described above.
Daniel, you are asking for two things:
1) the existence of a super() equivalence in the block protocol
2) the introduction of multiple
Daniel Fagerstrom wrote:
But if we step up from the technical details, the main reason that I
want multiple inheritance is that I want to make it easy to build
webapps by extending and partly overiding a couple of orthogonal blocks.
When you build your webapp block it might extend e.g. a
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
snip/
I don't like multiple inheritance and this is not just because I
learned OOP thru java, but because every single time I wish I had
multiple implementation inheritance in java I found a way to go around
the problem
Daniel Fagerstrom wrote:
damn, hit sent too early.
If you *don't* care for reusability, then it's true that multiple
implementation inheritnace can serve as a cheaper form of composition.
For the majority of Cocoon users I would assume that blocks that are
possible to extend and override is
Peter Hunsberger wrote:
I would go a little further and say that I believe inheritance is useful
only when used as a 'cascading' mechanism, in any other sense is
harmful: composition should be used instead.
Why so?
It's extremely hard to design for inheritance, a lot easier to design
for
Torsten Curdt wrote:
Torsten Curdt wrote:
The only thing missing is the automatic reload of classes (you still
need to touch the sitemap, which I sometimes forget),
Nah... almost there. Will finish that up over Easter.
Tadaaa! :)
...ok - now if you use the classpath directive
the
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
So I wrote in 2.2 an experimental per-sitemap classpath that allows
each sitemap to define its own specific classpath for the components
defined by map:components.
The syntax is as follows (the sitemap is in src/webapp hence
Sylvain Wallez wrote:
So I wrote in 2.2 an experimental per-sitemap classpath that allows each
sitemap to define its own specific classpath for the components defined
by map:components.
The syntax is as follows (the sitemap is in src/webapp hence the ../..).
map:components
map:classpath
Pier Fumagalli wrote:
FYI, might be interesting for the Cocooners out there, as that's what
I've tested.
http://www.betaversion.org/~pier/wiki/display/pier/32+Versus+64
Interesting.
It would also be kinda cool to have some other data in terms of
concurrency, you are stressing with 10 threads,
Daniel Fagerstrom wrote:
If I have to choose between an abandoned one man
show with full junit test support (whatever that means) and a block with
an active community but no tests there would need to be *very* strong
other advantages for the one man show, for me to even consider it.
If there is
Sylvain Wallez wrote:
Hi all,
There are some flowscript use cases where we want to stop the current
flowscript without creating a continuation, as we don't want to the user
to go back to the script.
An example is a login function where the caller function expects this
function to exit only if
Sylvain Wallez wrote:
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script files.
And of course this default encoding isn't the same on
Carsten Ziegeler wrote:
At the last GT we agreed that our core should not depend on other
projects, so we wrote our own container and did not use an existing one.
We also said that on the application level, a user can use whatever
container she wants on top of Cocoon.
It seems that this is a good
Marc Portier wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script
files
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi all,
Having to often write quick prototypes with Cocoon, I have on my laptop
one main Cocoon installation and a lot of subsitemap directories in
various locations, all mounted into the main Cocoon using the
mount-table matcher.
That works fine
Carsten Ziegeler wrote:
Gump wrote:
SNIP/
compile-mocks:
SNIP/
[echo] Compiling Cocoon Core
[javac] Compiling 32 source files to /home/gump/workspaces2/public/workspace/cocoon/build/cocoon/classes
[javac] Compiling 536 source files to
101 - 200 of 1170 matches
Mail list logo
