You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/11/01 13:55:04 UTC
SVN reorg: take 2
The first reorg ahs been needed but is not enough. Other dirs need
placement and have not been yet discussed, and we need to define the
subproject development. I have started, but let's talk about it here
before I continue: below are the points.
1 - Forrest projects are not indipendent
We are delivering a single product called Forrest, that is internally
composed of subprojects. Our release cycle is based on this product;
however we may have interim releases of subprojects in case it's deemed
necessary.
2 - We are not an umbrella project
Umbrella projects are dying at Apache. Jakarta and XML have spun off
many projects and are still doing so: we are one of them :-)
This means that we must not reconfigure ourselves to be an umbrella
project, and we must strive to remain unite.
3 - We shall have a single bin dir
This comes as part of the above, and from use feedback that usually
products have a top level bin dir. This also means setting the
FORREST_HOME the top level directory of Forrest.
4 - Move the main documentation under the forrest root
IOW from
forrest/forrestcore/src/documentation
to
forrest/site
5 - have a single jar repository + no legal dir
As a PMC we have the obbligation to check for the license of what we
distribute. To make it easier I propose that we remove the legal dir and
put all license files in the lib dir, alongside the jars themselves.
The lib dir should be under the forrest root, so that anyone checking
the dirs easily knows where to look -> it makes it more evident hence
transparent.
This will also mean moving under lib the jetty and the ant dirs, that
are now under tools.
6 - Refactor forretcore
a - rename 'forrestcore' to 'main' (like in Ant)
b - move documentation to 'forrest/site' (point 4)
c - move 'core' down two dirs (goes in 'main')
d - rename 'context' as 'webapp'
e - move java up one level
...
In practice, the contents of forrestcore become:
forrest/
bin/
site/
main/
java/
webapp/
fresh-site/
tasks/
var/
targets/
- = 0 = -
There is only one problem here, that is making interim releases of
subprojects if the new release needs a new jar.
This can be solved with the download of dependencies from a repository
or with the addition of the libs in the distro, or by deciding that
interim releases should not change jar dependencies.
Thoughts?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVN reorg: take 2
Posted by Dave Brondsema <da...@brondsema.net>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>
>> I think I've been convinced. I would've liked to see this second
>> discussion before the changes went into SVN, though.
>
>
> Sorry, I thought that we were on the same wavelength, and since I have
> very little time lately to contribute, I just went along.
>
That's ok, we're good now. It's been a very busy list since the
release, it's been hard to keep up with everything.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: SVN reorg: take 2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Nicola Ken Barozzi wrote:
...
>> We had a discussion at Apache a year ago, and the result was that
>> umbrella projects are not the future. AFAIK IIUC it's the current view
>> of the board also now.
>
> Ok, I wasn't aware of that. The subprojects we might have would be
> quite small though.
Actually I wasn't aware you weren't aware (no pun intended).
...
>> Let me ask you a question: have you ever used forrestbar?
>> Better: all Forrest developers that have used it raise your hands.
>
> No. And I'm not aware of any redeeming value in it. Would anybody shed
> a tear if it mysteriously dissappeared? :-)
Ok, then it means that it's one of those subprojects that is not part of
the community. One can decide to incorporate it in the main tool or get
rid of it. I wanna get rid of it at Forrest.
>> Same question: forrestbot?
>
> Yes, and this will (maybe) be part of the ASF website publishing process
> that David has proposed.
My answer is no, and the same for Davis I have seen. Then it may mean
that it's one of those subprojects that is not part of the community.
One can decide to incorporate it in the main tool or get rid of it. I
wanna incorporate it more, as it's vital to Forrest.
We must strive to make all or at least most developers take care of all
the codebase, or else we will rely on a single person.
> I think I've been convinced. I would've liked to see this second
> discussion before the changes went into SVN, though.
Sorry, I thought that we were on the same wavelength, and since I have
very little time lately to contribute, I just went along.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVN reorg: take 2
Posted by Dave Brondsema <da...@brondsema.net>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>
>> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>>
>>> The first reorg ahs been needed but is not enough. Other dirs need
>>> placement and have not been yet discussed, and we need to define the
>>> subproject development. I have started, but let's talk about it here
>>> before I continue: below are the points.
>>>
>>> 1 - Forrest projects are not indipendent
>>>
>>> We are delivering a single product called Forrest, that is internally
>>> composed of subprojects. Our release cycle is based on this product;
>>> however we may have interim releases of subprojects in case it's
>>> deemed necessary.
>>
>>
>> Forrestbar and logos are independent tools.
>
>
> True.
>
> This is also why I had reservations in keeping forrestbar in Forrest,
> remember?
>
> As for logos, my intention is to integrate it as a plugin, and
> forrestdoc also.
>
>> Forrestbot could be, if someone wrote a different "build" workstage.
>
>
> Could be but should not be. the day it became an indipendent tool, it is
> not part of Forrest anymore.
>
>> Editor configurations, like the one for
>> XXE, are independant also. Use case: document writers/editors install
>> and use
>> the XXE configuration to do their document writing, and save/commit
>> changes to
>> their documents. They never run forrest, that is done on a elsewhere
>> (perhaps
>> part of forrestbot or doco or something).
>
>
> I understand what you mean, but they will be doing it for a specific
> version of Forrest, and that is where they should take it from.
>
It'll be for a specific versions of the Forrest document DTDs.
> Maybe you want t multi-jar release? One thing is doing separate releases
> (in time), and another doing a single release of separate packages.
>
What do you mean? Release the XXE tool as a standalone .zip in addition
to releasing it as part of the main forrest .zip?
>>> 2 - We are not an umbrella project
>>>
>>> Umbrella projects are dying at Apache. Jakarta and XML have spun off
>>> many projects and are still doing so: we are one of them :-)
>>> This means that we must not reconfigure ourselves to be an umbrella
>>> project, and we must strive to remain unite.
>>
>>
>> Is the umbrella structure a problem because of the political & developer
>> structure or because of the source code structure?
>
>
> Only because of political & developer structure. It has been an utter
> failure socially, and is one of the prime reasons Avalon collapsed so
> badly.
>
>> I see value in having
>> subprojects have their own src, docs, build directories.
>
>
> Please explain.
>
If a tool can build and operate on it's own without forrest, it should
be segregated to reflect that. This would let people could "svn co"
just that directory, or set up gump dependencies for it/on it.
Actually, thinking of it in terms of a Gump projects is probably good.
Anything that is a seperate project in a gump descriptor should be in
it's own project directory. That's basic project and codeline management.
Forrestbar, forrestdoc, and logos are the only examples I can think of.
But since we plan to incorporate the last two, and forrestbar isn't
much to speak of, I guess this is currently a moot point.
>> I do think the Forrest TLP should remain united politically and
>> developmentally.
>
>
> As I see it, history has showed that making indipendent subprojects
> leads in one way or the other to fragmentation. Communities change,
> people come and go, and separating areas creates fragmentation that
> perpetuates.
>
>> We also need to be prepared for a tool subproject to suddenly grow
>> rapidly and have to seperate
>> cleanly from forrest and become its own TLP.
>
>
> Is this something you actually forsee or just a possibility that you
> want to take into account? For the latter we can always refactor later on.
>
>> Webservices, portals, logging, tcl, DB, and others are umbrella
>> projects also. Ant has an antidote subproject. Are they too planning
>> to break up?
>
>
> Webservices projects are too small to break out. Portals are actually a
> couple of projects. Logging is the same project in different languages.
> DB is basically only OJB and tcl was created much earlier. Antidote is
> dead.
>
> We had a discussion at Apache a year ago, and the result was that
> umbrella projects are not the future. AFAIK IIUC it's the current view
> of the board also now.
Ok, I wasn't aware of that. The subprojects we might have would be
quite small though.
>
>> I think if
>> the subprojects are topically related it can work fine. (XML and
>> Jakarta house
>> many subprojects and are technologically related but not topically
>> related).
>
>
> Avalon was basically the samme project built in components, and each
> component had become a feud. I'm scared to death in seeing it repeated.
>
>>> 3 - We shall have a single bin dir
>>
>>
>>> 4 - Move the main documentation under the forrest root
>>
>>
>>> 5 - have a single jar repository + no legal dir
>>
>>
>>> 6 - Refactor forretcore
>>
>>
>> I like all of these.
>>
>> I see value in having a one single project, but my primary concern is
>> that it
>> will eventually become too big.
>
>
> Let's not solve things too early.
>
Good point.
>> Some of our tools should be able to be
>> downloaded, built, and used without forrest itself.
>
>
> Let me ask you a question: have you ever used forrestbar?
> Better: all Forrest developers that have used it raise your hands.
>
No. And I'm not aware of any redeeming value in it. Would anybody shed
a tear if it mysteriously dissappeared? :-)
> Same question: forrestbot?
>
Yes, and this will (maybe) be part of the ASF website publishing process
that David has proposed.
What is your point here?
I think I've been convinced. I would've liked to see this second
discussion before the changes went into SVN, though.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: SVN reorg: take 2
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
> [snip]
> > Some of our tools should be able to be
> > downloaded, built, and used without forrest itself.
>
> Let me ask you a question: have you ever used forrestbar?
> Better: all Forrest developers that have used it raise your hands.
I raised my two hands. I don't use it at the moment.
> Same question: forrestbot?
If i had more hands i would raise them again.
I have used forrestbot, and when i get my servers upgraded
will get more serious.
If these questions have any bearing then they would need
to be asked specifically.
--
David Crossley
Re: SVN reorg: take 2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>>The first reorg ahs been needed but is not enough. Other dirs need
>>placement and have not been yet discussed, and we need to define the
>>subproject development. I have started, but let's talk about it here
>>before I continue: below are the points.
>>
>>1 - Forrest projects are not indipendent
>>
>>We are delivering a single product called Forrest, that is internally
>>composed of subprojects. Our release cycle is based on this product;
>>however we may have interim releases of subprojects in case it's deemed
>>necessary.
>
> Forrestbar and logos are independent tools.
True.
This is also why I had reservations in keeping forrestbar in Forrest,
remember?
As for logos, my intention is to integrate it as a plugin, and
forrestdoc also.
> Forrestbot could be, if someone wrote a different "build" workstage.
Could be but should not be. the day it became an indipendent tool, it is
not part of Forrest anymore.
> Editor configurations, like the one for
> XXE, are independant also. Use case: document writers/editors install and use
> the XXE configuration to do their document writing, and save/commit changes to
> their documents. They never run forrest, that is done on a elsewhere (perhaps
> part of forrestbot or doco or something).
I understand what you mean, but they will be doing it for a specific
version of Forrest, and that is where they should take it from.
Maybe you want t multi-jar release? One thing is doing separate releases
(in time), and another doing a single release of separate packages.
>>2 - We are not an umbrella project
>>
>>Umbrella projects are dying at Apache. Jakarta and XML have spun off
>>many projects and are still doing so: we are one of them :-)
>>This means that we must not reconfigure ourselves to be an umbrella
>>project, and we must strive to remain unite.
>
> Is the umbrella structure a problem because of the political & developer
> structure or because of the source code structure?
Only because of political & developer structure. It has been an utter
failure socially, and is one of the prime reasons Avalon collapsed so badly.
> I see value in having
> subprojects have their own src, docs, build directories.
Please explain.
> I do think the Forrest TLP should remain united politically and
> developmentally.
As I see it, history has showed that making indipendent subprojects
leads in one way or the other to fragmentation. Communities change,
people come and go, and separating areas creates fragmentation that
perpetuates.
> We also need to be prepared for a tool subproject to suddenly grow
> rapidly and have to seperate
> cleanly from forrest and become its own TLP.
Is this something you actually forsee or just a possibility that you
want to take into account? For the latter we can always refactor later on.
> Webservices, portals, logging, tcl, DB, and others are umbrella projects also.
> Ant has an antidote subproject. Are they too planning to break up?
Webservices projects are too small to break out. Portals are actually a
couple of projects. Logging is the same project in different languages.
DB is basically only OJB and tcl was created much earlier. Antidote is dead.
We had a discussion at Apache a year ago, and the result was that
umbrella projects are not the future. AFAIK IIUC it's the current view
of the board also now.
> I think if
> the subprojects are topically related it can work fine. (XML and Jakarta house
> many subprojects and are technologically related but not topically related).
Avalon was basically the samme project built in components, and each
component had become a feud. I'm scared to death in seeing it repeated.
>>3 - We shall have a single bin dir
>
>>4 - Move the main documentation under the forrest root
>
>>5 - have a single jar repository + no legal dir
>
>>6 - Refactor forretcore
>
> I like all of these.
>
> I see value in having a one single project, but my primary concern is that it
> will eventually become too big.
Let's not solve things too early.
> Some of our tools should be able to be
> downloaded, built, and used without forrest itself.
Let me ask you a question: have you ever used forrestbar?
Better: all Forrest developers that have used it raise your hands.
Same question: forrestbot?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVN reorg: take 2
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
> The first reorg ahs been needed but is not enough. Other dirs need
> placement and have not been yet discussed, and we need to define the
> subproject development. I have started, but let's talk about it here
> before I continue: below are the points.
>
> 1 - Forrest projects are not indipendent
>
> We are delivering a single product called Forrest, that is internally
> composed of subprojects. Our release cycle is based on this product;
> however we may have interim releases of subprojects in case it's deemed
> necessary.
>
Forrestbar and logos are independent tools. Forrestbot could be, if someone
wrote a different "build" workstage. Editor configurations, like the one for
XXE, are independant also. Use case: document writers/editors install and use
the XXE configuration to do their document writing, and save/commit changes to
their documents. They never run forrest, that is done on a elsewhere (perhaps
part of forrestbot or doco or something).
> 2 - We are not an umbrella project
>
> Umbrella projects are dying at Apache. Jakarta and XML have spun off
> many projects and are still doing so: we are one of them :-)
> This means that we must not reconfigure ourselves to be an umbrella
> project, and we must strive to remain unite.
>
Is the umbrella structure a problem because of the political & developer
structure or because of the source code structure? I see value in having
subprojects have their own src, docs, build directories. I do think the Forrest
TLP should remain united politically and developmentally. We also need to be
prepared for a tool subproject to suddenly grow rapidly and have to seperate
cleanly from forrest and become its own TLP.
Webservices, portals, logging, tcl, DB, and others are umbrella projects also.
Ant has an antidote subproject. Are they too planning to break up? I think if
the subprojects are topically related it can work fine. (XML and Jakarta house
many subprojects and are technologically related but not topically related).
> 3 - We shall have a single bin dir
> 4 - Move the main documentation under the forrest root
> 5 - have a single jar repository + no legal dir
> 6 - Refactor forretcore
I like all of these.
I see value in having a one single project, but my primary concern is that it
will eventually become too big. Some of our tools should be able to be
downloaded, built, and used without forrest itself.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: SVN reorg: take 2
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> There is only one problem here, that is making interim releases of
> subprojects if the new release needs a new jar.
With respect to plugins and skins (not a subproject yet, but could be in
the future) there is no problem since Forrest will only download a
plugin/skin with a name that indicates it will work with the currently
executing version of Forrest. For example:
OpenOffice.org-0.6.zip will be downloaded for 0.6 version of Forrest
OpenOffice.org-0.7-dev.zip for 0.7-dev version
The mechanism falls back on a filename with no version number if the
above fails.
[NOTE, in writing this I realised that both skins and plugins suffer
from the same problem. They do not upgrade their version of a plugin
when Forrest is upgraded. I'll enter a issue on this]
Ross
Re: SVN reorg: take 2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>4 - Move the main documentation under the forrest root
>>
>>IOW from
>>
>> forrest/forrestcore/src/documentation
>>
>>to
>> forrest/site
>
> What is the reason for this move? I would prefer that
> the documentation be contained with the main product
> as it is now. That way the users have a local copy
> of the documentation that matches their version.
Well, the main product IMV is forrest/ :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVN reorg: take 2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
>
>>Nicola Ken Barozzi wrote:
>>
>>>4 - Move the main documentation under the forrest root
>>>
>>>IOW from
>>>
>>> forrest/forrestcore/src/documentation
>>>
>>>to
>>>
>>> forrest/site
>>
>>What is the reason for this move? I would prefer that
>>the documentation be contained with the main product
>>as it is now. That way the users have a local copy
>>of the documentation that matches their version.
>
>
> Ah, sorry, i see what you are suggesting now.
> I had leaped to the conclusion that you were moving
> the docs out of the trunk.
>
> Would it be better to call it forrest/docs ?
I'm thinking of a future where subprojects have their docs/ dir and the
site/ does not contain technical docs.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVN reorg: take 2
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
> >
> > 4 - Move the main documentation under the forrest root
> >
> > IOW from
> >
> > forrest/forrestcore/src/documentation
> >
> > to
> >
> > forrest/site
>
> What is the reason for this move? I would prefer that
> the documentation be contained with the main product
> as it is now. That way the users have a local copy
> of the documentation that matches their version.
Ah, sorry, i see what you are suggesting now.
I had leaped to the conclusion that you were moving
the docs out of the trunk.
Would it be better to call it forrest/docs ?
--
David Crossley
Re: SVN reorg: take 2
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
>
> 4 - Move the main documentation under the forrest root
>
> IOW from
>
> forrest/forrestcore/src/documentation
>
> to
>
> forrest/site
What is the reason for this move? I would prefer that
the documentation be contained with the main product
as it is now. That way the users have a local copy
of the documentation that matches their version.
--David