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 <nicolaken@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
|