Bertrand Delacretaz wrote:
Le 15 mars 06 à 13:31, Upayavira a écrit :
...So, my question: Is this still cocoon, or is it becoming
something more
general than that (e.g. that could become a Felix sub-project) - thus
gaining a far wider adoption?..
Same feelings here - what you describe
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
snip/
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
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 Cocoon - it
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
snip/
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
Daniel Fagerstrom wrote:
snip/
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
scr:property
Daniel Fagerstrom wrote:
I have worked on implementing the blocks framework in terms of OSGi
for some time. Not everything is working yet, but I think it is time
to start discussing the involved ideas.
snip/
A Servlet Service
-
A bundle that provides a servlet, can
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 Cocoon - it seems more general than
that, and potentially more
Le 15 mars 06 à 13:31, Upayavira a écrit :
...So, my question: Is this still cocoon, or is it becoming
something more
general than that (e.g. that could become a Felix sub-project) - thus
gaining a far wider adoption?..
Same feelings here - what you describe sounds way cool, but maybe
Upayavira wrote:
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 Cocoon - it seems more general than
that,
Sylvain Wallez wrote:
A bundle that provides a servlet, can register it as a service with a
declaration like [5]:
scr:component name=cocoon.servlet3
scr:implementation
class=org.apache.cocoon.blocks.osgi.TestServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
Le 15 mars 06 à 14:38, Reinhard Poetz a écrit :
...We should develop it under our project for now and when we know
more about all the consequences we can still move it to another
community or start to build a new one so that other projects that
don't need this Cocoon-thing can reuse it
Sylvain Wallez wrote:
A *very* important point IMO for the acceptance of all this by
developers is to be able do deploy a directory. This to have fast
roundtrips, without having to go through the compile/package/deploy cycle.
Felix has recently added the possiblity to add bundles which are
Daniel Fagerstrom wrote:
Conclusion
==
It should be noted that I haven't referred to any Cocoon specifics
above. That is one of the neat things about the architecture. It is
completely orthogonal to and independent of the rest of Cocoon and it
could be used together with any
Ralph Goers wrote:
Please Daniel, don't take this personally as it isn't really directed at
you. Part of it is directed at myself as I haven't had any significant
amount of time to contribute to this work. I guess I'm just wondering if
I'm the only one who is feeling this way? If so, I'll
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Personally, the long waiting for this blocks system is having very
unfortunate effects on our community. We need to change that. Take the
development of blocks off the front stage, and let it happen quietly
somewhere until there's something clear
Upayavira wrote:
Ralph Goers wrote:
Please Daniel, don't take this personally as it isn't really directed at
you. Part of it is directed at myself as I haven't had any significant
amount of time to contribute to this work. I guess I'm just wondering if
I'm the only one who is feeling this
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Personally, the long waiting for this blocks system is having very
unfortunate effects on our community. We need to change that. Take the
development of blocks off the front stage, and let it happen quietly
somewhere until
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features
of 2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many other changes like the
Spring based container
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many other changes
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
Do that, and nothing other than 2.1 will ever happen. Getting real
blocks is a big thing. It looks like a lot of work, everyone has
always known that. Now that there is a little bit of momentum in the
blocks
Bertrand Delacretaz wrote:
How about backporting the Spring-based container and the new
configuration features to 2.1.x, and make that Cocoon 2.3, without
touching the current trunk?
The current 2.2 would then stay as is, people could work on it until
it stabilizes, and when it's
* Bertrand Delacretaz:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration
features of 2.2 in 2.1.x, like the includes for xconf and
properties. This alone is a big step forward. Unfortunately
this is tight to many
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
Do that, and nothing other than 2.1 will ever happen. Getting real
blocks is a big thing. It looks like a lot of work, everyone has
always known that. Now that there is a little bit of momentum
Le 15 mars 06 à 16:25, Jean-Baptiste Quenot a écrit :
* Bertrand Delacretaz:
...How about backporting the Spring-based container and the new
configuration features to 2.1.x, and make that Cocoon 2.3,
without touching the current trunk?
Good idea. But I guess you are talking about
My feelings about the blocks and OSGi are vented here already: too few
people know that is going on and what to do and although these features
are big promises, at the moment they are just that: promises.
Is it possible to get the best of both worlds and do something like this:
- evolve 2.1.X
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
snip/
I would like to see blocks and Cocoon 2.1.X move along in parallel, and
as soon as blocks are sufficiently mature and stable, they merge. The
current state of affairs with a tiny minority working on blocks (however
cool) and nothing
Reinhard Poetz wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward.
* hepabolu:
- evolve 2.1.X to include (Carsten's idea) the new configuration
features of 2.2 and Spring (and Maven 2 build?).
Maven 2 build would be great, but there is a problem with
deployment. AFAICT we will be able to have the Maven build ready
once we have a simple way to choose blocks
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
snip/
I would like to see blocks and Cocoon 2.1.X move along in parallel, and
as soon as blocks are sufficiently mature and stable, they merge. The
current state of affairs with a tiny minority working on blocks (however
Le 15 mars 06 à 16:28, Reinhard Poetz a écrit :
...I have no problem with a backport in general, but why exactly
*now* when Daniel writes a mail that he has solved all problems
that required a lot of research work and Daniel and I only need
some more weeks of implementation work?...
Reinhard Poetz wrote:
I have no problem with a backport in general, but why exactly *now* when
Daniel
writes a mail that he has solved all problems that required a lot of research
work and Daniel and I only need some more weeks of implementation work?
I guess the mail was just a
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Who _really_ is following the blocks thread anyway other than the core
developers? I want someone else for the rest of us to follow.
So, what else do you want that you can't do in 2.1 and are unwilling
to do in 2.2?
--
Peter Hunsberger
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
I have worked on implementing the blocks framework in terms of OSGi
for some time. Not everything is working yet, but I think it is time
to start discussing the involved ideas.
snip/
A Servlet Service
-
A bundle that provides a
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 Cocoon - it seems more general than
that,
Daniel Fagerstrom wrote:
snip/
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 block can extend a
I have worked on implementing the blocks framework in terms of OSGi for
some time. Not everything is working yet, but I think it is time to
start discussing the involved ideas.
As already discussed I have refactored the blocks fw to reuse as much as
possible form the servlet APIs. While
37 matches
Mail list logo
