Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 74421 invoked from network); 27 Feb 2005 16:34:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 27 Feb 2005 16:34:22 -0000 Received: (qmail 73461 invoked by uid 500); 27 Feb 2005 16:34:21 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Delivered-To: moderator for jdo-dev@db.apache.org Received: (qmail 9900 invoked by uid 99); 27 Feb 2005 05:23:36 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: error (hermes.apache.org: encountered temporary error during SPF processing of domain of jdo-dev@db.apache.org) From: Apache JDO project To: jdo-dev@db.apache.org Subject: Re: High level structure of Apache JDO project Date: Sun, 27 Feb 2005 13:22:55 +0800 User-Agent: KMail/1.7.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502271322.55201.jdo-dev@db.apache.org> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Sunday 27 February 2005 11:17, Craig Russell wrote: > We aren't quite as complicated as Geronimo, but we do plan to have a > full web site mostly (completely?) built by maven. And several sub > projects. Let's look at other projects and see if we can pick a paragon > to emulate. People tend to organize their respective projects a bit differently. There is a general recommendation of the trunk/ tags/ branches/ but some do that at subproject levels, whereas some do it only at the top-level, yet others doesn't use the ttb structure like that at all. One of the best things about subversion is that it is not expensive to change the directory structure later, as it is in CVS, so I would recommend "Simplicity first" and evolve with the needs as they arise. Maven have the 'single artifact' rule per "Maven project", which often is not identical with the logical projects. I would recommend; * Create a 'trunk' top level directory. * Identify the generated Jar artifacts. * Create one directory for each in the trunk. * Create a trunk-level project.xml, that contains the global info. * Create one project.xml in each Maven project. * Create the src/java (is that still the Maven default) in each project dir. * Create the src/test for the unittest, if any. * Create a site project, with a xdocs/ directory if using Maven for the site generation. If you choose Forrest, it has slightly different layout of stuff I think, but a separate site project is still recommended. Cheers Niclas