You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2004/10/22 15:58:58 UTC
[proposal] SVN restructure for subprojects
Now that we are a top level project, and growing to include "subprojects"
(anything not a core part of forrest), we need to handle this properly in our
code repository. Currently we hold subprojects in src/ (forrestbot, forrestbar,
forrestlogos) and in scratchpad/ (forrestdoc, eclipsePlugin, XXE-config). Ross
work on forrest plugins needs a location too. See FOR-233 also.
I propose:
Create everything (including Forrest itself) as a subdirectory of our existing
"forrest". It would look like this:
forrest/
site/ (unchanged)
dist/ (unchanged)
forrest/ (pushed down)
trunk/
branches/
tags/
eclipsePlugin/ (moved)
trunk/
branches/
tags/
xxePlugin/ (moved)
TBT
forrestbot/ (moved)
TBT
forrestbar/ (moved)
TBT
plugins/ (new)
OpenOffice.org/
TBT
DocBook4.3/
TBT
Each subproject would have it's own trunk/, branches/, and tag/ (TBT)
subdirectories. The plugins subproject would have its own subprojects so the
TBT directories would be under plugins/OpenOffice.org for example.
Implications: the current checkout of forrest/trunk that everyone has will
become invalid. They will have to do a svn switch to forrest/forrest/trunk.
This is significant, but now is probably the best time to make the change since
the majority of users are using the 0.6 release and not SVN. As time passes,
more users will begin using SVN to take advantage of unreleased features.
Note about SVN: branches and tags are not really anything special in subversion
like they are in CVS. They are just fast, lightweight copies (references
really) of files.
The process for implementing this would probably be first, to move forrest/TBT
to forrest/forrest/TBT. After that is working, we will pull out the subprojects
one at a time to their new location.
Thoughts? Questions? Suggestions?
We'll definitely need an approving vote before we do this :-)
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: build system
Posted by Dave Brondsema <da...@brondsema.net>.
David Crossley wrote:
> Dave Brondsema wrote:
>>Another alternative to consider is to use a real scripting language instead of
>>Ant to do our builds. In my experience with skin fetching, ant simply isn't
>>designed to do the things we want to do. I am not familiar with python, but I
>>think it would be a good candidate.
>
>
> Is Ant able to call a python script to do certain tasks?
>
Ant can embed scripting. I can't believe I forgot about this. I've
used rhino (a Javascript implementation in Java) at work to do this. It
can be a real pain to debug because it's embedded, but it does make
stuff easier.
See http://ant.apache.org/manual/OptionalTasks/script.html (and
scriptdef and macrodef).
It looks like python, java, groovy, and other less popular languages are
supported.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: build system
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Dave Brondsema wrote:
>
>>Quoting Nicola Ken Barozzi:
...
>>>For Ant I am willing to help set it up in a way that it makes it easy to
>>>do the above multi-project. I see it as a must that we use a lib
>>>download system ALA Maven.
>
> Why is it a *must*?
:-)
OTOMH
1. It's not reasonable for a Maven user to have to redownload the libs
we use just because we don't use a repository
2. The downloaded jars can be shared easily between Forrest projects
easily without having to put them all in the classpath or having to
declare them by hand in the ant scripts
3. The downloaded jars can come from mirrors even for those tat use the
trunk
...
>>With my experience and understanding of maven, we would have to write plugins to
>>do what we want. Our software is not a simple standard java package, since we
>>do a lot with cocoon, copyless issues, and skin/plugin fetching. Since this is
>>so unique to our project, I don't think maven's standard build system will help
>>us much.
>
> I don't know much about Maven, but resonate with Dave's comments.
>
> Are there simple repository systems that we could use
> for the "lib download" aspect.
> e.g. Apache Depot http://incubator.apache.org/depot/
+1
>>Matching a standard directory structure is certainly good. Not sure about
>>automatically downloading jars. That could be good, but I don't see a real need
>>for it; things work fine how they are.
>>
>>Another alternative to consider is to use a real scripting language instead of
>>Ant to do our builds. In my experience with skin fetching, ant simply isn't
>>designed to do the things we want to do. I am not familiar with python, but I
>>think it would be a good candidate.
>
> Is Ant able to call a python script to do certain tasks?
Yup, embedded.
Now I can say that I'm fully +1 for using Ant. I wanted to be sure I
didn't step on other's toes by assuming it per default :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: build system (was: [proposal] SVN restructure for subprojects)
Posted by David Crossley <cr...@apache.org>.
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi:
>
> > Notice the 'bin' directory where users would think of finding it, as a
> > single thing to add to the system path variable. the trunk would become
> > the new FORREST_HOME
> >
> > Also, this would mean that we have to rethink our build system.
>
> I would like to see a SVN restructure in the near future, with minimal changes
> to the build system. Discussion and implementation of changes to FORREST_HOME,
> the bin location, and the build system in general will take *much* longer.
Yes do it in stages.
> > - Please no flame wars -
> >
> > As I see it we have two options: Ant and Maven.
> >
> > For Ant I am willing to help set it up in a way that it makes it easy to
> > do the above multi-project. I see it as a must that we use a lib
> > download system ALA Maven.
Why is it a *must*?
> > Other than this, I'm really open to any sensible technical comment on
> > this, along with proposals in helping out.
> >
>
> With my experience and understanding of maven, we would have to write plugins to
> do what we want. Our software is not a simple standard java package, since we
> do a lot with cocoon, copyless issues, and skin/plugin fetching. Since this is
> so unique to our project, I don't think maven's standard build system will help
> us much.
I don't know much about Maven, but resonate with Dave's comments.
Are there simple repository systems that we could use
for the "lib download" aspect.
e.g. Apache Depot http://incubator.apache.org/depot/
> Matching a standard directory structure is certainly good. Not sure about
> automatically downloading jars. That could be good, but I don't see a real need
> for it; things work fine how they are.
>
> Another alternative to consider is to use a real scripting language instead of
> Ant to do our builds. In my experience with skin fetching, ant simply isn't
> designed to do the things we want to do. I am not familiar with python, but I
> think it would be a good candidate.
Is Ant able to call a python script to do certain tasks?
--
David Crossley
Re: build system (was: [proposal] SVN restructure for subprojects)
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Notice the 'bin' directory where users would think of finding it, as a
> single thing to add to the system path variable. the trunk would become
> the new FORREST_HOME
>
> Also, this would mean that we have to rethink our build system.
I would like to see a SVN restructure in the near future, with minimal changes
to the build system. Discussion and implementation of changes to FORREST_HOME,
the bin location, and the build system in general will take *much* longer.
> - Please no flame wars -
>
> As I see it we have two options: Ant and Maven.
>
> For Ant I am willing to help set it up in a way that it makes it easy to
> do the above multi-project. I see it as a must that we use a lib
> download system ALA Maven.
>
> Other than this, I'm really open to any sensible technical comment on
> this, along with proposals in helping out.
>
With my experience and understanding of maven, we would have to write plugins to
do what we want. Our software is not a simple standard java package, since we
do a lot with cocoon, copyless issues, and skin/plugin fetching. Since this is
so unique to our project, I don't think maven's standard build system will help
us much.
Matching a standard directory structure is certainly good. Not sure about
automatically downloading jars. That could be good, but I don't see a real need
for it; things work fine how they are.
Another alternative to consider is to use a real scripting language instead of
Ant to do our builds. In my experience with skin fetching, ant simply isn't
designed to do the things we want to do. I am not familiar with python, but I
think it would be a good candidate.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [proposal] SVN restructure for subprojects
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Dave Brondsema wrote:
>
>>The tools may be for more than just editors. For example, eclipse can
>>start/stop a forrest jetty server I think.
>>
>>What about "externaltools" or just "tools"? We probably don't need the
>>"forrest" prefix since we're already within repos/asf/forrest
>
>
> I had a similar response half-prepared. Just "tools"
> would suffice.
+1
> Yeah, why does the proposed SVN restructure have the "forrest*"
> prefix for everything? The "forrestbot" and "forrestbar"
> i can understand, but not the rest.
It was to avoid confusion between similar sounding names, however, if
the tools stuff gos in a tools dir then it is no longer needed.
Ross
Re: [proposal] SVN restructure for subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
...
> whiteboard == scratchpad, correct?
Yup, I prefer 'whiteboard' now :-)
> The scratchpad should be pulled out of forrestcore also, and made a peer
> to "tools" and "plugins", I think.
Agreed.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] SVN restructure for subprojects
Posted by Dave Brondsema <da...@brondsema.net>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>
> ATM logos is a tool as are eclipse and xxe, and I'd put it there with them.
>
>> What about forrestdoc? Just calling it "doc" seems way too generic.
>> I think that eventually it will take the form of some plugin.
>
>
> Yup.
>
>> Could we guess what the name of that would be? Maybe
>> "projectmetrics", "projectreports", "codereports", "srcreports"? Or
>> just KISS and stay with "forrestdoc".
>
>
> Let's keep it in the whiteboard for now, without changing anything :-)
>
whiteboard == scratchpad, correct?
The scratchpad should be pulled out of forrestcore also, and made a peer
to "tools" and "plugins", I think.
BTW, I'm preparing a summary of this thread for vote.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: [proposal] SVN restructure for subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Nicola Ken Barozzi wrote:
...
>> We may as well do away with all the prefixes.
>
> Forrestbot and forrestbar are already known by those names, so I think
> we probably should keep them prefixed.
bleah ;-)
> Logos would be *good* to not be prefixed, since it isn't related to
> forrest at all currently. Eclipse and XXE plugins also are just fine
> without the prefix.
ATM logos is a tool as are eclipse and xxe, and I'd put it there with them.
> What about forrestdoc? Just calling it "doc" seems way too generic. I
> think that eventually it will take the form of some plugin.
Yup.
> Could we
> guess what the name of that would be? Maybe "projectmetrics",
> "projectreports", "codereports", "srcreports"? Or just KISS and stay
> with "forrestdoc".
Let's keep it in the whiteboard for now, without changing anything :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] SVN restructure for subprojects
Posted by Dave Brondsema <da...@brondsema.net>.
Nicola Ken Barozzi wrote:
> David Crossley wrote:
>
>> Dave Brondsema wrote:
>>
>>> The tools may be for more than just editors. For example, eclipse
>>> can start/stop a forrest jetty server I think.
>>>
>>> What about "externaltools" or just "tools"? We probably don't need
>>> the "forrest" prefix since we're already within repos/asf/forrest
>>
>>
>> I had a similar response half-prepared. Just "tools"
>> would suffice.
>
>
> +1, I like it (especially moving the eclipse, xxe, etc stuff under there).
>
>> Yeah, why does the proposed SVN restructure have the "forrest*"
>> prefix for everything? The "forrestbot" and "forrestbar"
>> i can understand, but not the rest.
>
>
> We may as well do away with all the prefixes.
>
Forrestbot and forrestbar are already known by those names, so I think
we probably should keep them prefixed.
Logos would be *good* to not be prefixed, since it isn't related to
forrest at all currently. Eclipse and XXE plugins also are just fine
without the prefix.
What about forrestdoc? Just calling it "doc" seems way too generic. I
think that eventually it will take the form of some plugin. Could we
guess what the name of that would be? Maybe "projectmetrics",
"projectreports", "codereports", "srcreports"? Or just KISS and stay
with "forrestdoc".
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: [proposal] SVN restructure for subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Dave Brondsema wrote:
>
>>The tools may be for more than just editors. For example, eclipse can
>>start/stop a forrest jetty server I think.
>>
>>What about "externaltools" or just "tools"? We probably don't need the
>>"forrest" prefix since we're already within repos/asf/forrest
>
> I had a similar response half-prepared. Just "tools"
> would suffice.
+1, I like it (especially moving the eclipse, xxe, etc stuff under there).
> Yeah, why does the proposed SVN restructure have the "forrest*"
> prefix for everything? The "forrestbot" and "forrestbar"
> i can understand, but not the rest.
We may as well do away with all the prefixes.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] SVN restructure for subprojects
Posted by David Crossley <cr...@apache.org>.
Dave Brondsema wrote:
>
> The tools may be for more than just editors. For example, eclipse can
> start/stop a forrest jetty server I think.
>
> What about "externaltools" or just "tools"? We probably don't need the
> "forrest" prefix since we're already within repos/asf/forrest
I had a similar response half-prepared. Just "tools"
would suffice.
Yeah, why does the proposed SVN restructure have the "forrest*"
prefix for everything? The "forrestbot" and "forrestbar"
i can understand, but not the rest.
--
David Crossley
Re: [proposal] SVN restructure for subprojects
Posted by Dave Brondsema <da...@brondsema.net>.
Ross Gardler wrote:
> Rick Tessner wrote:
>
>> Dave Brondsema wrote:
>>
>>> Any more thoughts on this? We should put it to a vote soon, so we
>>> can get
>>> the plugins in SVN.
>>
>>
>>
>>>> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>>
>>
>>
>>>>> forrest/
>>>>> branches/**
>>>>> tags/**
>>>>> trunk/
>>>>> bin/
>>>>> site/
>>>>> dist/
>>>>> forrestcore/
>>>>> forrestbot/
>>>>> forrestbar/
>>>>> forresteclipse/
>>>>> forrestxxe/
>>>>> forrestplugins/
>>>>> OpenOffice.org/
>>>>> DocBook4.3/
>>>>>
>>
>> Hi all,
>>
>> I just have one little nit-pick on this and that would be the
>> "forresteclipse" and "forrestxxe". I was thinking it be nice to keep
>> these under a separate directory such as "aids" or "tools" or
>> "contenttools", "contentaids", etc.
>>
>> I just thought that there may be folk out there using XMLSpy or their
>> favorite content creation tool and may have tools bars, css, configs
>> that help with a given tool.
>>
>> These things may well be plugins for their favorite tool, but they are
>> not forrest plugins.
>>
>> It seems it could get cluttered on the "top-level" directory with
>> things like "forrestxmlspy", "forrestgnumeric" etc.
>>
>> Thoughts?
>
>
> We could place the editor extensions inside an "forresteditors"
> directory. This would have the effect of reducing clutter
> (forresteclipse and forrestxxe would fit in there to start with. It
> would also make it more obvious to the casual observer what these items
> are.
>
> Ross
The tools may be for more than just editors. For example, eclipse can
start/stop a forrest jetty server I think.
What about "externaltools" or just "tools"? We probably don't need the
"forrest" prefix since we're already within repos/asf/forrest
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: [proposal] SVN restructure for subprojects
Posted by Ross Gardler <rg...@apache.org>.
Rick Tessner wrote:
> Dave Brondsema wrote:
>
>> Any more thoughts on this? We should put it to a vote soon, so we can
>> get
>> the plugins in SVN.
>
>
>>> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>
>>>> forrest/
>>>> branches/**
>>>> tags/**
>>>> trunk/
>>>> bin/
>>>> site/
>>>> dist/
>>>> forrestcore/
>>>> forrestbot/
>>>> forrestbar/
>>>> forresteclipse/
>>>> forrestxxe/
>>>> forrestplugins/
>>>> OpenOffice.org/
>>>> DocBook4.3/
>>>>
>
> Hi all,
>
> I just have one little nit-pick on this and that would be the
> "forresteclipse" and "forrestxxe". I was thinking it be nice to keep
> these under a separate directory such as "aids" or "tools" or
> "contenttools", "contentaids", etc.
>
> I just thought that there may be folk out there using XMLSpy or their
> favorite content creation tool and may have tools bars, css, configs
> that help with a given tool.
>
> These things may well be plugins for their favorite tool, but they are
> not forrest plugins.
>
> It seems it could get cluttered on the "top-level" directory with things
> like "forrestxmlspy", "forrestgnumeric" etc.
>
> Thoughts?
We could place the editor extensions inside an "forresteditors"
directory. This would have the effect of reducing clutter
(forresteclipse and forrestxxe would fit in there to start with. It
would also make it more obvious to the casual observer what these items are.
Ross
Re: [proposal] SVN restructure for subprojects
Posted by Rick Tessner <ri...@onnadayr.ca>.
Dave Brondsema wrote:
> Any more thoughts on this? We should put it to a vote soon, so we can get
> the plugins in SVN.
>>Quoting Nicola Ken Barozzi <ni...@apache.org>:
>>>forrest/
>>> branches/**
>>> tags/**
>>> trunk/
>>> bin/
>>> site/
>>> dist/
>>> forrestcore/
>>> forrestbot/
>>> forrestbar/
>>> forresteclipse/
>>> forrestxxe/
>>> forrestplugins/
>>> OpenOffice.org/
>>> DocBook4.3/
>>>
Hi all,
I just have one little nit-pick on this and that would be the
"forresteclipse" and "forrestxxe". I was thinking it be nice to keep
these under a separate directory such as "aids" or "tools" or
"contenttools", "contentaids", etc.
I just thought that there may be folk out there using XMLSpy or their
favorite content creation tool and may have tools bars, css, configs
that help with a given tool.
These things may well be plugins for their favorite tool, but they are
not forrest plugins.
It seems it could get cluttered on the "top-level" directory with things
like "forrestxmlspy", "forrestgnumeric" etc.
Thoughts?
--
rick@onnadayr.ca
IT Firefighting and Prevention
Re: [proposal] SVN restructure for subprojects
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>
>> Any more thoughts on this? We should put it to a vote soon, so we can
>> get
>> the plugins in SVN.
Personally, I have nothing more to add at this stage. I am in agreement
with Nicola Ken's modifications.
Ross
Re: [proposal] SVN restructure for subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Any more thoughts on this? We should put it to a vote soon, so we can get
> the plugins in SVN.
>
> On Fri, 22 Oct 2004, Dave Brondsema wrote:
>
>>core may get confused with the "src/core" directory, which even end-users have
>>seen since it's used when they set FORREST_HOME. Perhaps forrestmain?
I still prefer forrestcore, as the forrestcore directory will probably
contain what is now in the core directory.
...
>>> site/
>>> dist/
>>> forrestcore/
>>> forrestbot/
>>> forrestbar/
>>> forresteclipse/
>>> forrestxxe/
>>> forrestplugins/
>>> OpenOffice.org/
>>> DocBook4.3/
...
>>Did you mean to put site and dist as subdirectories of trunk? If so, why? I
>>think the current setup for those is good.
Sorry, an error on my part. Current setup is fine.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] SVN restructure for subprojects
Posted by Dave Brondsema <da...@brondsema.net>.
Any more thoughts on this? We should put it to a vote soon, so we can get
the plugins in SVN.
On Fri, 22 Oct 2004, Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
> > Dave Brondsema wrote:
> > ...
> > > See FOR-233 also.
> > >
> > > I propose:
> > >
> > > Create everything (including Forrest itself) as a subdirectory of our
> > existing
> > > "forrest".
> > ...
> > > It would look like this:
> > >
> > > forrest/
> > > site/ (unchanged)
> > > dist/ (unchanged)
> > > forrest/ (pushed down)
> >
> > </nitpicking>
> > It's confusing to have a forrest/forrest directory, why
> > not forrest/core or forrest/forrestcore?
> > </nitpicking>
> >
>
> core may get confused with the "src/core" directory, which even end-users have
> seen since it's used when they set FORREST_HOME. Perhaps forrestmain?
>
> > > trunk/
> > > branches/
> > > tags/
> > > eclipsePlugin/ (moved)
> >
> > </nitpicking>
> > There is confusion between forrest/plugins and eclipsePlugin, as they
> > both have 'plugin' in it, and there micht also actually be a plugin
> > for eclipse formatted docs in the future
> > </nitpicking>
>
> Yes.
>
> > There is a problem though... what will happen with the copyless stuff?
> >
>
> What do you mean?
>
> > I would see this as easier to use and maintain (given cheap copies):
> >
> >
> > forrest/
> > branches/**
> > tags/**
> > trunk/
> > bin/
> > site/
> > dist/
> > forrestcore/
> > forrestbot/
> > forrestbar/
> > forresteclipse/
> > forrestxxe/
> > forrestplugins/
> > OpenOffice.org/
> > DocBook4.3/
> >
>
> This also lets people check out "everything" by checking out trunk. One
> disadvantage I forgot to mention in my first proposal was that you would have to
> check out each trunk seperately.
>
> Did you mean to put site and dist as subdirectories of trunk? If so, why? I
> think the current setup for those is good.
>
> > Notice the 'bin' directory where users would think of finding it, as a
> > single thing to add to the system path variable. the trunk would become
> > the new FORREST_HOME
> >
> > Also, this would mean that we have to rethink our build system.
> >
>
> Yes, but let's keep the two issues seperate. I will reply in a seperate email.
>
> > - Please no flame wars -
> >
> > As I see it we have two options: Ant and Maven.
> >
> > For Ant I am willing to help set it up in a way that it makes it easy to
> > do the above multi-project. I see it as a must that we use a lib
> > download system ALA Maven.
> >
> > Other than this, I'm really open to any sensible technical comment on
> > this, along with proposals in helping out.
> >
> > Again:
> >
> > - Please no flame wars -
> >
> > (it's also a reminder for me)
> >
> > > We'll definitely need an approving vote before we do this :-)
> >
> > --
> > Nicola Ken Barozzi nicolaken@apache.org
> > - verba volant, scripta manent -
> > (discussions get forgotten, just code remains)
> > ---------------------------------------------------------------------
> >
> >
>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [proposal] SVN restructure for subprojects
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Dave Brondsema wrote:
> ...
> > See FOR-233 also.
> >
> > I propose:
> >
> > Create everything (including Forrest itself) as a subdirectory of our
> existing
> > "forrest".
> ...
> > It would look like this:
> >
> > forrest/
> > site/ (unchanged)
> > dist/ (unchanged)
> > forrest/ (pushed down)
>
> </nitpicking>
> It's confusing to have a forrest/forrest directory, why
> not forrest/core or forrest/forrestcore?
> </nitpicking>
>
core may get confused with the "src/core" directory, which even end-users have
seen since it's used when they set FORREST_HOME. Perhaps forrestmain?
> > trunk/
> > branches/
> > tags/
> > eclipsePlugin/ (moved)
>
> </nitpicking>
> There is confusion between forrest/plugins and eclipsePlugin, as they
> both have 'plugin' in it, and there micht also actually be a plugin
> for eclipse formatted docs in the future
> </nitpicking>
Yes.
> There is a problem though... what will happen with the copyless stuff?
>
What do you mean?
> I would see this as easier to use and maintain (given cheap copies):
>
>
> forrest/
> branches/**
> tags/**
> trunk/
> bin/
> site/
> dist/
> forrestcore/
> forrestbot/
> forrestbar/
> forresteclipse/
> forrestxxe/
> forrestplugins/
> OpenOffice.org/
> DocBook4.3/
>
This also lets people check out "everything" by checking out trunk. One
disadvantage I forgot to mention in my first proposal was that you would have to
check out each trunk seperately.
Did you mean to put site and dist as subdirectories of trunk? If so, why? I
think the current setup for those is good.
> Notice the 'bin' directory where users would think of finding it, as a
> single thing to add to the system path variable. the trunk would become
> the new FORREST_HOME
>
> Also, this would mean that we have to rethink our build system.
>
Yes, but let's keep the two issues seperate. I will reply in a seperate email.
> - Please no flame wars -
>
> As I see it we have two options: Ant and Maven.
>
> For Ant I am willing to help set it up in a way that it makes it easy to
> do the above multi-project. I see it as a must that we use a lib
> download system ALA Maven.
>
> Other than this, I'm really open to any sensible technical comment on
> this, along with proposals in helping out.
>
> Again:
>
> - Please no flame wars -
>
> (it's also a reminder for me)
>
> > We'll definitely need an approving vote before we do this :-)
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [proposal] SVN restructure for subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
> Is it possible to have different rights for each of the directories
> in SVN.
Yes
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] SVN restructure for subprojects
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
>> I would see this as easier to use and maintain (given cheap copies):
>>
>>
>> forrest/
>> branches/**
>> tags/**
>> trunk/
>> bin/
>> site/
>> dist/
>> forrestcore/
>> forrestbot/
>> forrestbar/
>> forresteclipse/
>> forrestxxe/
>> forrestplugins/
>> OpenOffice.org/
>> DocBook4.3/
>
>
>
> This feels better somehow, at the very least we should use these names
> for the reasons Nicola Ken puts forward. The only (minor) drawback I see
> is the length of the URLS for checkouts etc.
One other point that was raised when discussing the plugins location in
SVN. Is it possible to have different rights for each of the directories
in SVN. That is can we make someone a committer on
forrestplugins/OpenOffice.org and not on forrestcore? I'm not sure we
will ever want to do this, but we may.
Ross
Re: [proposal] SVN restructure for subprojects
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
> ...
>
>> See FOR-233 also.
>>
>> I propose:
>>
>> Create everything (including Forrest itself) as a subdirectory of our
>> existing
>> "forrest".
>
> ...
>
>> It would look like this:
>>
>> forrest/
>> site/ (unchanged)
>> dist/ (unchanged)
>> forrest/ (pushed down)
>
...
> I would see this as easier to use and maintain (given cheap copies):
>
>
> forrest/
> branches/**
> tags/**
> trunk/
> bin/
> site/
> dist/
> forrestcore/
> forrestbot/
> forrestbar/
> forresteclipse/
> forrestxxe/
> forrestplugins/
> OpenOffice.org/
> DocBook4.3/
This feels better somehow, at the very least we should use these names
for the reasons Nicola Ken puts forward. The only (minor) drawback I see
is the length of the URLS for checkouts etc.
> Notice the 'bin' directory where users would think of finding it, as a
> single thing to add to the system path variable. the trunk would become
> the new FORREST_HOME
+1 it may be a small point but it is an important one, I know of a
number of people who have been bitten by this (even though it is documented)
> Also, this would mean that we have to rethink our build system.
>
> - Please no flame wars -
>
> As I see it we have two options: Ant and Maven.
<snip/>
> Other than this, I'm really open to any sensible technical comment on
> this, along with proposals in helping out.
I know very little of Maven. I understand what it is doing, but I am
also aware of many of the "discussions" it generates that seem to end up
arguments. Therefore, I will say nothing other than I cannot help with
setting up a Maven build system (but of course I will help maintain it
if that is the way we go).
One thing does occur to me though. Maven is quite widely used and if we
use it ourselves I am sure we will find more motivation for integrating
Forrest into it. This could expand the user base of Forrest.
Ross
Re: [proposal] SVN restructure for subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
...
> See FOR-233 also.
>
> I propose:
>
> Create everything (including Forrest itself) as a subdirectory of our existing
> "forrest".
...
> It would look like this:
>
> forrest/
> site/ (unchanged)
> dist/ (unchanged)
> forrest/ (pushed down)
</nitpicking>
It's confusing to have a forrest/forrest directory, why
not forrest/core or forrest/forrestcore?
</nitpicking>
> trunk/
> branches/
> tags/
> eclipsePlugin/ (moved)
</nitpicking>
There is confusion between forrest/plugins and eclipsePlugin, as they
both have 'plugin' in it, and there micht also actually be a plugin
for eclipse formatted docs in the future
</nitpicking>
> trunk/
> branches/
> tags/
> xxePlugin/ (moved)
</nitpicking>
Same as eclipsePlugin...
</nitpicking>
> TBT
> forrestbot/ (moved)
> TBT
> forrestbar/ (moved)
> TBT
> plugins/ (new)
> OpenOffice.org/
> TBT
> DocBook4.3/
> TBT
There is a problem though... what will happen with the copyless stuff?
I would see this as easier to use and maintain (given cheap copies):
forrest/
branches/**
tags/**
trunk/
bin/
site/
dist/
forrestcore/
forrestbot/
forrestbar/
forresteclipse/
forrestxxe/
forrestplugins/
OpenOffice.org/
DocBook4.3/
Notice the 'bin' directory where users would think of finding it, as a
single thing to add to the system path variable. the trunk would become
the new FORREST_HOME
Also, this would mean that we have to rethink our build system.
- Please no flame wars -
As I see it we have two options: Ant and Maven.
For Ant I am willing to help set it up in a way that it makes it easy to
do the above multi-project. I see it as a must that we use a lib
download system ALA Maven.
Other than this, I'm really open to any sensible technical comment on
this, along with proposals in helping out.
Again:
- Please no flame wars -
(it's also a reminder for me)
> We'll definitely need an approving vote before we do this :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------