Vadim Gritsenko wrote:
Niclas Hedhman wrote:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
Th
Upayavira wrote:
I would also ask whether we should consider replacing the serializers in
core with those in the serializer block.
Why would you replace single class which works in 99% of cases with 4Mb of code?
Vadim
Niclas Hedhman wrote:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
That's a remarkable spirit ;o
Sylvain Wallez wrote:
So my opinion about ditching our abstraction is that, as we say in
France, it is urgent to wait. Along with the backwards compatibility
problems that ditching the abstraction in 2.2 may lead to, we should see
if that common abstraction comes to life and then consider using
[
http://issues.apache.org/jira/browse/COCOON-1589?page=comments#action_12360388
]
Renaud Waldura commented on COCOON-1589:
I had the same problem as the original reporter on Cocoon 2.1.7, and had
arrived to the same conclusion after reading the co
Niclas Hedhman schrieb:
> On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
>
>>For the versioning, we could for example release a 2.2 soon, change the
>>environment abstract after that and then release a 2.3 later this year.
>
>
> Two more releases this year, YEAH!!!
> That's a remar
Niclas Hedhman wrote:
On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote:
From a users perspective (= the average Cocoon developer), most of the
"messiness" is hidden. She does not have to deal with how the tree processor
works, or with implementing an own pipeline etc. All these i
This is from the geronimo dev list I thought I'd share it here.
Thanks,
--
Dondi Imperial
Software Engineer
Exist Software Labs
Penthouse I, Prestige Tower,
F. Ortigas Jr. Ave. (formerly Emerald Ave.),
Ortigas Center, Pasig City 1605
Philippines
+632.687.7653
www.exist.com
--- Begin Message
Upayavira wrote:
Jorg Heymans wrote:
Also: are we carrying forward all blocks to 2.2 or is this the time
where we ditch the obscure, rarely used and "blocks that don't really
deserve to be a block" blocks? I'ld say we choose the 10 most often used
and well known blocks and let the users vo
Daniel Fagerstrom wrote:
Upayavira skrev:
I would also ask whether we should consider replacing the serializers in
core with those in the serializer block.
Better move the current core serializers to an own block. IMO we
should have a core that only contains the minimal infrastructure and
On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote:
> From a
> users perspective (= the average Cocoon developer), most of the
> "messiness" is hidden. She does not have to deal with how the tree
> processor works, or with implementing an own pipeline etc. All these
> interfaces and compon
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
|
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
> For the versioning, we could for example release a 2.2 soon, change the
> environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
That's a remarkable spirit ;o)
Just kidding...
I
[LINK] www.mw-import.de
---
Key: COCOON-1713
URL: http://issues.apache.org/jira/browse/COCOON-1713
Project: Cocoon
Type: Task
Components: * Cocoon Core
Reporter: Jianuy Wang
Priority: Trivial
-URL of the website:
http://www.mw-impor
Ralph Goers wrote:
Sylvain Wallez wrote:
Which makes actually two different abstractions for the same purpose,
and makes blocking the outputstream on our own abstraction useless,
as people can access it anyway.
It would be better IMO to have a single abstraction, but _control_
how the output
Ralph Goers wrote:
Sylvain Wallez wrote:
Which makes actually two different abstractions for the same purpose,
and makes blocking the outputstream on our own abstraction useless,
as people can access it anyway.
It would be better IMO to have a single abstraction, but _control_
how the output
Sylvain Wallez wrote:
Which makes actually two different abstractions for the same purpose,
and makes blocking the outputstream on our own abstraction useless, as
people can access it anyway.
It would be better IMO to have a single abstraction, but _control_ how
the outputstream is used,
On 13.12.2005 22:20, Carsten Ziegeler wrote:
I have the feeling that changing this does not buy us something and that
does it not make life easier - I might be wrong though. Now, I still
think we should make the request/response objects more easily accessible
somehow.
+1 to both.
Jörg
Carsten Ziegeler wrote:
Ralph Goers wrote:
Daniel Fagerstrom wrote:
The servlet set of apis is allready an abstraction, we have due to
historical circumstances another abstraction of the same concepts. To
me the abstractions look fairly similar, except for the Cocoon
aditions that h
Ralph Goers wrote:
>
> Daniel Fagerstrom wrote:
>
>
>>The servlet set of apis is allready an abstraction, we have due to
>>historical circumstances another abstraction of the same concepts. To
>>me the abstractions look fairly similar, except for the Cocoon
>>aditions that have been mentioned
Daniel Fagerstrom wrote:
The servlet set of apis is allready an abstraction, we have due to
historical circumstances another abstraction of the same concepts. To
me the abstractions look fairly similar, except for the Cocoon
aditions that have been mentioned. What am I missing more specifi
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Look, Cocoons current messiness depends on a large amount of small
things. If we not are able to improve these areas one at a time Cocoon
will stay as messy as it is.
Sure, but I really think messiness is a very hard work here.
I know, but
On 12 Dec 2005, at 18:28, Sylvain Wallez wrote:
Hi all,
An ASF members meeting was held yesterday evening here in San Diego
during which new members were voted in. Among the 33 new members,
some are well known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gardler
- Reinhard Poetz
- Jeremy
Reinhard Poetz skrev:
--- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb:
Daniel Fagerstrom wrote:
More seriously, it was an RT, I wanted to hear
what people think and if
there was any problems that I hadn't thought
about. I will of course
cast a vote before commiting anything. We co
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
It seem like we all agree about that the Cocoon core need to be
simplified, although we have different opinions about how to achieve
it. IMO it can be done in steps by refactoring of the trunk.
One of the complications with Cocoon is the environ
Daniel Fagerstrom wrote:
> Look, Cocoons current messiness depends on a large amount of small
> things. If we not are able to improve these areas one at a time Cocoon
> will stay as messy as it is.
>
Sure, but I really think messiness is a very hard work here. From a
users perspective (= the ave
Carsten Ziegeler skrev:
Leszek Gawron schrieb:
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the s
Upayavira skrev:
Jorg Heymans wrote:
Also: are we carrying forward all blocks to 2.2 or is this the time
where we ditch the obscure, rarely used and "blocks that don't really
deserve to be a block" blocks? I'ld say we choose the 10 most often used
and well known blocks and let the users voice
Berin Loritsch skrev:
IMO, abstraction is not bad, however the wrong abstraction is. Using
the right abstraction can make using a library or tool much easier to
grasp and use.
Now, I'm sure you are sick of Ruby and Rails, but I'd like to share a
little about how the user interacts with the e
Jorg Heymans skrev:
Carsten Ziegeler wrote:
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff and ma
Reinhard Poetz skrev:
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
| +-- MyJavaflowControlle
Torsten Curdt wrote:
While I agree that it is OK to break compatibility to some degree
between 2.1 and 2.2, I think this is more of a change than I'd
really like to see between 2.1 and 2.2 as it will require
modifications to every Cocoon application.
Either we allow such required modif
--- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb:
> Daniel Fagerstrom wrote:
> >
> > More seriously, it was an RT, I wanted to hear
> what people think and if
> > there was any problems that I hadn't thought
> about. I will of course
> > cast a vote before commiting anything. We could
> possib
Daniel Fagerstrom wrote:
It seem like we all agree about that the Cocoon core need to be
simplified, although we have different opinions about how to achieve
it. IMO it can be done in steps by refactoring of the trunk.
One of the complications with Cocoon is the environment abstraction:
o.a.c
Daniel Fagerstrom wrote:
>
> More seriously, it was an RT, I wanted to hear what people think and if
> there was any problems that I hadn't thought about. I will of course
> cast a vote before commiting anything. We could possibly provide some
> optional back compability mode that puts the envi
Leszek Gawron schrieb:
> Carsten Ziegeler wrote:
>
>>In general I agree with this - it makes learning Cocoon internal a
>>little bit easier. But I think the current environment api is not our
>>biggest problem. Anyways, our current Request object has more
>>functionality as the servlet request obj
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Hi all,
An ASF members meeting was held yesterday evening here in San Diego
during which new members were voted in. Among the 33 new members,
some are well known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gardler
- Reinhard Poetz
- Jeremy Quin
On 12/12/2005, at 7:28 PM, Sylvain Wallez wrote:
Hi all,
An ASF members meeting was held yesterday evening here in San Diego
during which new members were voted in. Among the 33 new members,
some are well known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gardler
- Reinhard Poetz
- Jeremy
Upayavira wrote:
> For me, the absolute most important thing is getting the build working
> again with the excalibur stuff. I'm here at ApacheCon with Maven chaps
> around, and the easier it is for me to 'grok' the current Maven setup,
> the more likely I am to be able to understand and explore
Jorg Heymans wrote:
> Also: are we carrying forward all blocks to 2.2 or is this the time
> where we ditch the obscure, rarely used and "blocks that don't really
> deserve to be a block" blocks? I'ld say we choose the 10 most often used
> and well known blocks and let the users voice their concer
While I agree that it is OK to break compatibility to some degree
between 2.1 and 2.2, I think this is more of a change than I'd
really like to see between 2.1 and 2.2 as it will require
modifications to every Cocoon application.
Either we allow such required modifications or we need to
s
Jorg Heymans wrote:
>
>
> Carsten Ziegeler wrote:
>
>>
>> I strongly suggest that we start creating roadmaps. This also would make
>> the development of Cocoon for users much more transparent. Currently I
>> have only two points which I really think have to be finished for 2.2:
>> the build/depl
IMO, abstraction is not bad, however the wrong abstraction is. Using
the right abstraction can make using a library or tool much easier to
grasp and use.
Now, I'm sure you are sick of Ruby and Rails, but I'd like to share a
little about how the user interacts with the environment there. It
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g. to get the sitemap
prefi
On Tue, 2005-12-13 at 09:33 +, Ross Gardler wrote:
> Reinhard Poetz wrote:
> > Sylvain Wallez wrote:
> >
> >> Hi all,
> >>
> >> An ASF members meeting was held yesterday evening here in San Diego
> >> during which new members were voted in. Among the 33 new members, some
> >> are well known
Giacomo Pati wrote:
On Mon, 12 Dec 2005, Sylvain Wallez wrote:
An ASF members meeting was held yesterday evening here in San Diego
during which new members were voted in. Among the 33 new members, some
are well known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gardler
- Reinhard Poetz
- Jer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Dec 2005, Sylvain Wallez wrote:
An ASF members meeting was held yesterday evening here in San Diego during
which new members were voted in. Among the 33 new members, some are well
known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gard
Reinhard Poetz wrote:
We also discussed the structure of projects as proposed by Jorg some
time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113102875010469&w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
The (usual)
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Hi all,
An ASF members meeting was held yesterday evening here in San Diego
during which new members were voted in. Among the 33 new members, some
are well known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gardler
- Reinhard Poetz
- Jeremy Quinn
Carsten Ziegeler wrote:
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff and making the current bloc
Carsten Ziegeler apache.org> writes:
> >>And for me the most important question :) What is the suggested
> >>timeframe/version for this? Do you want to do this for 2.2?
> >
> > So it sounds like 2.2.
>
> Hmm, ok, this is a point where I disagree :) I think we should get 2.2
> out asap to have ou
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
| +-- MyJavaflowController.class
+-- app
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
After working on the deployer and learning more about the Maven2
internals, I want to share 2 thougths:
I've already raised the question whether it is possible to merge
block.xml and pom.xml. For now it's not as dependencies in pom.xml
can't
Sylvain Wallez wrote:
Hi all,
An ASF members meeting was held yesterday evening here in San Diego
during which new members were voted in. Among the 33 new members, some
are well known here:
- Bruno Dumon
- Antonio Gallardo
- Ross Gardler
- Reinhard Poetz
- Jeremy Quinn
Congratulations and a
54 matches
Mail list logo
