t case we will be in a similar situation
as when the current team around spring had declared their retirement from
spring project: A new team needs to take over.
So let's have a close watch at further development of the issue....
Rainer
Reinhard Pötz schrieb:
> Rainer Pruy wrote:
>
Hi,
yes, all the wording is quite confusing.
The "statement" cited by Peter is trying to convince readers into believing "it
will affect only old releases",
but there nowhere is a guarantee put up that there will be a new release within
the 3month period.
And the policy puts up that 3 month peri
Hi,
sorry for intruding this discussion.
just from what I can take from this discussion:
Wouldn't it be easier to enclose this into a generalized Environment
implementation
that does support Environment.getTopRequest() and is stored with ObjectModel in
place of those different "REQUEST_OBJE
Just another 0.01€ in the same direction:
most "developing" users (esp. the ones developing cocoon itself) would qualify
as hackers.
Those are used to associate special meanings with groups of version numbers
as a number of other projects follow similar rules (e.g. Linux for long used
that even/
Just my 0,02 cents...
I always considered "Cocoon" to mean more than pipelines, sitemap and alike
Thus I don't think using Cocoon 3.0 being an apropriate name.
What about
Cocoon Pipe (ok, not exaktly)
or
Cocoon Bones
Rainer
Reinhard Pötz schrieb:
> Bertrand Delacretaz wrote:
>> On Wed,
It is essential to keep the different layers straight here.
The example is somewhere at the level of the pipeline api or probably sitemap
api implementation..
Here caching is a question of the implementation of the components.
It actually will depend on different implementations of generators,
t
xcept that we have one less
> dependency - when nobody really gets in contact with uri resolving
> anyway? I have only received half an answer to only the second question
> (standard API). Only then I started to look at the relationship between
> uri resolving and pipeline API and found only this one reference to the
> source resolve package.
>
> Joerg
>
> [1] http://marc.info/?l=xml-cocoon-dev&m=120649777119480&w=4
--
Rainer Pruy
Geschäftsführer
Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151
Reinhard Poetz schrieb:
> Dev at weitling wrote:
>> But (maybe I have missed some mails) how do you want to make this
>> Pipeline API?
>> E.g. a SAX-based pipeline is something different than image data
>> running through several filters. How do you want to prevent the use of
>> a SAX-events gene
Reinhard Poetz schrieb:
> Carsten Ziegeler wrote:
>> The question is now if we need support for caching in the low level
>> apis or if it is possible to have a layered approach - which would
>> make the entry barrier much easier.
>
> Yes, this layered approach is what I'm aiming for. All the rea
configuration files. Instead they provide dynamic
> evaluation of property placeholders though - just like our input modules.
>
> That's why I'm strongly against adding this functionality to the
> sitemap.
>
> (I have held back this mail (for nearly 24 hours) so that o
Then
cocoon:prepare
or (more verbose)
cocoon:prepare-run
does sound appropriate
Jason Johnston schrieb:
> Reinhard Poetz wrote:
>> Felix Knecht wrote:
>>> Reinhard Poetz schrieb:
After having seen quite a few people wonder what 'cocoon:rcl' means,
I propose to change it
Grzegorz Kossakowski schrieb:
> Rainer Pruy pisze:
>> Daniel Fagerstrom schrieb:
>>> Grzegorz Kossakowski skrev:
>>>> Daniel Fagerstrom pisze:
>>> ...
>>>
>>>> Simply choosing {} is not a solution because there will be no smooth
>>
ng anyone to use the new unified ELs, we just offer
> people to do that if they feel like it. It is just a configuration setting.
>
> /Daniel
Hmm, leaving me wonder, whether such configuration can be decided upon
on a per block basis.
Otherwise, if I'd choose using "new" EL I would be prevented from using
blocks that stick to "old" world and vice-versa?
Rainer Pruy
13 matches
Mail list logo