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.

Thx
Dan

[1] https://cwiki.apache.org/confluence/display/ISIS/MavenModules
[2] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/pdf/weld-reference.pdf


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: https://cwiki.apache.org/confluence/display/ISIS/MavenModules

Thoughts?
Dan


Reply via email to