On 6/8/06, James M Snell <[EMAIL PROTECTED]> wrote:
That layout works for me. It's very close to what I already have in the image I'm preparing to check in. Question: should we have contrib and sandbox folders in there at the same level as trunk/tags/branches? I'd personally prefer to keep those things separate from the main code. Also, I've just been working on some simple static HTML pages for the project website (I've yet to actually see any time and energy savings from XML-to-(X)HTML processes. Of course, I can always do the xdoc/maven thing if y'all prefer that instead.
It depends on whether or not you want all of the stuff that Maven site generation gives you free. I like the fact that, with about one line per plugin, I can get unit test reports, Javadocs, Checkstyle, PMD, FindBugs, code coverage, cross-ref, developer and file activity, change logs, and much more. I can also see at a glance where to find the mailing lists, the source code, the issue tracking system, and the project's dependencies. I can enter my FAQs in a simple Q&A format and have Maven generate a TOC with all the right links. And anyone who's ever seen a Maven-generated site before will know exactly where to find all those things. It beats the heck out of trying to put that all together manually. Personally, I wouldn't put a new project in place without a Maven site any more. There's just too much that comes with it that would be a pain to do otherwise. As for styling, CSS works just as well for a Maven-generated site as it does for static HTML or an Anakia-generated site. At the end of the day, they're all HTML. ;-) -- Martin Cooper - James
Garrett Rooney wrote: > Before we check the initial code drop into Subversion, we should > probably talk a little bit about how the repository should be laid > out. > > A few questions come to mind: > > 1) Should the website live with the code, or separate from it? > > 2) Should we just start off with what we have sitting in trunk/ or > should we assume we will have other language implementations > eventually, and start out with java/trunk instead? > > Personally, I'm leaning towards something like this: > > abdera/ > java/ > trunk/ > *current code goes here* > tags/ > branches > site/ > trunk/ > *initial website goes here* > tags/ > branches/ > > This leaves room for other languages later without having to rearrange > things, and makes it easy to make tags/branches of one part of the > tree without having to worry about the rest (say we want to release > the java stuff, but not the fledgling C implementation). > > It does mean that people will need a separate checkout for the > website, but I don't think that's an overly huge problem... > > Comments? > > -garrett >
