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