Mailing-List: contact isis-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: isis-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dkhaywood@gmail.com
 designates 74.125.82.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:organization:user-agent:mime-version
         :to:subject:content-type;
        b=yIYf3q/yfEYBSzzk5z9ezgReYXB7DGg182JcguCdaHa5BEXov30FiF6vuDp1Qfctyr
         WNWbR3ca98RraFxGPdoy2boBBmzl6NEk0RlQCoEb3Kg/vUYCGg5vjlRnhO3XWvTxoIJ+
         Vp1lfctFnECrFHomTb1ZgnBD6P+JD7MvH9Iqw=
Message-ID: <4CB31A40.1000806@gmail.com>
Date: Mon, 11 Oct 2010 15:08:00 +0100
From: Dan Haywood <dkhaywood@gmail.com>
Reply-To: dan@haywood-associates.co.uk
Organization: Haywood Associates Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: isis-dev@incubator.apache.org
Subject: Need to confirm Isis' groupId and artifactId's
Content-Type: multipart/mixed;
 boundary="------------010200000600040600020306"

--------------010200000600040600020306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  First off, Gav has uploaded the Naked Objects codebase (prepared by 
Rob).  He accidentally put it in the wrong place, so I've moved it into 
its correct location (isis/contrib/initial/nof).  I've also made a few 
minor tweaks there (nothing very substantive).

If you want to peruse it, go to isis/contrib/initial/nof/framework/trunk.

~~~
Next step then is to move those modules that will be in v0.1 into 
isis/trunk.  Rob's already done a lot of work in changing class names, 
package names, and has also changed some of the Maven 
groupId/artifactIds.  However, I'm of the view (and I think Rob is too) 
that we need to adjust these groupIds/artifactIds somewhat, to balance 
the requirements that:

1. the directory tree corresponds to the Maven site that we want to generate
   - what that means is breaking up the plugins (now called 
"extensions") into four chunks: viewers, objectstores, security and remoting
2. the directory tree is "obvious" to browse around
   - meaning there's a correlation between groupIds/artifactIds and 
directories
3. we make all child modules (aggregated using <modules>) define their 
parent (defined by <parent>) to be their aggregating parent
   - ie so that inheritance = aggregation as far as we're concerned
   - doing this means that we won't require any special configuration in 
the maven-release-plugin and maven-site-plugin

I've captured the proposed modules on our wiki, at: 
https://cwiki.apache.org/confluence/display/ISIS/MavenModules

Thoughts?
Dan


--------------010200000600040600020306--