> -Original Message-
> From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
> Sent: 18 February 2005 17:41
> To: dev@cocoon.apache.org
> Subject: Re: Moving blocks
>
> Upayavira wrote:
> > Reinhard Poetz wrote:
> >
> >> Could some people p
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
I have not tested yet what happens with local changes after the block
is "mounted" using svn:external. Any experiences?
I've been using svn:external for including the documentation in the
simile.mit.edu web site (which is managed in SVN) importing t
Upayavira wrote:
Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build.
Authentication-fw depends on session-fw. This will give me the chance
to test my build syst
Reinhard Poetz wrote:
I have not tested yet what happens with local changes
after the block is "mounted" using svn:external. Any experiences?
I've been using svn:external for including the documentation in the
simile.mit.edu web site (which is managed in SVN) importing the /docs
that come from t
Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build.
Authentication-fw depends on session-fw. This will give me the chance to
test my build system that will resp
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build. Authentication-fw
depends on session-fw. This will give me the chance to test my build system that
will respect those relations. I
Reinhard Poetz wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy
to use deployment tool) it should be the goal to have independant
blocks with their own release cycles.
But
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the proposal
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the proposal is to move blocks
Ralph Goers wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
/cocoon/blocks/core/forms/b
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
/cocoon/blocks/core/forms/branches/ .
This makes me a little uncomfortable. So blocks will now have a release
schedule that is independent from core? I'm just wondering if that is a
good thing or a bad thing at this time. And if that is so, why isn't
each block on its own release? (That is just rhetorical, as I don't
believe we
Carsten Ziegeler wrote:
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under core,
Would it be worth considering adding either 'legacy' or 'deprecated' to
contain blocks that are going to disappear at some unspecified point in
the future (or maybe s/unsupported/deprecated/)? I'm just suggesting
that 'unsupported' may not be strongly worded enough for new users who
start deve
Carsten Ziegeler wrote:
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under core,
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under core, supported, unsupported,
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Sometimes I think that "real blocks"
[...] is another instance of something that is becoming an anti-pattern:
"stating the solution before stating the problem".
This is true. I agree completely with that, in fact, the observation
came after deep
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Sometimes I think that "real blocks"
[...] is another instance of something that is becoming an anti-pattern:
"stating the solution before stating the problem".
This is true. I agree completely with that, in fact, the observation
came after deep
Daniel Fagerstrom wrote:
Sometimes I think that "real blocks"
[...] is another instance of something that is becoming an anti-pattern:
"stating the solution before stating the problem".
This is true. I agree completely with that, in fact, the observation
came after deep and long thinking sbout e
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x shoul
Le 15 févr. 05, à 08:14, Reinhard Poetz a écrit :
...I propose having a very small distribution (Cocoon core + core
blocks which are IMO CocoonForms, Templating and JavaFlow) and a
complete distribution with all blocks included...
+1, seems the easiest thing to do now, yet already a good improvem
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Ralph Goers wrote:
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should b
Le 14 févr. 05, à 11:14, Carsten Ziegeler a écrit :
...I think these are minimal changes that can be done very quickly...
Then big +1, having a smaller core is also important for the
*perception* of Cocoon being the lean and mean tool that it is.
-Bertrand
smime.p7s
Description: S/MIME cryptogr
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Daniel Fagerstrom wrote:
And hopefully people that develops external blocks e.g. Stefano with
Linotype and maybe the Forrest and Lenya communities will be active in
geting the requirements right.
we'll try ;) we don't have our build system split into blocks yet
though. one thing i noticed yester
Ralph Goers wrote:
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should b
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Now one benefit of cour
31 matches
Mail list logo
