incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: Need to confirm Isis' groupId and artifactId's
Date Wed, 13 Oct 2010 14:43:42 GMT
  Rob and I have been reviewing the Maven modules on the wiki page [1], 
and made a number of changes, which we're now happy with.

One of our objectives in this is to try to make the architecture of the 
framework easily understood by developers who are not familiar with it, 
though especially if they DO have a passing familiarity with JSR-299 [2].

So I'm wondering, have we succeeded?  Assuming you understood the 
JSR-299 concepts of defaults and alternatives, do you think you from the 
table on [1] that you could figure out the different ways in which Isis 
could be deployed, and know, for example, what might be needed to 
integrate a different security mechanism?

Your thoughts welcome.



On 11/10/2010 15:08, Dan Haywood wrote:
>  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: 
> Thoughts?
> Dan

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message