Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't
destabilize the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114073731515724&w=2.
It just cannot affect t
Hi everybody,
I've just read the simple release plan, and I feel obliged to make
some comments.
I think the main doubts about the stabilty of trunk is that it isn't
possible to get the samples running. The only way to solve the
problem of the lack of confidence in trunk is to get the samples
wor
Daniel Fagerstrom wrote:
The target could be overriden by the configuration service. Do we get
polymorphism this way based on the interface of references?
I think it should work, neat idea :)
Otherwise we have mainly discussed pol
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I suppose is to check out trun
We are really innovating, as the cited article just contains some parts
of the blocks idea. But the rest of the world is definitely catching up.
If we focus on self doubt instead of development, we will be overrunned
in this area as well.
On the more positive side it is an advantage that the i
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Not surprisingly I'm -1 on your points 2 and 3. If you want to continue
in that direction which IMO represents a huge step back. I insist on
that you prove that it work and that you actually have the persistence
to carry it through, on a copy
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
Inter Block Communication
=
The servlets (sitemaps) in the different blocks need to be able to
call each other. Also it simplifies reuse of blocks if one block can
extend another one (or rather that a servlets in one bl
Hi,
Ralph Goers wrote:
I first tried it at ApacheCon in early December. As I recall it was in a
whiteboard at the time. I've tried it several times since then. I've
never been able to get a Cocoon up where I could test the code I wanted
to modify. I haven't tried it since the email you refer
Sylvain did some work on pull based pipelines around last ApacheCon, and
we had some design discussions among the present Cocoon devs. I don't
think any code hit the SVN though.
From an implementation POV, much of what is needed for Stax based
pipelines is already done as part of Axis2. They
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I suppose is to check out trunk. There are a bun
Hi All
I am working on a project that uses a lot of aggregations in the
sitemap, using .
My aggregated parts all call cocoon:// pipelines in other subsitemap,
via the top level sitemap, where my top-level sitemap is not the one
that comes built-in with Cocoon, but is my own, mounted direc
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of how
to do it? I don't mind helping with this.
(I could be
wrong, but I don't seem to be able to check out trunk as there is an
external t
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
BTW, I'm quite surprised that you want to go back to the messy Ant
build from 2.1.x after having argued for building Cocoon with Maven
for years. Have you lost your faith in Maven?
Same feeling here.
I honestly admit being rather clueless bot
Jean-Baptiste Quenot wrote:
> * Sylvain Wallez:
>
>> Daniel says that "classical Cocoon" code doesn't depend on the
>> infrastructure that's being built for real blocks and OSGi. And
>> we seem pretty close to a full M10N. AFAIU, what's needed to
>> finish it is mainly the equivalent of "bu
* Sylvain Wallez:
> Daniel says that "classical Cocoon" code doesn't depend on the
> infrastructure that's being built for real blocks and OSGi. And
> we seem pretty close to a full M10N. AFAIU, what's needed to
> finish it is mainly the equivalent of "build webapp".
Exactly!
> If the abo
Daniel Fagerstrom wrote:
> The blocks FUD
> ==
>
> I'd like to remind once again that the blocks work doesn't destabilize
> the traditional use of Cocoon the slightest, see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114073731515724&w=2.
> It just cannot affect that as there are
Peter Hunsberger wrote:
On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote:
Thus, we have 'one way' of doing it, that people don't want to follow,
for their own reasons, and because of this, nothing at all happens, and
our community gets weaker by the day.
Oh, come on. There's no real
Peter Hunsberger wrote:
> On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote:
>
>> Thus, we have 'one way' of doing it, that people don't want to follow,
>> for their own reasons, and because of this, nothing at all happens, and
>> our community gets weaker by the day.
>
> Oh, come on. There's no re
Carsten Ziegeler wrote:
Trunk is not working out of the box; testing the samples is really a
pain; for example I can't test the new portal version as this would
require porting all missing blocks to the new structure, getting them
compiled and more important its a rather huge effort to build t
On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote:
>
> Thus, we have 'one way' of doing it, that people don't want to follow,
> for their own reasons, and because of this, nothing at all happens, and
> our community gets weaker by the day.
Oh, come on. There's no real evidence for this being true.
* Reinhard Poetz:
> If somebody has the need of writing some deployment tool without having to
> understand blocks-fw, he could write an
> Ant script or an M2 Mojo that get some kind of configuration which blocks
> should be installed:
>
>
>
> org.apache.cocoon:forms-impl:1.0-SNAPSHOT
>
Hi,
Tim Williams wrote:
On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote:
The overhead for people to work on trunk is that trunk is largely
unknown. It is my perception that many people have little confidence
that trunk actually works. Fear that it will change frequently, and that
they will h
Reinhard Poetz schrieb:
> Upayavira wrote:
>
>> Carsten has offered a suggestion that _he_ is prepared to implement. I
>> would like to hear other proposals from people of things that _they_ are
>> prepared to implement. Only that way will we move beyond this impass.
>
> There are many documents
On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote:
> Reinhard Poetz wrote:
> > Upayavira wrote:
> >
> >> Carsten has offered a suggestion that _he_ is prepared to implement. I
> >> would like to hear other proposals from people of things that _they_ are
> >> prepared to implement. Only that way will
Reinhard Poetz wrote:
> Upayavira wrote:
>
>> Carsten has offered a suggestion that _he_ is prepared to implement. I
>> would like to hear other proposals from people of things that _they_ are
>> prepared to implement. Only that way will we move beyond this impass.
>
> There are many documents th
Upayavira wrote:
Carsten has offered a suggestion that _he_ is prepared to implement. I
would like to hear other proposals from people of things that _they_ are
prepared to implement. Only that way will we move beyond this impass.
There are many documents that explain the roadmap Daniel and I
Reinhard Poetz wrote:
> I agree with Daniel.
I figured you would ;-)
>
> I want to add some thoughts to Daniel's idea of writing some Ant script
> for the build: trunk has been mavenized and split up into many modules.
> The missing thing is some tool that will create a web application out of
>
Daniel Fagerstrom wrote:
> Upayavira skrev:
>> My own reflections on this is whether or not this is still Cocoon.
>>
>> It seems to me that you are creating a framework for managing web
>> applications based upon servlets, OSGi and the URLConnections. This
>> doesn't seem all that specific to Cocoo
Le 16 mars 06 à 08:44, Carsten Ziegeler a écrit :
...Getting a 2.3 out with the proposed plan is doable in the short
term imho...
Would it be possible to prove this without touching the current
trunk, so as not to disturb the work of those working on the blocks
and OSGI stuff? By creating
Hi
I have modified
build.properties
src/webapp/WEB-INF/web.xml
in order that one can actually patch the enable-uploads.
Before my change one had always true for this no matter if one declared
within (local.)build.properties: config.enable-uploads=false, because
web.xml was set to true by defau
30 matches
Mail list logo
