Hi all,
No-ones come back with any objections on this, so (as you might have
noticed from commit messages) I've started to move things around.
Please be aware of this if you are making any changes to defaults/*,
alternatives/* or core.runtime/*, since all of these will move.
Since we do now have a stable snapshot with archetype up and working on
the snapshot repo, what I'd also like to propose is that we bump the
version number from 0.1.0-incubating-SNAPSHOT through to
0.1.1-incubating-SNAPSHOT. Obviously, we will at some point need to
push out our 0.1 release, but I only want to do that when we've got our
documentation in a better state. I see the reorg as a prereq to that
because we can then put appropriate effort on documenting the different
modules (ie, I intend to do less work on the 'default' runtime
documentation cos I intend to put my energy into the new CDI/JSR-299
based runtime).
If anyone has an objection to me bumping the version number, let me
know. Otherwise I'll assume lazy consent and action it in the next few
days.
Thanks
Dan
On 27/02/2011 15:58, Dan Haywood wrote:
Hi all,
Over the last month or two I've been working through our various
modules, ostensibly to work on their documentation. As part of this
I've been using Structure 101 [1] to detangle the packages structures
and make it easier for would-be contributors to understand the
codebase. So far I've tidied up core.common, core.metamodel and
core.progmodel. I'm now up to working on the core.runtime module...
and it needs quite a lot of work.
What I'm actively considering is to write a new runtime, so that our
current runtime moves out of core and into (say)
org.apache.isis.runtimes.dflt. This new runtime could be a lot more
lightweight than the current, because we could use other frameworks to
do some of the heavy lifting that our current runtime does.
Specifically:
- context management of scopes (application/session/transaction) - ie
the IsisContext class - could be managed by JSR-299 CDI (this is our
roadmap anyway to implement, [2])
- rather than invent our own ObjectStore API to abstract over
different persistence implementations, we could leverage DataNucleus
(as suggested in ISIS-14, [3])
I think this would be less work overall than tidying up our current
runtime. We could also more thoroughly test-drive the new
implementation.
My thoughts is that the existing object stores would be moved so that
they live "under" the existing runtime. The same is true (I think)
for the bytecode implementations and also the remoting support.
However, the security and progmodel APIs, and also the viewers, live
in the application layer (ie in "front of" the runtime) and so would
be usable by both the existing and the new runtimes. This may require
a little refactoring to remove dependencies on IsisContext; but I
think refactoring these classes would be relatively straightforward.
~~~
I have, therefore, added a page to our wiki [4] suggesting a new
directory structure and groupId/artifactId. I'm happy (as usual) to
make these changes; but I don't want to charge in there without some
discussion.
If we do this work, what I'll do is to fully document core, and but
only lightly document the existing runtime, on the basis that there'll
be a new runtime to follow.
Thoughts?
Cheers
Dan
[1] http://www.headwaysoftware.com/products/structure101/index.php
[2] http://wiki.apache.org/incubator/IsisProposal
[3] https://issues.apache.org/jira/browse/ISIS-14
[4]
https://cwiki.apache.org/confluence/display/ISIS/MavenModulesMultipleRuntimesProposal
