[PROPOSAL] Apache Isis

[Dan Haywood <dk...@gmail.com>]

  I'd like to formally propose a new project for the incubator, Apache 
Isis. If accepted, Isis will combine the existing open source Naked 
Objects framework with a collection of sister projects, providing an 
extensible Java-based framework for rapidly developing domain-driven 
applications.

I floated the idea of Isis on this mailing list about a month or so ago, 
and we got some positive feedback and a couple of expressions of 
interest in contributing. Since then, we've put together a proposal 
(also copied in below) onto the incubator wiki.

The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
The current codebase is at: http://nakedobjects.org, with sister 
projects hosted at: http://starobjects.org

We currently have two mentors, but require more, and we still need a 
champion. I'm hoping that this post will generate some further interest 
to develop the proposal further. All being well we hope to put this 
proposal to a vote in a week or two's time.

Thanks for reading, looking forward to your feedback.
Dan Haywood

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

= Isis Proposal =
The following presents the proposal for creating a new project within 
the Apache Software Foundation called Isis.

== Abstract ==
Isis will be an extensible standards-based framework to rapidly develop 
and enterprise level deploy domain-driven (DDD) applications.

== Proposal ==
The Isis project will bring together a collection of open source 
projects that collectively support the rapid development of 
domain-driven applications. The heart of Isis is the Naked Objects 
Framework, an established open source project that has been around since 
2002. In addition, it will incorporate a number of sister projects that 
build on Naked Objects' pluggable architecture and which extend the 
reach of Naked Objects in several key areas.

In addition, the project will be reorganising the existing projects to 
logically separate out the components into 
[[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]] 
beans. We believe that the JSR-299 programming model is likely to become 
widely used for enterprise Java applications; adopting it should make it 
easier for new contributors to understand how the framework fits 
together and therefore to develop their own extensions. In turn, we hope 
this will further extend the reach of the framework to other 
complementary open source frameworks (either within Apache or outside of 
it).

== Background ==
Naked Objects is an open source Java framework that was originally 
developed to explore the idea of enterprise systems that treat the user 
as a "problem solver, not a process follower". Conceived by Richard 
Pawson, the first version of the framework was written by Robert 
Matthews (2002). Richard and Rob also wrote a book, Naked Objects 
(Wiley, 2002), to explain the idea.

More generally, Naked Objects is an implementation of the naked objects 
architectural pattern. In its purest form, "all" the developer has to do 
is develop their domain model as pojos; Naked Objects then provides: a 
object-oriented user interface by rendering those pojos; persistence by 
extracting the content of the pojos; security by wrapping access to the 
pojos; remoting by turning local calls into remote ones; and 
localisation by adapting all the names used in the metamodel. All of 
this is done reflectively at runtime so that the developer can 
concentrate on the most important aspect - the application itself. You 
can think of Naked Objects' OOUI generation as analogous to Hibernate 
and other ORMs, but rather than reflecting the pojo into the persistence 
layer, they are reflected into the presentation layer. A number of other 
open source frameworks cite it as their inspiration, including 
[[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and 
[[http://www.trailsframework.org|Trails]].

Over this time Naked Objects has attracted a fair degree of attention 
among the early adopter crowd, generally splitting opinion as either a 
very good idea or a very bad one. A common misconception is that naked 
objects is only appropriate for simple CRUD based applications. While 
developing CRUD applications is indeed trivial, an important innovation 
is that the UI generated by NO also renders the pojo's 
commands/behaviors (we call them actions). Simply stated: any public 
method that does not represent a property or collection is rendered so 
it can be invoked, eg with a button, a menu item or a hyperlink. We 
characterize entities with such behaviors as "behaviorally complete". 
It's OO as your mother taught it to you.

At the same time that we have been developing our ideas on the naked 
objects, there has been a resurgent interest in object modelling at the 
enterprise level, specifically as described by Eric Evans' book, 
[[http://domaindrivendesign.org/books|Domain Driven Design]]. 
Recognizing that there's a lot of synergy between the two ideas, the NO 
framework now uses DDD terminology, such as repository, domain service 
and value.

As mentioned in the proposal section, Isis will consist of both the 
original NO framework, along with a number of sister projects. These 
sister projects were written by Dan Haywood to support a book he wrote 
about the framework, [[http://pragprog.com/titles/dhnako|Domain Driven 
Design using Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of 
these projects was to demonstrate the pluggable nature of the framework.

Both Naked Objects and its sister projects are under the ASL v2 license.

Not directly related to this proposal but worth mentioning: Naked 
Objects has also been ported to the .NET platform, as a commercial 
product. Richard Pawson, the originator of the naked objects pattern, 
now devotes his energies to the [[http://nakedobjects.net|.NET version]] 
and is no longer involved in the open source Java version. Conversely, 
Rob Matthews, the originator of the framework and a co-author of this 
proposal, now devotes his energies to the Java version, not the .NET one.

== Rationale ==
We recognize that the key to open source projects long-term success is a 
large user base, along with a goodly number of diverse active and 
enthusiastic committers. Being brutally honest, we cannot claim to have 
either. That said, we are not naive enough to think that entrance into 
the Apache incubator will automatically bring us these things. Rather, 
we believe it will give us a platform to more effectively publicize the 
project so that it can succeed. It will also allow us to take advantage 
of the collaborative environment that the Apache Software Foundation 
provides. Attracting a diverse group of developers will also provide the 
opportunity for significant advancements and improvements to the Isis 
framework, making it more useful for more people.

There are, then, several reasons for us wanting to contribute the 
framework to Apache.

First, it helps us legitimize the "naked objects" concept. 
Notwithstanding the fact that the project has attracted its fair share 
of nay-sayers, as its developers we remain convinced of its usefulness 
and contribution to enterprise development in general. Most 
significantly, (v2.0 of) Naked Objects was used to develop the online 
application for benefits administration of pensions and other state 
benefits for the Irish Government. This project went live in 2006, is 
used by 1500+ users on a day-by-day basis, consists of an enterprise 
domain model of approximately 500 entities, and pushes out a new release 
each month. Richard and Dan remain consultants to this project; we would 
dearly like others to reap the benefit of building enterprise 
applications in this way.

Second, and as already mentioned, it gives us a platform on which to 
publicize. The Naked Objects framework did have its moment in the sun 
about 5~6 years back, but, at that time, it was under a GPL license 
rather than ASL v2. We were also solely focused in developing the 
aforementioned benefits system, rather than building an open source 
community. One could argue that we had an opportunity and we blew it; at 
any rate what we hope is that Apache will give us an opportunity to 
build up a new community. At Devoxx 2009 we ran an informal poll to get 
opinions of Naked Objects, from "best thing since sliced bread", through 
"fundamentally flawed", to "never heard of it". There were 5x as many 
votes in "never heard of it" as there were in all of the other columns. 
That can either be taken as very disappointing, or as an opportunity. We 
prefer the latter interpretation.

Third, by renaming the project to Isis, it gives us a chance to 
reposition the framework. While the "naked objects" pattern is 
important, we also want to emphasize domain-driven design. Alistair 
Cockburn's hexagonal (or "ports and adapters") architecture is another 
influence; the plugins that the NO framework supports (see 
[[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either 
ports/adapters from the presentation layer, or ports/adapters to the 
persistence layer. Furthermore, the newer UI viewers that we have been 
developing allow the UI to be customized in various ways and to various 
extents; so the pojos are not necessarily naked, they are lightly (or 
heavily!) clad. And also, being blunt, that term "naked", while 
attracting the "bleeding edge" guys, tends to be a turn-off for the 
"early majority" who we now want to target.

Fourth, it removes doubt over its direction. Currently the NO framework 
is ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard 
Pawson still the figurehead of the naked objects movement. As already 
mentioned, NOGL's energy is in their commercial .NET product. They are 
happy to donate the relevant rights to this software to Apache because 
they recognise that the framework is already critically dependent upon 
the open source community, so this is the best way to encourage greater 
take up, and ensure its future. Changing the name of the Java version 
also means it removes confusion in the market place as to what Naked 
Objects framework is (ie a .NET product only). Meanwhile the rights to 
the various sister projects that Dan has written would also be donated 
to ASF. Having a single legal entity - ASF - owning rights for all of 
this software would be very desirable; we think it might prompt others 
to explore the framework.

Fifth, the synergies with other Apache projects will help us meet our 
ambition to make the framework easier to extend. There are two principle 
extension points of the framework: viewers, and object stores. While we 
do understand that it isn't a goal of Apache per se to create a 
portfolio of frameworks, we hope that being part of the Apache family 
might encourage members of these other communities to help us develop 
new viewers or object stores. One of the sister projects provides a 
customizable viewer that uses Wicket; since pre-announcing this proposal 
on the incubator mailing list we've had one expression of interest to 
develop a new viewer using Tapestry.

The 'domain services' angle of DDD also means there are opportunities to 
integrate with frameworks that aren't just about presentation or 
persistence; in Dan's book he sketches out an integration with 
[[camel.apache.org|Camel]; there are multiple opportunities here. We 
also hope to tap into expertise to help us refactor the framework 
components into JSR-299 beans. Again, we've had an expression of 
interest from the incubator mailing list along these lines.

Sixth, it isn't finished. As has been pointed out to us, projects whose 
codebases are finished don't make for good project candidates. Isis, 
though, will probably never be truly finished. The hexagonal 
architecture, as we think of it, is about plugging in different 
presentation and persistence layers. We have several viewers that are in 
active development (including the Wicket, and a RESTful-based viewer), 
and object stores too (BerkleyDB, MongoDB, vanilla SQL). But there are 
lots of UI frameworks we haven't even started on, either Apache's own 
(eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, …) 
or external (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX, 
[[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX, 
Silverlight, …). The same is true for persistence technologies, both 
internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]], 
[[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase, 
iBATIS, ...) and external (eg neo4j, db4o, 
[[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3, 
JCloud … ). And… there are also lots of development tools that could be 
built, either IDE integrations, or into build tools such as Maven.

In summary: we hope that incubation will allow us to develop Isis into a 
standards-based framework for building domain-driven apps, appealing 
both to its user community (who just want to use it "out-of-the-box") 
and to its contributor community (who want to quickly understand how it 
works and what is required to extend it).

== Initial Source ==
=== 1. Combine the codebases ===
Both the core Naked Objects framework and the sister projects reside in 
Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:

* nakedobjects.sourceforge.net
* wicketobjects.sourceforge.net
* restfulobjects.sourceforge.net
* jpaobjects.sourceforge.net
* testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]], 
[[http://www.concordion.org/|Concordion]])
* groovyobjects.sourceforge.net

These will need to be moved into a single Subversion tree, hosted on 
Apache infrastructure.

=== 2. Rationalize the builds ===
Both the NO codebase and the sister projects are built using Maven 2. It 
shouldn't be difficult to combine these into a single build.

=== 3. Standardize package names ===
Naked Objects package names are currently:

* org.nakedobjects.applib.* and org.nakedobjects.service.* for the 
applib and domain services
* org.nakedobjects.core.* for the core
* org.nakedobjects.plugins.xxx for each plugin

These should move, respectively, to

* org.apache.isis.application.*
* org.apache.isis.core.* and
* org.apache.isis.alternatives.xxx (we expect that plugins will become 
[[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]] 
under JSR-299).

The sister projects package names are currently:

* org.starobjects.wicket.* (for wicket objects)
* org.starobjects.restful.* (for restful objects)

etc.

Because these are all just plugins/alternatives, they should just move 
to org.apache.isis.alternatives.*.

=== 4. Move the version number down. ===
To emphasize the fact that this is a new project not yet considered 
complete, we will move the number back down to < 1.0, eg v0.1. This will 
allow us to work on a number of releases, hopefully getting to 1.0 as 
and when we graduate from the incubator.

=== 5. Establish continuous integration ===
The Naked Objects framework currently builds on its own Hudson server; 
we would move this over to run on Apache infrastructure.

=== 6. Rationalize documentation ===
The documentation for the sister projects is reasonably up-to-date, but 
the documentation for Naked Objects needs rationalizing, aligning with 
the core component and the various plugins. This will help make the 
framework more digestible to new users/would-be committers; they can 
focus on the core, or a bit of the core (say, the metamodel), or work on 
just one plugin.

=== 7. Rationalize the Maven sites ===
Related to above, we need to "tell the story better" so that would-be 
users can see what benefits using the framework will bring (and, 
conversely, what freedom they give up in adopting a framework).

=== 8. Review/copy over outstanding tickets. ===
There are a number of tickets in the Naked Objects TRAC wiki. These 
should be either moved over, or fixed.

== Initial Goals ==
The following outlines some of the goals we have set ourselves during 
incubation. Of course, these may change as we proceed and learn more.

* Prepare ground by defining the 3 area of Isis: Application; Framework; 
and Plugin.
* Address (either fix or transfer) all tickets from Naked Objects TRAC wiki.
* Ensure existing documentation (of which there is a reasonable amount) 
is correctly related to each project now that the documentation has been 
separated out.
* v 0.1 - source code combination and rationalization (as per above).
* v 0.2 - refactor components to JSR-299, while maintaining backwards 
compatibility for bootstrapping.
* v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
* v 0.4 - integrate with JMX for runtime management; provide profiling 
of client/server and webapps (eg serialization vs domain logic vs domain 
services vs object store timings).
* v 0.5 - write contract tests for all major plugin APIs (object stores, 
authentication, authorization, remoting).

We also have a number of overarching goals:

* steadily improve the code coverage
* clean up the APIs. Some of the code dates back to Java 1.1 (at one 
point in time the code was cross-compiled into J# code); so there is 
opportunity to use more generics and remove use of arrays
* steadily reduce the amount of proprietary code, and the code size in 
general; use newer libraries such as google-collections more extensively.

As well as the work going on to create the Isis project there are a 
number of components that are in the works, and that will be released as 
they are ready:

* Scimpi web application release.
* Introduce dynamic view design into the DnD viewer.
* [[http://wicket.apache.org|Wicket]] viewer release.
* NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]], 
[[http://www.mongodb.org/|MongoDB]] and 
[[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
* SQL persistor release.
* CLI viewer release.
* Portal integration: Examine and implement support for compatible 
portals. Under consideration: 
[[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal 
Server]].

Whether these are part of incubation or not will depend on whether we 
feel we have reached a self-sustaining community (but it's more likely 
than not that they will be released during incubation). Equally, there 
may be other viewers/persistors using other technologies that might be 
implemented during incubation.

== Current Status ==
Naked Objects 4.0.0 was released at the end of 2009, broadly 
corresponding to the release of Dan's book.This is released into the 
Maven central repo, along with an application archetype for quick-start. 
The three sister projects mentioned in Dan's book (restful, tested, jpa) 
are at 1.0-beta-3, but not formally released into the Maven central 
repo. The remaining sister projects are in alpha status.

The main committers for the codebases to date have been Robert Matthews 
and Dan Haywood. Both Rob and Dan work on the NOF core, and each also 
works independently (reflecting their individual interests) on their 
respective plugins. Much work was done on the core by both Rob and Dan 
leading up to the release of NOF 4.0.0, and we are now reasonably happy 
with it. Much work remains (see above) in the area of 
plugins/alternatives; there is work to complete and improve the existing 
ones and many opportunities to develop new ones.

We readily support users on the NO forum (on 
[[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]]) 
and also on the forum for Dan's book (on pragprog.com). As a consequence 
of Dan's book, a GWT-based viewer (non open source) has been developed 
separately, and we have provided support for this (and hope it will be 
contributed back to the framework in the future).

Over the years we have received some patches for the framework, which we 
have incorporated, but not many. Part of the reason for this, we 
believe, is that until NOF 4.0.0 it had a monolithic architecture, 
making it difficult for would-be contributors to provide small patches. 
We think that NOF 4.0.0 improves in this area, but a move to JSR-299 
would be a major step forward to help bring up participation.

== Community ==
We recognize that the lack of a large (or at least, vocal) user 
community is the weakest part of our proposal. That said, we do have a 
steady trickle of queries on both the Naked Objects forum, and on the 
forum for Dan's book. Getting NOF 4.0.0 released has rekindled interest 
in at least one long-time user who is helping Rob to test one of the 
object store plugins, while we've also picked up commitment to help with 
this Apache proposal from a couple of people via the book forum.

To help build up our community we intend to:

* ensure that the website and documentation is first-rate (see initial 
goals, above)
* make sure that the Isis code can be easily used and understood
* court other open source projects with compatible technologies to work 
on integrations with Isis
* write a series of articles for leading web journals, eg 
theserverside.com, javaworld.com, artima.com. We would want to point out 
that we were in the Apache Incubator, and actively looking for help
* submit sessions to Devoxx and similar, Java-focused, conferences; 
again we'd trade on the Apache Incubator status.

We also hope that some of the newer members of our community will help 
us identify what the roadblocks are to adoption, so that we can address 
them.

== Core Developers ==
The core developers are:

* Robert Matthews, UK-based independent consultant. Original author of 
the Naked Objects framework, committer to the NOF core and primary 
developer of the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer, 
in-memory !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL 
!ObjectStore, !MongoDB ObjectStore). Until recently, worked for Naked 
Objects Group Ltd on the commercial .NET version. Is now independent and 
working on apps built using the open source Java version.

* Dan Haywood, UK-based independent consultant. Contributor to the Naked 
Objects framework since 2005; took lead in much of the restructuring of 
the NO architecture for NOF 4.0.0. Also primary developer for sister 
projects plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA 
!ObjectStore, !TestedObjects "viewer", Groovy support). Part-time 
consultant/advisor to the Irish Government project (since 2004); also a 
trainer/consultant in agile, Java, TDD etc.

Additional committers are:

* Kevin Meyer, South Africa-based freelance developer and business 
analyst. Kevin has been working primarily in a testing role, both on the 
SQL Object Store with Rob and on the Wicket viewer with Dan. Kevin has 
recently started contributing fixes to both.

* Dave Slaughter, US-based developer/consultant who is the Lead of the 
Software and Specialty Engineering group at SM&A. Dave has spent his 
career in the development of enterprise applications for companies such 
as Siemens, Sprint and Lockheed Martin. He has started a SWT viewer and 
has also started improving code coverage of the XML !ObjectStore.

* Alexander Krasnukhin, a Swedish-based developer who has spent more 
than a year developing different applications on Naked Objects v3 and 
spent six months developing a closed-source GWT viewer for Naked Objects 
v4.0 for his former employer in Russia. Alexander is interested in 
developing a new viewer for Android.

As a result of a correspondence on the incubator mailing list, we have 
also had interest from:

* Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour 
has helped us with this proposal relating to JSR-299.

* Ulrich Stark, committer to Apache Tapestry. Uli has expressed an 
interest in developing a Tapstry-based viewer.

We also have had interest (off list) in developing a Vaadin viewer, and 
we know of a student masters project that has developed a (different) 
Android viewer for Naked Objects 4.0, which we're keen to incorporate if 
we can. We are also hoping that we might persuade Alexander's previous 
employer to donate their GWT viewer.

== Alignment ==
The current codebase makes heavy use of Apache projects, including: 
Maven, log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and 
Wicket.

There is a particular opportunity to integrate nicely with both Wicket 
and Tapestry. Both Wicket and Tapestry are great way of building web 
UIs, but have little to say about the "back-end". Naked Objects, 
meanwhile, provides a full runtime environment with pluggable 
persistence layers, and exposes a metamodel to allow generic or 
customisable UIs to be built rapidly. The currently in-development 
!WicketObjects viewer brings Wickets and Naked Objects together, and (as 
noted above) there has been interest in writing a Tapestry viewer.

Another ongoing integration project is the ongoing-development of an 
object store using MongoDB; the intent is to make this codebase a good 
basis for other similar object stores, such as Apache CouchDB.

There are no Apache projects that we are aware of that compete with 
Naked Objects. At its heart, NO is (a) a metamodel, and (b) a container 
that acts as an abstraction over a persistence layer, using the identity 
map pattern.

== Known Risks ==
The biggest risk is that we fail to build a diverse community during 
incubation, opening up the possibility that the project could be orphaned.

That said, there is little risk that either Rob or Dan will move onto 
other interests; we are both independent consultants and have the 
resources and inclination to continue working on the codebase. Indeed, 
with Rob now working only on the Java version (and not the .NET one) and 
Dan having finished his book, we have more resources now than at any 
time in the last couple of years.

== Inexperience with Open Source ==
Although Naked Objects is an open source project, the number of 
committers is so small then we cannot claim great experience with open 
source. Neither Rob nor Dan are committers to any other open source 
project, though both have submitted occasional patches to the various 
open source projects that we use.

We are, however, comfortable users of open source projects. We also 
appreciate that there are lots of open source projects out there and 
that most developers will form an impression of a project without 
necessarily ever trying it out. This is one of the reasons why we feel 
we need to bring the two different codebases together, and create a 
standard message about what Apache Isis is about ("rapid development", 
"domain-driven design", "standard, extensible architecture", 
"customizable UIs").

== Homogeneous Developers ==
The two main developers, Rob and Dan, are based in the UK. Although we 
have collaborated on the framework over the years, we do not work for 
the same company and are independent.

The other developers mentioned in this proposal are based in South 
Africa, US, Sweden, Egypt and Germany.

== Reliance on Salaried Developers ==
There are no salaried developers working on the projects. The main 
developers, Dan and Rob, are both independent consultants. We use 
non-billable time to work on the codebase, with the view to developing 
consultancy/services from it.

== Documentation ==
* [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard 
Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
* Books:
* Domain Driven Design using Naked Objects, Dan Haywood
* [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
* Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
* full text available online at 
[[http://nakedobjects.org/book/|nakedobjects.org/book]]
* [[http://nakedobjects.org|nakedobjects.org]] - current website
* [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his 
book
* [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's 
sister projects; references the various SF websites for the sister projects

== Source and IP Submission Plan ==
As mentioned earlier, the NO framework is ASLv2 but copyright belongs to 
Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to 
Apache, while Dan is also happy to donate the various sister projects 
that he has written. Having a single legal entity - ASF - owning the 
relevant rights to all this software would be very desirable.

== External Dependencies ==
Other than the Apache dependencies, all other open source projects used 
all have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg 
Hamcrest, ASM), MPL (eg javassist) or similarly permissive licenses. We 
do also have a soft dependency on an LGPL-licensed library (Hibernate) 
but during migration would look to migrate to the Apache equivalent 
(OpenJPA).

== Required Resources ==
* Subversion
* Jira
* Hudson CI server
* Wiki
* Website space

== Mailing Lists ==
* isis-private
* isis-dev
* isis-commits
* isis-user

== Subversion Repository ==
https://svn.apache.org/repos/asf/incubator/isis

== Issue Tracking ==
Jira; project known as 'isis'

== Initial Committers ==
* Robert Matthews
* Dan Haywood
* Kevin Meyer
* Dave Slaughter
* Alexander Krasnukhin

== Affiliations ==
Alexander is employed as a software developer by Zenterio AB. The other 
committers are independent consultants.

== Champion ==
[none yet]

== Sponsors: Nominated Mentors ==
* Vincent Massol
* James Carman
* [more required]

== Sponsor ==
Apache Incubator

Re: [PROPOSAL] Apache Isis

[Mohammad Nour El-Din <no...@gmail.com>]

+1 (Not binding)

On Tue, Aug 24, 2010 at 5:12 PM, Dan Haywood <dk...@gmail.com> wrote:
>  I'd like to formally propose a new project for the incubator, Apache Isis.
> If accepted, Isis will combine the existing open source Naked Objects
> framework with a collection of sister projects, providing an extensible
> Java-based framework for rapidly developing domain-driven applications.
>
> I floated the idea of Isis on this mailing list about a month or so ago, and
> we got some positive feedback and a couple of expressions of interest in
> contributing. Since then, we've put together a proposal (also copied in
> below) onto the incubator wiki.
>
> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
> The current codebase is at: http://nakedobjects.org, with sister projects
> hosted at: http://starobjects.org
>
> We currently have two mentors, but require more, and we still need a
> champion. I'm hoping that this post will generate some further interest to
> develop the proposal further. All being well we hope to put this proposal to
> a vote in a week or two's time.
>
> Thanks for reading, looking forward to your feedback.
> Dan Haywood
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> = Isis Proposal =
> The following presents the proposal for creating a new project within the
> Apache Software Foundation called Isis.
>
> == Abstract ==
> Isis will be an extensible standards-based framework to rapidly develop and
> enterprise level deploy domain-driven (DDD) applications.
>
> == Proposal ==
> The Isis project will bring together a collection of open source projects
> that collectively support the rapid development of domain-driven
> applications. The heart of Isis is the Naked Objects Framework, an
> established open source project that has been around since 2002. In
> addition, it will incorporate a number of sister projects that build on
> Naked Objects' pluggable architecture and which extend the reach of Naked
> Objects in several key areas.
>
> In addition, the project will be reorganising the existing projects to
> logically separate out the components into
> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]
> beans. We believe that the JSR-299 programming model is likely to become
> widely used for enterprise Java applications; adopting it should make it
> easier for new contributors to understand how the framework fits together
> and therefore to develop their own extensions. In turn, we hope this will
> further extend the reach of the framework to other complementary open source
> frameworks (either within Apache or outside of it).
>
> == Background ==
> Naked Objects is an open source Java framework that was originally developed
> to explore the idea of enterprise systems that treat the user as a "problem
> solver, not a process follower". Conceived by Richard Pawson, the first
> version of the framework was written by Robert Matthews (2002). Richard and
> Rob also wrote a book, Naked Objects (Wiley, 2002), to explain the idea.
>
> More generally, Naked Objects is an implementation of the naked objects
> architectural pattern. In its purest form, "all" the developer has to do is
> develop their domain model as pojos; Naked Objects then provides: a
> object-oriented user interface by rendering those pojos; persistence by
> extracting the content of the pojos; security by wrapping access to the
> pojos; remoting by turning local calls into remote ones; and localisation by
> adapting all the names used in the metamodel. All of this is done
> reflectively at runtime so that the developer can concentrate on the most
> important aspect - the application itself. You can think of Naked Objects'
> OOUI generation as analogous to Hibernate and other ORMs, but rather than
> reflecting the pojo into the persistence layer, they are reflected into the
> presentation layer. A number of other open source frameworks cite it as
> their inspiration, including [[http://jmatter.org|JMatter]],
> [[http://openxava.org|OpenXava]], and
> [[http://www.trailsframework.org|Trails]].
>
> Over this time Naked Objects has attracted a fair degree of attention among
> the early adopter crowd, generally splitting opinion as either a very good
> idea or a very bad one. A common misconception is that naked objects is only
> appropriate for simple CRUD based applications. While developing CRUD
> applications is indeed trivial, an important innovation is that the UI
> generated by NO also renders the pojo's commands/behaviors (we call them
> actions). Simply stated: any public method that does not represent a
> property or collection is rendered so it can be invoked, eg with a button, a
> menu item or a hyperlink. We characterize entities with such behaviors as
> "behaviorally complete". It's OO as your mother taught it to you.
>
> At the same time that we have been developing our ideas on the naked
> objects, there has been a resurgent interest in object modelling at the
> enterprise level, specifically as described by Eric Evans' book,
> [[http://domaindrivendesign.org/books|Domain Driven Design]]. Recognizing
> that there's a lot of synergy between the two ideas, the NO framework now
> uses DDD terminology, such as repository, domain service and value.
>
> As mentioned in the proposal section, Isis will consist of both the original
> NO framework, along with a number of sister projects. These sister projects
> were written by Dan Haywood to support a book he wrote about the framework,
> [[http://pragprog.com/titles/dhnako|Domain Driven Design using Naked
> Objects]] (Pragmatic Bookshelf, 2009). The intent of these projects was to
> demonstrate the pluggable nature of the framework.
>
> Both Naked Objects and its sister projects are under the ASL v2 license.
>
> Not directly related to this proposal but worth mentioning: Naked Objects
> has also been ported to the .NET platform, as a commercial product. Richard
> Pawson, the originator of the naked objects pattern, now devotes his
> energies to the [[http://nakedobjects.net|.NET version]] and is no longer
> involved in the open source Java version. Conversely, Rob Matthews, the
> originator of the framework and a co-author of this proposal, now devotes
> his energies to the Java version, not the .NET one.
>
> == Rationale ==
> We recognize that the key to open source projects long-term success is a
> large user base, along with a goodly number of diverse active and
> enthusiastic committers. Being brutally honest, we cannot claim to have
> either. That said, we are not naive enough to think that entrance into the
> Apache incubator will automatically bring us these things. Rather, we
> believe it will give us a platform to more effectively publicize the project
> so that it can succeed. It will also allow us to take advantage of the
> collaborative environment that the Apache Software Foundation provides.
> Attracting a diverse group of developers will also provide the opportunity
> for significant advancements and improvements to the Isis framework, making
> it more useful for more people.
>
> There are, then, several reasons for us wanting to contribute the framework
> to Apache.
>
> First, it helps us legitimize the "naked objects" concept. Notwithstanding
> the fact that the project has attracted its fair share of nay-sayers, as its
> developers we remain convinced of its usefulness and contribution to
> enterprise development in general. Most significantly, (v2.0 of) Naked
> Objects was used to develop the online application for benefits
> administration of pensions and other state benefits for the Irish
> Government. This project went live in 2006, is used by 1500+ users on a
> day-by-day basis, consists of an enterprise domain model of approximately
> 500 entities, and pushes out a new release each month. Richard and Dan
> remain consultants to this project; we would dearly like others to reap the
> benefit of building enterprise applications in this way.
>
> Second, and as already mentioned, it gives us a platform on which to
> publicize. The Naked Objects framework did have its moment in the sun about
> 5~6 years back, but, at that time, it was under a GPL license rather than
> ASL v2. We were also solely focused in developing the aforementioned
> benefits system, rather than building an open source community. One could
> argue that we had an opportunity and we blew it; at any rate what we hope is
> that Apache will give us an opportunity to build up a new community. At
> Devoxx 2009 we ran an informal poll to get opinions of Naked Objects, from
> "best thing since sliced bread", through "fundamentally flawed", to "never
> heard of it". There were 5x as many votes in "never heard of it" as there
> were in all of the other columns. That can either be taken as very
> disappointing, or as an opportunity. We prefer the latter interpretation.
>
> Third, by renaming the project to Isis, it gives us a chance to reposition
> the framework. While the "naked objects" pattern is important, we also want
> to emphasize domain-driven design. Alistair Cockburn's hexagonal (or "ports
> and adapters") architecture is another influence; the plugins that the NO
> framework supports (see
> [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either
> ports/adapters from the presentation layer, or ports/adapters to the
> persistence layer. Furthermore, the newer UI viewers that we have been
> developing allow the UI to be customized in various ways and to various
> extents; so the pojos are not necessarily naked, they are lightly (or
> heavily!) clad. And also, being blunt, that term "naked", while attracting
> the "bleeding edge" guys, tends to be a turn-off for the "early majority"
> who we now want to target.
>
> Fourth, it removes doubt over its direction. Currently the NO framework is
> ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard Pawson
> still the figurehead of the naked objects movement. As already mentioned,
> NOGL's energy is in their commercial .NET product. They are happy to donate
> the relevant rights to this software to Apache because they recognise that
> the framework is already critically dependent upon the open source
> community, so this is the best way to encourage greater take up, and ensure
> its future. Changing the name of the Java version also means it removes
> confusion in the market place as to what Naked Objects framework is (ie a
> .NET product only). Meanwhile the rights to the various sister projects that
> Dan has written would also be donated to ASF. Having a single legal entity -
> ASF - owning rights for all of this software would be very desirable; we
> think it might prompt others to explore the framework.
>
> Fifth, the synergies with other Apache projects will help us meet our
> ambition to make the framework easier to extend. There are two principle
> extension points of the framework: viewers, and object stores. While we do
> understand that it isn't a goal of Apache per se to create a portfolio of
> frameworks, we hope that being part of the Apache family might encourage
> members of these other communities to help us develop new viewers or object
> stores. One of the sister projects provides a customizable viewer that uses
> Wicket; since pre-announcing this proposal on the incubator mailing list
> we've had one expression of interest to develop a new viewer using Tapestry.
>
> The 'domain services' angle of DDD also means there are opportunities to
> integrate with frameworks that aren't just about presentation or
> persistence; in Dan's book he sketches out an integration with
> [[camel.apache.org|Camel]; there are multiple opportunities here. We also
> hope to tap into expertise to help us refactor the framework components into
> JSR-299 beans. Again, we've had an expression of interest from the incubator
> mailing list along these lines.
>
> Sixth, it isn't finished. As has been pointed out to us, projects whose
> codebases are finished don't make for good project candidates. Isis, though,
> will probably never be truly finished. The hexagonal architecture, as we
> think of it, is about plugging in different presentation and persistence
> layers. We have several viewers that are in active development (including
> the Wicket, and a RESTful-based viewer), and object stores too (BerkleyDB,
> MongoDB, vanilla SQL). But there are lots of UI frameworks we haven't even
> started on, either Apache's own (eg Click, Tapestry,
> [[http://myfaces.apache.org/|MyFaces]], Pivot, …) or external (eg
> [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
> Silverlight, …). The same is true for persistence technologies, both
> internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]],
> [[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase, iBATIS,
> ...) and external (eg neo4j, db4o,
> [[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3, JCloud
> … ). And… there are also lots of development tools that could be built,
> either IDE integrations, or into build tools such as Maven.
>
> In summary: we hope that incubation will allow us to develop Isis into a
> standards-based framework for building domain-driven apps, appealing both to
> its user community (who just want to use it "out-of-the-box") and to its
> contributor community (who want to quickly understand how it works and what
> is required to extend it).
>
> == Initial Source ==
> === 1. Combine the codebases ===
> Both the core Naked Objects framework and the sister projects reside in
> Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:
>
> * nakedobjects.sourceforge.net
> * wicketobjects.sourceforge.net
> * restfulobjects.sourceforge.net
> * jpaobjects.sourceforge.net
> * testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]],
> [[http://www.concordion.org/|Concordion]])
> * groovyobjects.sourceforge.net
>
> These will need to be moved into a single Subversion tree, hosted on Apache
> infrastructure.
>
> === 2. Rationalize the builds ===
> Both the NO codebase and the sister projects are built using Maven 2. It
> shouldn't be difficult to combine these into a single build.
>
> === 3. Standardize package names ===
> Naked Objects package names are currently:
>
> * org.nakedobjects.applib.* and org.nakedobjects.service.* for the applib
> and domain services
> * org.nakedobjects.core.* for the core
> * org.nakedobjects.plugins.xxx for each plugin
>
> These should move, respectively, to
>
> * org.apache.isis.application.*
> * org.apache.isis.core.* and
> * org.apache.isis.alternatives.xxx (we expect that plugins will become
> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]]
> under JSR-299).
>
> The sister projects package names are currently:
>
> * org.starobjects.wicket.* (for wicket objects)
> * org.starobjects.restful.* (for restful objects)
>
> etc.
>
> Because these are all just plugins/alternatives, they should just move to
> org.apache.isis.alternatives.*.
>
> === 4. Move the version number down. ===
> To emphasize the fact that this is a new project not yet considered
> complete, we will move the number back down to < 1.0, eg v0.1. This will
> allow us to work on a number of releases, hopefully getting to 1.0 as and
> when we graduate from the incubator.
>
> === 5. Establish continuous integration ===
> The Naked Objects framework currently builds on its own Hudson server; we
> would move this over to run on Apache infrastructure.
>
> === 6. Rationalize documentation ===
> The documentation for the sister projects is reasonably up-to-date, but the
> documentation for Naked Objects needs rationalizing, aligning with the core
> component and the various plugins. This will help make the framework more
> digestible to new users/would-be committers; they can focus on the core, or
> a bit of the core (say, the metamodel), or work on just one plugin.
>
> === 7. Rationalize the Maven sites ===
> Related to above, we need to "tell the story better" so that would-be users
> can see what benefits using the framework will bring (and, conversely, what
> freedom they give up in adopting a framework).
>
> === 8. Review/copy over outstanding tickets. ===
> There are a number of tickets in the Naked Objects TRAC wiki. These should
> be either moved over, or fixed.
>
> == Initial Goals ==
> The following outlines some of the goals we have set ourselves during
> incubation. Of course, these may change as we proceed and learn more.
>
> * Prepare ground by defining the 3 area of Isis: Application; Framework; and
> Plugin.
> * Address (either fix or transfer) all tickets from Naked Objects TRAC wiki.
> * Ensure existing documentation (of which there is a reasonable amount) is
> correctly related to each project now that the documentation has been
> separated out.
> * v 0.1 - source code combination and rationalization (as per above).
> * v 0.2 - refactor components to JSR-299, while maintaining backwards
> compatibility for bootstrapping.
> * v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
> * v 0.4 - integrate with JMX for runtime management; provide profiling of
> client/server and webapps (eg serialization vs domain logic vs domain
> services vs object store timings).
> * v 0.5 - write contract tests for all major plugin APIs (object stores,
> authentication, authorization, remoting).
>
> We also have a number of overarching goals:
>
> * steadily improve the code coverage
> * clean up the APIs. Some of the code dates back to Java 1.1 (at one point
> in time the code was cross-compiled into J# code); so there is opportunity
> to use more generics and remove use of arrays
> * steadily reduce the amount of proprietary code, and the code size in
> general; use newer libraries such as google-collections more extensively.
>
> As well as the work going on to create the Isis project there are a number
> of components that are in the works, and that will be released as they are
> ready:
>
> * Scimpi web application release.
> * Introduce dynamic view design into the DnD viewer.
> * [[http://wicket.apache.org|Wicket]] viewer release.
> * NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]],
> [[http://www.mongodb.org/|MongoDB]] and
> [[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
> * SQL persistor release.
> * CLI viewer release.
> * Portal integration: Examine and implement support for compatible portals.
> Under consideration:
> [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal
> Server]].
>
> Whether these are part of incubation or not will depend on whether we feel
> we have reached a self-sustaining community (but it's more likely than not
> that they will be released during incubation). Equally, there may be other
> viewers/persistors using other technologies that might be implemented during
> incubation.
>
> == Current Status ==
> Naked Objects 4.0.0 was released at the end of 2009, broadly corresponding
> to the release of Dan's book.This is released into the Maven central repo,
> along with an application archetype for quick-start. The three sister
> projects mentioned in Dan's book (restful, tested, jpa) are at 1.0-beta-3,
> but not formally released into the Maven central repo. The remaining sister
> projects are in alpha status.
>
> The main committers for the codebases to date have been Robert Matthews and
> Dan Haywood. Both Rob and Dan work on the NOF core, and each also works
> independently (reflecting their individual interests) on their respective
> plugins. Much work was done on the core by both Rob and Dan leading up to
> the release of NOF 4.0.0, and we are now reasonably happy with it. Much work
> remains (see above) in the area of plugins/alternatives; there is work to
> complete and improve the existing ones and many opportunities to develop new
> ones.
>
> We readily support users on the NO forum (on
> [[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]]) and
> also on the forum for Dan's book (on pragprog.com). As a consequence of
> Dan's book, a GWT-based viewer (non open source) has been developed
> separately, and we have provided support for this (and hope it will be
> contributed back to the framework in the future).
>
> Over the years we have received some patches for the framework, which we
> have incorporated, but not many. Part of the reason for this, we believe, is
> that until NOF 4.0.0 it had a monolithic architecture, making it difficult
> for would-be contributors to provide small patches. We think that NOF 4.0.0
> improves in this area, but a move to JSR-299 would be a major step forward
> to help bring up participation.
>
> == Community ==
> We recognize that the lack of a large (or at least, vocal) user community is
> the weakest part of our proposal. That said, we do have a steady trickle of
> queries on both the Naked Objects forum, and on the forum for Dan's book.
> Getting NOF 4.0.0 released has rekindled interest in at least one long-time
> user who is helping Rob to test one of the object store plugins, while we've
> also picked up commitment to help with this Apache proposal from a couple of
> people via the book forum.
>
> To help build up our community we intend to:
>
> * ensure that the website and documentation is first-rate (see initial
> goals, above)
> * make sure that the Isis code can be easily used and understood
> * court other open source projects with compatible technologies to work on
> integrations with Isis
> * write a series of articles for leading web journals, eg theserverside.com,
> javaworld.com, artima.com. We would want to point out that we were in the
> Apache Incubator, and actively looking for help
> * submit sessions to Devoxx and similar, Java-focused, conferences; again
> we'd trade on the Apache Incubator status.
>
> We also hope that some of the newer members of our community will help us
> identify what the roadblocks are to adoption, so that we can address them.
>
> == Core Developers ==
> The core developers are:
>
> * Robert Matthews, UK-based independent consultant. Original author of the
> Naked Objects framework, committer to the NOF core and primary developer of
> the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer, in-memory
> !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL !ObjectStore,
> !MongoDB ObjectStore). Until recently, worked for Naked Objects Group Ltd on
> the commercial .NET version. Is now independent and working on apps built
> using the open source Java version.
>
> * Dan Haywood, UK-based independent consultant. Contributor to the Naked
> Objects framework since 2005; took lead in much of the restructuring of the
> NO architecture for NOF 4.0.0. Also primary developer for sister projects
> plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA !ObjectStore,
> !TestedObjects "viewer", Groovy support). Part-time consultant/advisor to
> the Irish Government project (since 2004); also a trainer/consultant in
> agile, Java, TDD etc.
>
> Additional committers are:
>
> * Kevin Meyer, South Africa-based freelance developer and business analyst.
> Kevin has been working primarily in a testing role, both on the SQL Object
> Store with Rob and on the Wicket viewer with Dan. Kevin has recently started
> contributing fixes to both.
>
> * Dave Slaughter, US-based developer/consultant who is the Lead of the
> Software and Specialty Engineering group at SM&A. Dave has spent his career
> in the development of enterprise applications for companies such as Siemens,
> Sprint and Lockheed Martin. He has started a SWT viewer and has also started
> improving code coverage of the XML !ObjectStore.
>
> * Alexander Krasnukhin, a Swedish-based developer who has spent more than a
> year developing different applications on Naked Objects v3 and spent six
> months developing a closed-source GWT viewer for Naked Objects v4.0 for his
> former employer in Russia. Alexander is interested in developing a new
> viewer for Android.
>
> As a result of a correspondence on the incubator mailing list, we have also
> had interest from:
>
> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour has
> helped us with this proposal relating to JSR-299.
>
> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an interest
> in developing a Tapstry-based viewer.
>
> We also have had interest (off list) in developing a Vaadin viewer, and we
> know of a student masters project that has developed a (different) Android
> viewer for Naked Objects 4.0, which we're keen to incorporate if we can. We
> are also hoping that we might persuade Alexander's previous employer to
> donate their GWT viewer.
>
> == Alignment ==
> The current codebase makes heavy use of Apache projects, including: Maven,
> log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and Wicket.
>
> There is a particular opportunity to integrate nicely with both Wicket and
> Tapestry. Both Wicket and Tapestry are great way of building web UIs, but
> have little to say about the "back-end". Naked Objects, meanwhile, provides
> a full runtime environment with pluggable persistence layers, and exposes a
> metamodel to allow generic or customisable UIs to be built rapidly. The
> currently in-development !WicketObjects viewer brings Wickets and Naked
> Objects together, and (as noted above) there has been interest in writing a
> Tapestry viewer.
>
> Another ongoing integration project is the ongoing-development of an object
> store using MongoDB; the intent is to make this codebase a good basis for
> other similar object stores, such as Apache CouchDB.
>
> There are no Apache projects that we are aware of that compete with Naked
> Objects. At its heart, NO is (a) a metamodel, and (b) a container that acts
> as an abstraction over a persistence layer, using the identity map pattern.
>
> == Known Risks ==
> The biggest risk is that we fail to build a diverse community during
> incubation, opening up the possibility that the project could be orphaned.
>
> That said, there is little risk that either Rob or Dan will move onto other
> interests; we are both independent consultants and have the resources and
> inclination to continue working on the codebase. Indeed, with Rob now
> working only on the Java version (and not the .NET one) and Dan having
> finished his book, we have more resources now than at any time in the last
> couple of years.
>
> == Inexperience with Open Source ==
> Although Naked Objects is an open source project, the number of committers
> is so small then we cannot claim great experience with open source. Neither
> Rob nor Dan are committers to any other open source project, though both
> have submitted occasional patches to the various open source projects that
> we use.
>
> We are, however, comfortable users of open source projects. We also
> appreciate that there are lots of open source projects out there and that
> most developers will form an impression of a project without necessarily
> ever trying it out. This is one of the reasons why we feel we need to bring
> the two different codebases together, and create a standard message about
> what Apache Isis is about ("rapid development", "domain-driven design",
> "standard, extensible architecture", "customizable UIs").
>
> == Homogeneous Developers ==
> The two main developers, Rob and Dan, are based in the UK. Although we have
> collaborated on the framework over the years, we do not work for the same
> company and are independent.
>
> The other developers mentioned in this proposal are based in South Africa,
> US, Sweden, Egypt and Germany.
>
> == Reliance on Salaried Developers ==
> There are no salaried developers working on the projects. The main
> developers, Dan and Rob, are both independent consultants. We use
> non-billable time to work on the codebase, with the view to developing
> consultancy/services from it.
>
> == Documentation ==
> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard
> Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
> * Books:
> * Domain Driven Design using Naked Objects, Dan Haywood
> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
> * full text available online at
> [[http://nakedobjects.org/book/|nakedobjects.org/book]]
> * [[http://nakedobjects.org|nakedobjects.org]] - current website
> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his
> book
> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's
> sister projects; references the various SF websites for the sister projects
>
> == Source and IP Submission Plan ==
> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
> Apache, while Dan is also happy to donate the various sister projects that
> he has written. Having a single legal entity - ASF - owning the relevant
> rights to all this software would be very desirable.
>
> == External Dependencies ==
> Other than the Apache dependencies, all other open source projects used all
> have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg Hamcrest,
> ASM), MPL (eg javassist) or similarly permissive licenses. We do also have a
> soft dependency on an LGPL-licensed library (Hibernate) but during migration
> would look to migrate to the Apache equivalent (OpenJPA).
>
> == Required Resources ==
> * Subversion
> * Jira
> * Hudson CI server
> * Wiki
> * Website space
>
> == Mailing Lists ==
> * isis-private
> * isis-dev
> * isis-commits
> * isis-user
>
> == Subversion Repository ==
> https://svn.apache.org/repos/asf/incubator/isis
>
> == Issue Tracking ==
> Jira; project known as 'isis'
>
> == Initial Committers ==
> * Robert Matthews
> * Dan Haywood
> * Kevin Meyer
> * Dave Slaughter
> * Alexander Krasnukhin
>
> == Affiliations ==
> Alexander is employed as a software developer by Zenterio AB. The other
> committers are independent consultants.
>
> == Champion ==
> [none yet]
>
> == Sponsors: Nominated Mentors ==
> * Vincent Massol
> * James Carman
> * [more required]
>
> == Sponsor ==
> Apache Incubator
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>



-- 
Thanks
- Mohammad Nour
  Author of (WebSphere Application Server Community Edition 2.0 User Guide)
  http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

"Stay hungry, stay foolish."
- Steve Jobs

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Mark Struberg <st...@yahoo.de>]

+1 

LieGrue,
strub



----- Original Message ----
> From: Dan Haywood <dk...@gmail.com>
> To: general@incubator.apache.org
> Cc: nakedobjects-contributors@lists.sourceforge.net
> Sent: Tue, August 24, 2010 7:12:10 PM
> Subject: [PROPOSAL] Apache Isis
> 
> I'd like to formally propose a new project for the incubator, Apache Isis. If  
>accepted, Isis will combine the existing open source Naked Objects framework  
>with a collection of sister projects, providing an extensible Java-based  
>framework for rapidly developing domain-driven applications.
> 
> I floated  the idea of Isis on this mailing list about a month or so ago, and 
>we got some  positive feedback and a couple of expressions of interest in 
>contributing. Since  then, we've put together a proposal (also copied in below) 
>onto the incubator  wiki.
> 
> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
> The current codebase is  at: http://nakedobjects.org, with sister projects 
>hosted at: http://starobjects.org
> 
> We currently have two mentors, but require  more, and we still need a champion. 
>I'm hoping that this post will generate some  further interest to develop the 
>proposal further. All being well we hope to put  this proposal to a vote in a 
>week or two's time.
> 
> Thanks for reading,  looking forward to your feedback.
> Dan  Haywood
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> =  Isis Proposal =
> The following presents the proposal for creating a new  project within the 
>Apache Software Foundation called Isis.
> 
> == Abstract  ==
> Isis will be an extensible standards-based framework to rapidly develop  and 
>enterprise level deploy domain-driven (DDD) applications.
> 
> == Proposal  ==
> The Isis project will bring together a collection of open source projects  that 
>collectively support the rapid development of domain-driven applications.  The 
>heart of Isis is the Naked Objects Framework, an established open source  
>project that has been around since 2002. In addition, it will incorporate a  
>number of sister projects that build on Naked Objects' pluggable architecture  
>and which extend the reach of Naked Objects in several key areas.
> 
> In  addition, the project will be reorganising the existing projects to 
>logically  separate out the components into 
>[[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]  beans. 
>We believe that the JSR-299 programming model is likely to become widely  used 
>for enterprise Java applications; adopting it should make it easier for new  
>contributors to understand how the framework fits together and therefore to  
>develop their own extensions. In turn, we hope this will further extend the  
>reach of the framework to other complementary open source frameworks (either  
>within Apache or outside of it).
> 
> == Background ==
> Naked Objects is an  open source Java framework that was originally developed 
>to explore the idea of  enterprise systems that treat the user as a "problem 
>solver, not a process  follower". Conceived by Richard Pawson, the first version 
>of the framework was  written by Robert Matthews (2002). Richard and Rob also 
>wrote a book, Naked  Objects (Wiley, 2002), to explain the idea.
> 
> More generally, Naked Objects  is an implementation of the naked objects 
>architectural pattern. In its purest  form, "all" the developer has to do is 
>develop their domain model as pojos;  Naked Objects then provides: a 
>object-oriented user interface by rendering those  pojos; persistence by 
>extracting the content of the pojos; security by wrapping  access to the pojos; 
>remoting by turning local calls into remote ones; and  localisation by adapting 
>all the names used in the metamodel. All of this is  done reflectively at 
>runtime so that the developer can concentrate on the most  important aspect - 
>the application itself. You can think of Naked Objects' OOUI  generation as 
>analogous to Hibernate and other ORMs, but rather than reflecting  the pojo into 
>the persistence layer, they are reflected into the presentation  layer. A number 
>of other open source frameworks cite it as their inspiration,  including 
>[[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and 
>[[http://www.trailsframework.org|Trails]].
> 
> Over this time Naked  Objects has attracted a fair degree of attention among 
>the early adopter crowd,  generally splitting opinion as either a very good idea 
>or a very bad one. A  common misconception is that naked objects is only 
>appropriate for simple CRUD  based applications. While developing CRUD 
>applications is indeed trivial, an  important innovation is that the UI 
>generated by NO also renders the pojo's  commands/behaviors (we call them 
>actions). Simply stated: any public method that  does not represent a property 
>or collection is rendered so it can be invoked, eg  with a button, a menu item 
>or a hyperlink. We characterize entities with such  behaviors as "behaviorally 
>complete". It's OO as your mother taught it to  you.
> 
> At the same time that we have been developing our ideas on the naked  objects, 
>there has been a resurgent interest in object modelling at the  enterprise 
>level, specifically as described by Eric Evans' book, 
>[[http://domaindrivendesign.org/books|Domain Driven Design]]. Recognizing  that 
>there's a lot of synergy between the two ideas, the NO framework now uses  DDD 
>terminology, such as repository, domain service and value.
> 
> As  mentioned in the proposal section, Isis will consist of both the original 
>NO  framework, along with a number of sister projects. These sister projects 
>were  written by Dan Haywood to support a book he wrote about the framework, 
>[[http://pragprog.com/titles/dhnako|Domain Driven Design using Naked  Objects]] 
>(Pragmatic Bookshelf, 2009). The intent of these projects was to  demonstrate 
>the pluggable nature of the framework.
> 
> Both Naked Objects and  its sister projects are under the ASL v2 license.
> 
> Not directly related to  this proposal but worth mentioning: Naked Objects has 
>also been ported to the  .NET platform, as a commercial product. Richard Pawson, 
>the originator of the  naked objects pattern, now devotes his energies to the 
>[[http://nakedobjects.net|.NET version]] and is no longer involved in the  open 
>source Java version. Conversely, Rob Matthews, the originator of the  framework 
>and a co-author of this proposal, now devotes his energies to the Java  version, 
>not the .NET one.
> 
> == Rationale ==
> We recognize that the key  to open source projects long-term success is a large 
>user base, along with a  goodly number of diverse active and enthusiastic 
>committers. Being brutally  honest, we cannot claim to have either. That said, 
>we are not naive enough to  think that entrance into the Apache incubator will 
>automatically bring us these  things. Rather, we believe it will give us a 
>platform to more effectively  publicize the project so that it can succeed. It 
>will also allow us to take  advantage of the collaborative environment that the 
>Apache Software Foundation  provides. Attracting a diverse group of developers 
>will also provide the  opportunity for significant advancements and improvements 
>to the Isis framework,  making it more useful for more people.
> 
> There are, then, several reasons  for us wanting to contribute the framework to 
>Apache.
> 
> First, it helps us  legitimize the "naked objects" concept. Notwithstanding the 
>fact that the  project has attracted its fair share of nay-sayers, as its 
>developers we remain  convinced of its usefulness and contribution to enterprise 
>development in  general. Most significantly, (v2.0 of) Naked Objects was used to 
>develop the  online application for benefits administration of pensions and 
>other state  benefits for the Irish Government. This project went live in 2006, 
>is used by  1500+ users on a day-by-day basis, consists of an enterprise domain 
>model of  approximately 500 entities, and pushes out a new release each month. 
>Richard and  Dan remain consultants to this project; we would dearly like others 
>to reap the  benefit of building enterprise applications in this way.
> 
> Second, and as  already mentioned, it gives us a platform on which to 
>publicize. The Naked  Objects framework did have its moment in the sun about 5~6 
>years back, but, at  that time, it was under a GPL license rather than ASL v2. 
>We were also solely  focused in developing the aforementioned benefits system, 
>rather than building  an open source community. One could argue that we had an 
>opportunity and we blew  it; at any rate what we hope is that Apache will give 
>us an opportunity to build  up a new community. At Devoxx 2009 we ran an 
>informal poll to get opinions of  Naked Objects, from "best thing since sliced 
>bread", through "fundamentally  flawed", to "never heard of it". There were 5x 
>as many votes in "never heard of  it" as there were in all of the other columns. 
>That can either be taken as very  disappointing, or as an opportunity. We prefer 
>the latter  interpretation.
> 
> Third, by renaming the project to Isis, it gives us a  chance to reposition the 
>framework. While the "naked objects" pattern is  important, we also want to 
>emphasize domain-driven design. Alistair Cockburn's  hexagonal (or "ports and 
>adapters") architecture is another influence; the  plugins that the NO framework 
>supports (see [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are 
>either  ports/adapters from the presentation layer, or ports/adapters to the 
>persistence  layer. Furthermore, the newer UI viewers that we have been 
>developing allow the  UI to be customized in various ways and to various 
>extents; so the pojos are not  necessarily naked, they are lightly (or heavily!) 
>clad. And also, being blunt,  that term "naked", while attracting the "bleeding 
>edge" guys, tends to be a  turn-off for the "early majority" who we now want to 
>target.
> 
> Fourth, it  removes doubt over its direction. Currently the NO framework is 
>ASLv2 but  copyright Naked Objects Group Ltd (NOGL), with Richard Pawson still 
>the  figurehead of the naked objects movement. As already mentioned, NOGL's 
>energy is  in their commercial .NET product. They are happy to donate the 
>relevant rights  to this software to Apache because they recognise that the 
>framework is already  critically dependent upon the open source community, so 
>this is the best way to  encourage greater take up, and ensure its future. 
>Changing the name of the Java  version also means it removes confusion in the 
>market place as to what Naked  Objects framework is (ie a .NET product only). 
>Meanwhile the rights to the  various sister projects that Dan has written would 
>also be donated to ASF.  Having a single legal entity - ASF - owning rights for 
>all of this software  would be very desirable; we think it might prompt others 
>to explore the  framework.
> 
> Fifth, the synergies with other Apache projects will help us  meet our ambition 
>to make the framework easier to extend. There are two  principle extension 
>points of the framework: viewers, and object stores. While  we do understand 
>that it isn't a goal of Apache per se to create a portfolio of  frameworks, we 
>hope that being part of the Apache family might encourage members  of these 
>other communities to help us develop new viewers or object stores. One  of the 
>sister projects provides a customizable viewer that uses Wicket; since  
>pre-announcing this proposal on the incubator mailing list we've had one  
>expression of interest to develop a new viewer using Tapestry.
> 
> The  'domain services' angle of DDD also means there are opportunities to 
>integrate  with frameworks that aren't just about presentation or persistence; 
>in Dan's  book he sketches out an integration with [[camel.apache.org|Camel]; 
>there are  multiple opportunities here. We also hope to tap into expertise to 
>help us  refactor the framework components into JSR-299 beans. Again, we've had 
>an  expression of interest from the incubator mailing list along these  lines.
> 
> Sixth, it isn't finished. As has been pointed out to us, projects  whose 
>codebases are finished don't make for good project candidates. Isis,  though, 
>will probably never be truly finished. The hexagonal architecture, as we  think 
>of it, is about plugging in different presentation and persistence layers.  We 
>have several viewers that are in active development (including the Wicket,  and 
>a RESTful-based viewer), and object stores too (BerkleyDB, MongoDB, vanilla  
>SQL). But there are lots of UI frameworks we haven't even started on, either  
>Apache's own (eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, 
>…) or external  (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX, 
>[[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,  
>Silverlight, …). The same is true for persistence technologies, both internal to  
>Apache (eg [[http://couchdb.apache.org/|CouchDB]], 
>[[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase, iBATIS,  ...) 
>and external (eg neo4j, db4o, 
>[[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3, JCloud …  
>). And… there are also lots of development tools that could be built, either IDE  
>integrations, or into build tools such as Maven.
> 
> In summary: we hope that  incubation will allow us to develop Isis into a 
>standards-based framework for  building domain-driven apps, appealing both to 
>its user community (who just want  to use it "out-of-the-box") and to its 
>contributor community (who want to  quickly understand how it works and what is 
>required to extend it).
> 
> ==  Initial Source ==
> === 1. Combine the codebases ===
> Both the core Naked  Objects framework and the sister projects reside in 
>Subversion trees, hosted on  [[http://sourceforge.net|SourceForge]]:
> 
> *  nakedobjects.sourceforge.net
> * wicketobjects.sourceforge.net
> *  restfulobjects.sourceforge.net
> * jpaobjects.sourceforge.net
> *  testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]], 
>[[http://www.concordion.org/|Concordion]])
> *  groovyobjects.sourceforge.net
> 
> These will need to be moved into a single  Subversion tree, hosted on Apache 
>infrastructure.
> 
> === 2. Rationalize the  builds ===
> Both the NO codebase and the sister projects are built using Maven  2. It 
>shouldn't be difficult to combine these into a single build.
> 
> === 3.  Standardize package names ===
> Naked Objects package names are  currently:
> 
> * org.nakedobjects.applib.* and org.nakedobjects.service.* for  the applib and 
>domain services
> * org.nakedobjects.core.* for the core
> *  org.nakedobjects.plugins.xxx for each plugin
> 
> These should move,  respectively, to
> 
> * org.apache.isis.application.*
> *  org.apache.isis.core.* and
> * org.apache.isis.alternatives.xxx (we expect that  plugins will become 
>[[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]]
>  under JSR-299).
> 
> The sister projects package names are  currently:
> 
> * org.starobjects.wicket.* (for wicket objects)
> *  org.starobjects.restful.* (for restful objects)
> 
> etc.
> 
> Because these  are all just plugins/alternatives, they should just move to  
>org.apache.isis.alternatives.*.
> 
> === 4. Move the version number down.  ===
> To emphasize the fact that this is a new project not yet considered  complete, 
>we will move the number back down to < 1.0, eg v0.1. This will  allow us to work 
>on a number of releases, hopefully getting to 1.0 as and when  we graduate from 
>the incubator.
> 
> === 5. Establish continuous integration  ===
> The Naked Objects framework currently builds on its own Hudson server; we  
>would move this over to run on Apache infrastructure.
> 
> === 6. Rationalize  documentation ===
> The documentation for the sister projects is reasonably  up-to-date, but the 
>documentation for Naked Objects needs rationalizing,  aligning with the core 
>component and the various plugins. This will help make  the framework more 
>digestible to new users/would-be committers; they can focus  on the core, or a 
>bit of the core (say, the metamodel), or work on just one  plugin.
> 
> === 7. Rationalize the Maven sites ===
> Related to above, we  need to "tell the story better" so that would-be users 
>can see what benefits  using the framework will bring (and, conversely, what 
>freedom they give up in  adopting a framework).
> 
> === 8. Review/copy over outstanding tickets.  ===
> There are a number of tickets in the Naked Objects TRAC wiki. These  should be 
>either moved over, or fixed.
> 
> == Initial Goals ==
> The  following outlines some of the goals we have set ourselves during 
>incubation. Of  course, these may change as we proceed and learn more.
> 
> * Prepare ground  by defining the 3 area of Isis: Application; Framework; and 
>Plugin.
> * Address  (either fix or transfer) all tickets from Naked Objects TRAC wiki.
> * Ensure  existing documentation (of which there is a reasonable amount) is 
>correctly  related to each project now that the documentation has been separated 
>out.
> *  v 0.1 - source code combination and rationalization (as per above).
> * v 0.2 -  refactor components to JSR-299, while maintaining backwards 
>compatibility for  bootstrapping.
> * v 0.3 - JPA persistor ported from Hibernate to Apache  OpenJPA.
> * v 0.4 - integrate with JMX for runtime management; provide  profiling of 
>client/server and webapps (eg serialization vs domain logic vs  domain services 
>vs object store timings).
> * v 0.5 - write contract tests for  all major plugin APIs (object stores, 
>authentication, authorization,  remoting).
> 
> We also have a number of overarching goals:
> 
> * steadily  improve the code coverage
> * clean up the APIs. Some of the code dates back to  Java 1.1 (at one point in 
>time the code was cross-compiled into J# code); so  there is opportunity to use 
>more generics and remove use of arrays
> * steadily  reduce the amount of proprietary code, and the code size in 
>general; use newer  libraries such as google-collections more extensively.
> 
> As well as the  work going on to create the Isis project there are a number of 
>components that  are in the works, and that will be released as they are ready:
> 
> * Scimpi  web application release.
> * Introduce dynamic view design into the DnD  viewer.
> * [[http://wicket.apache.org|Wicket]] viewer release.
> * NOSQL persistor  release (using [[http://couchdb.apache.org|CouchDB]], 
>[[http://www.mongodb.org/|MongoDB]] and 
>[[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
>
> *  SQL persistor release.
> * CLI viewer release.
> * Portal integration:  Examine and implement support for compatible portals. 
>Under consideration: 
>[[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal  Server]].
> 
> Whether these are part of incubation or not will depend on  whether we feel we 
>have reached a self-sustaining community (but it's more  likely than not that 
>they will be released during incubation). Equally, there  may be other 
>viewers/persistors using other technologies that might be  implemented during 
>incubation.
> 
> == Current Status ==
> Naked Objects  4.0.0 was released at the end of 2009, broadly corresponding to 
>the release of  Dan's book.This is released into the Maven central repo, along 
>with an  application archetype for quick-start. The three sister projects 
>mentioned in  Dan's book (restful, tested, jpa) are at 1.0-beta-3, but not 
>formally released  into the Maven central repo. The remaining sister projects 
>are in alpha  status.
> 
> The main committers for the codebases to date have been Robert  Matthews and 
>Dan Haywood. Both Rob and Dan work on the NOF core, and each also  works 
>independently (reflecting their individual interests) on their respective  
>plugins. Much work was done on the core by both Rob and Dan leading up to the  
>release of NOF 4.0.0, and we are now reasonably happy with it. Much work remains  
>(see above) in the area of plugins/alternatives; there is work to complete and  
>improve the existing ones and many opportunities to develop new ones.
> 
> We  readily support users on the NO forum (on 
>[[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]]) and  also 
>on the forum for Dan's book (on pragprog.com). As a consequence of Dan's  book, 
>a GWT-based viewer (non open source) has been developed separately, and we  have 
>provided support for this (and hope it will be contributed back to the  
>framework in the future).
> 
> Over the years we have received some patches  for the framework, which we have 
>incorporated, but not many. Part of the reason  for this, we believe, is that 
>until NOF 4.0.0 it had a monolithic architecture,  making it difficult for 
>would-be contributors to provide small patches. We think  that NOF 4.0.0 
>improves in this area, but a move to JSR-299 would be a major  step forward to 
>help bring up participation.
> 
> == Community ==
> We  recognize that the lack of a large (or at least, vocal) user community is 
>the  weakest part of our proposal. That said, we do have a steady trickle of 
>queries  on both the Naked Objects forum, and on the forum for Dan's book. 
>Getting NOF  4.0.0 released has rekindled interest in at least one long-time 
>user who is  helping Rob to test one of the object store plugins, while we've 
>also picked up  commitment to help with this Apache proposal from a couple of 
>people via the  book forum.
> 
> To help build up our community we intend to:
> 
> * ensure  that the website and documentation is first-rate (see initial goals, 
>above)
> *  make sure that the Isis code can be easily used and understood
> * court other  open source projects with compatible technologies to work on 
>integrations with  Isis
> * write a series of articles for leading web journals, eg  theserverside.com, 
>javaworld.com, artima.com. We would want to point out that we  were in the 
>Apache Incubator, and actively looking for help
> * submit sessions  to Devoxx and similar, Java-focused, conferences; again we'd 
>trade on the Apache  Incubator status.
> 
> We also hope that some of the newer members of our  community will help us 
>identify what the roadblocks are to adoption, so that we  can address them.
> 
> == Core Developers ==
> The core developers  are:
> 
> * Robert Matthews, UK-based independent consultant. Original author  of the 
>Naked Objects framework, committer to the NOF core and primary developer  of the 
>NOF plugins (DnD viewer, HTML viewer, Scimpi viewer, in-memory  !ObjectStore, 
>XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL !ObjectStore,  !MongoDB 
>ObjectStore). Until recently, worked for Naked Objects Group Ltd on the  
>commercial .NET version. Is now independent and working on apps built using the  
>open source Java version.
> 
> * Dan Haywood, UK-based independent consultant.  Contributor to the Naked 
>Objects framework since 2005; took lead in much of the  restructuring of the NO 
>architecture for NOF 4.0.0. Also primary developer for  sister projects plugins 
>(!RestfulObjects viewer, !WicketObjects viewer, JPA  !ObjectStore, 
>!TestedObjects "viewer", Groovy support). Part-time  consultant/advisor to the 
>Irish Government project (since 2004); also a  trainer/consultant in agile, 
>Java, TDD etc.
> 
> Additional committers  are:
> 
> * Kevin Meyer, South Africa-based freelance developer and business  analyst. 
>Kevin has been working primarily in a testing role, both on the SQL  Object 
>Store with Rob and on the Wicket viewer with Dan. Kevin has recently  started 
>contributing fixes to both.
> 
> * Dave Slaughter, US-based  developer/consultant who is the Lead of the 
>Software and Specialty Engineering  group at SM&A. Dave has spent his career in 
>the development of enterprise  applications for companies such as Siemens, 
>Sprint and Lockheed Martin. He has  started a SWT viewer and has also started 
>improving code coverage of the XML  !ObjectStore.
> 
> * Alexander Krasnukhin, a Swedish-based developer who has  spent more than a 
>year developing different applications on Naked Objects v3 and  spent six months 
>developing a closed-source GWT viewer for Naked Objects v4.0  for his former 
>employer in Russia. Alexander is interested in developing a new  viewer for 
>Android.
> 
> As a result of a correspondence on the incubator  mailing list, we have also 
>had interest from:
> 
> * Mohammad Nour El-Din,  Egypt-based committer to Apache OpenEJB. Nour has 
>helped us with this proposal  relating to JSR-299.
> 
> * Ulrich Stark, committer to Apache Tapestry. Uli  has expressed an interest in 
>developing a Tapstry-based viewer.
> 
> We also  have had interest (off list) in developing a Vaadin viewer, and we 
>know of a  student masters project that has developed a (different) Android 
>viewer for  Naked Objects 4.0, which we're keen to incorporate if we can. We are 
>also hoping  that we might persuade Alexander's previous employer to donate 
>their GWT  viewer.
> 
> == Alignment ==
> The current codebase makes heavy use of Apache  projects, including: Maven, 
>log4j, Apache Commons  Codec/Collections/CLI/Lang/HttpClient and Wicket.
> 
> There is a particular  opportunity to integrate nicely with both Wicket and 
>Tapestry. Both Wicket and  Tapestry are great way of building web UIs, but have 
>little to say about the  "back-end". Naked Objects, meanwhile, provides a full 
>runtime environment with  pluggable persistence layers, and exposes a metamodel 
>to allow generic or  customisable UIs to be built rapidly. The currently 
>in-development  !WicketObjects viewer brings Wickets and Naked Objects together, 
>and (as noted  above) there has been interest in writing a Tapestry viewer.
> 
> Another  ongoing integration project is the ongoing-development of an object 
>store using  MongoDB; the intent is to make this codebase a good basis for other 
>similar  object stores, such as Apache CouchDB.
> 
> There are no Apache projects that  we are aware of that compete with Naked 
>Objects. At its heart, NO is (a) a  metamodel, and (b) a container that acts as 
>an abstraction over a persistence  layer, using the identity map pattern.
> 
> == Known Risks ==
> The biggest  risk is that we fail to build a diverse community during 
>incubation, opening up  the possibility that the project could be orphaned.
> 
> That said, there is  little risk that either Rob or Dan will move onto other 
>interests; we are both  independent consultants and have the resources and 
>inclination to continue  working on the codebase. Indeed, with Rob now working 
>only on the Java version  (and not the .NET one) and Dan having finished his 
>book, we have more resources  now than at any time in the last couple of years.
> 
> == Inexperience with  Open Source ==
> Although Naked Objects is an open source project, the number  of committers is 
>so small then we cannot claim great experience with open  source. Neither Rob 
>nor Dan are committers to any other open source project,  though both have 
>submitted occasional patches to the various open source  projects that we use.
> 
> We are, however, comfortable users of open source  projects. We also appreciate 
>that there are lots of open source projects out  there and that most developers 
>will form an impression of a project without  necessarily ever trying it out. 
>This is one of the reasons why we feel we need  to bring the two different 
>codebases together, and create a standard message  about what Apache Isis is 
>about ("rapid development", "domain-driven design",  "standard, extensible 
>architecture", "customizable UIs").
> 
> == Homogeneous  Developers ==
> The two main developers, Rob and Dan, are based in the UK.  Although we have 
>collaborated on the framework over the years, we do not work  for the same 
>company and are independent.
> 
> The other developers mentioned  in this proposal are based in South Africa, US, 
>Sweden, Egypt and  Germany.
> 
> == Reliance on Salaried Developers ==
> There are no salaried  developers working on the projects. The main developers, 
>Dan and Rob, are both  independent consultants. We use non-billable time to work 
>on the codebase, with  the view to developing consultancy/services from it.
> 
> == Documentation  ==
> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard 
>Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
> * Books:
> * Domain  Driven Design using Naked Objects, Dan Haywood
> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
> * Naked  Objects, Richard Pawson and Rob Matthews book Naked Objects
> * full text  available online at 
>[[http://nakedobjects.org/book/|nakedobjects.org/book]]
> * [[http://nakedobjects.org|nakedobjects.org]] - current website
> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his  book
> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's sister  
>projects; references the various SF websites for the sister projects
> 
> ==  Source and IP Submission Plan ==
> As mentioned earlier, the NO framework is  ASLv2 but copyright belongs to Naked 
>Objects Group Ltd. NOGL is happy to donate  the relevant rights to Apache, while 
>Dan is also happy to donate the various  sister projects that he has written. 
>Having a single legal entity - ASF - owning  the relevant rights to all this 
>software would be very desirable.
> 
> ==  External Dependencies ==
> Other than the Apache dependencies, all other open  source projects used all 
>have ASL v2.0 (eg Google Collections, cglib,  objenesis), BSD (eg Hamcrest, 
>ASM), MPL (eg javassist) or similarly permissive  licenses. We do also have a 
>soft dependency on an LGPL-licensed library  (Hibernate) but during migration 
>would look to migrate to the Apache equivalent  (OpenJPA).
> 
> == Required Resources ==
> * Subversion
> * Jira
> * Hudson  CI server
> * Wiki
> * Website space
> 
> == Mailing Lists ==
> *  isis-private
> * isis-dev
> * isis-commits
> * isis-user
> 
> == Subversion  Repository ==
> https://svn.apache.org/repos/asf/incubator/isis
> 
> ==  Issue Tracking ==
> Jira; project known as 'isis'
> 
> == Initial Committers  ==
> * Robert Matthews
> * Dan Haywood
> * Kevin Meyer
> * Dave  Slaughter
> * Alexander Krasnukhin
> 
> == Affiliations ==
> Alexander is  employed as a software developer by Zenterio AB. The other 
>committers are  independent consultants.
> 
> == Champion ==
> [none yet]
> 
> == Sponsors:  Nominated Mentors ==
> * Vincent Massol
> * James Carman
> * [more  required]
> 
> == Sponsor ==
> Apache  Incubator
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To  unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For  additional commands, e-mail: general-help@incubator.apache.org 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Tim Williams <wi...@gmail.com>]

On Tue, Aug 31, 2010 at 6:28 AM, Dan Haywood <dk...@gmail.com> wrote:
>  On 30/08/2010 07:26, Tim Williams wrote:
>>
>> Your proposal caused me to poke around the NO site and the first forum
>> topic I came upon[1] had someone providing a [simple] patch.  This has
>> me curious about the code provenance.  Assuming this isn't the only
>> one, could you say something about getting clearance from outside
>> contributors?  At least, it seems to me that it could be slightly more
>> complicated than the two parties you mention above.
>
> Just to update this thread... there have been very few patches historically.
>  Indeed, we've searched through our email archives (back to 2002), through
> the SVN commit logs, and through the current codebase for any comments, and
> found only 1 one-liner from 2008, and the three patches in 2010 all from the
> same user (one of which was the patch you quoted).
>
> In addition, we have three contributors/committers who have made changes.
>
> What we're doing is contacting the guy who gave us these patches, and
> getting a formal ok from the existing contributors/committers; when I have
> this I'll update the proposal.

Hi Dan, that's great, you can just update your proposal to acknowledge
this and then solve it during incubation.  I think it's important to
identify these things prior to incubation but you can work it while
you're incubating [and, obviously, prior to any release]...

--tim

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Dan Haywood <dk...@gmail.com>]

  On 30/08/2010 07:26, Tim Williams wrote:
>
> Your proposal caused me to poke around the NO site and the first forum
> topic I came upon[1] had someone providing a [simple] patch.  This has
> me curious about the code provenance.  Assuming this isn't the only
> one, could you say something about getting clearance from outside
> contributors?  At least, it seems to me that it could be slightly more
> complicated than the two parties you mention above.

Just to update this thread... there have been very few patches 
historically.  Indeed, we've searched through our email archives (back 
to 2002), through the SVN commit logs, and through the current codebase 
for any comments, and found only 1 one-liner from 2008, and the three 
patches in 2010 all from the same user (one of which was the patch you 
quoted).

In addition, we have three contributors/committers who have made changes.

What we're doing is contacting the guy who gave us these patches, and 
getting a formal ok from the existing contributors/committers; when I 
have this I'll update the proposal.

Tim, I appreciate you taking the time to look into our affairs, 
though... I'm very keen that we get this right.

Thx
Dan

Re: [PROPOSAL] Apache Isis

[Tim Williams <wi...@gmail.com>]

On Mon, Aug 30, 2010 at 8:07 AM, Benson Margulies <bi...@gmail.com> wrote:
> Um, Well, maven still uses Codehaus JIRA that lacks the 'grant to
> Apache' checkbox. Perhaps they separately negotiate iclas.

Sorry, I can't speak intelligently about maven - hopefully, the Maven
PMC has another mechanism for performing the oversight role they're
responsible for.

--tim

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Benson Margulies <bi...@gmail.com>]

Um, Well, maven still uses Codehaus JIRA that lacks the 'grant to
Apache' checkbox. Perhaps they separately negotiate iclas.

On Mon, Aug 30, 2010 at 7:57 AM, Tim Williams <wi...@gmail.com> wrote:
> On Mon, Aug 30, 2010 at 7:39 AM, Mohammad Nour El-Din
> <no...@gmail.com> wrote:
>> Hi Tim...
>>
>>   From this link - http://sourceforge.net/projects/nakedobjects -
>> project details section, it is stated that the code of this project is
>> licensed under (Apache License v2.0), and hence it is the
>> responsibility of the person who contributed any code to the project
>> to understand that his/her contribution is going to be under the same
>> license as long as it is committed as a patch to source code of
>> project they contributed to, just like what happens from contributors
>> contributing code to different Apache projects. I hope this can reply
>> your question ? :)
>
> Short answer is that I am not totally sure - I just saw that there
> were clearly other sources for the code other than the two parties
> mentioned and so I thought that should be highlighted in the IP
> Clearance section.  The question, AIUI, isn't about the license of the
> code being patched, it's the granting of the code in the patch itself.
>  We ask contributors to either submit an ICLA or check the "Grant for
> inclusion..." checkbox in JIRA.  I don't have a lot of Incubator
> experience so I'll defer on this one, it just caught my eye - my own
> understanding is that contributors would need to be tracked down[1].
>
> --tim
>
> [1] - http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
>
>> On Mon, Aug 30, 2010 at 11:26 AM, Tim Williams <wi...@gmail.com> wrote:
>>> On Tue, Aug 24, 2010 at 1:12 PM, Dan Haywood <dk...@gmail.com> wrote:
>>>>  I'd like to formally propose a new project for the incubator, Apache Isis.
>>>
>>> ... snipped....
>>>
>>>> == Source and IP Submission Plan ==
>>>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>>>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>>>> Apache, while Dan is also happy to donate the various sister projects that
>>>> he has written. Having a single legal entity - ASF - owning the relevant
>>>> rights to all this software would be very desirable.
>>>
>>> Your proposal caused me to poke around the NO site and the first forum
>>> topic I came upon[1] had someone providing a [simple] patch.  This has
>>> me curious about the code provenance.  Assuming this isn't the only
>>> one, could you say something about getting clearance from outside
>>> contributors?  At least, it seems to me that it could be slightly more
>>> complicated than the two parties you mention above.
>>>
>>> Thanks,
>>> --tim
>>>
>>> [1] - http://sourceforge.net/projects/nakedobjects/forums/forum/544071/topic/3742184
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
>>   Author of (WebSphere Application Server Community Edition 2.0 User Guide)
>>   http://www.redbooks.ibm.com/abstracts/sg247585.html
>> - LinkedIn: http://www.linkedin.com/in/mnour
>> - Blog: http://tadabborat.blogspot.com
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>>
>> "Writing clean code is what you must do in order to call yourself a
>> professional. There is no reasonable excuse for doing anything less
>> than your best."
>> - Clean Code: A Handbook of Agile Software Craftsmanship
>>
>> "Stay hungry, stay foolish."
>> - Steve Jobs
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Tim Williams <wi...@gmail.com>]

On Mon, Aug 30, 2010 at 7:39 AM, Mohammad Nour El-Din
<no...@gmail.com> wrote:
> Hi Tim...
>
>   From this link - http://sourceforge.net/projects/nakedobjects -
> project details section, it is stated that the code of this project is
> licensed under (Apache License v2.0), and hence it is the
> responsibility of the person who contributed any code to the project
> to understand that his/her contribution is going to be under the same
> license as long as it is committed as a patch to source code of
> project they contributed to, just like what happens from contributors
> contributing code to different Apache projects. I hope this can reply
> your question ? :)

Short answer is that I am not totally sure - I just saw that there
were clearly other sources for the code other than the two parties
mentioned and so I thought that should be highlighted in the IP
Clearance section.  The question, AIUI, isn't about the license of the
code being patched, it's the granting of the code in the patch itself.
 We ask contributors to either submit an ICLA or check the "Grant for
inclusion..." checkbox in JIRA.  I don't have a lot of Incubator
experience so I'll defer on this one, it just caught my eye - my own
understanding is that contributors would need to be tracked down[1].

--tim

[1] - http://incubator.apache.org/guides/mentor.html#initial-ip-clearance

> On Mon, Aug 30, 2010 at 11:26 AM, Tim Williams <wi...@gmail.com> wrote:
>> On Tue, Aug 24, 2010 at 1:12 PM, Dan Haywood <dk...@gmail.com> wrote:
>>>  I'd like to formally propose a new project for the incubator, Apache Isis.
>>
>> ... snipped....
>>
>>> == Source and IP Submission Plan ==
>>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>>> Apache, while Dan is also happy to donate the various sister projects that
>>> he has written. Having a single legal entity - ASF - owning the relevant
>>> rights to all this software would be very desirable.
>>
>> Your proposal caused me to poke around the NO site and the first forum
>> topic I came upon[1] had someone providing a [simple] patch.  This has
>> me curious about the code provenance.  Assuming this isn't the only
>> one, could you say something about getting clearance from outside
>> contributors?  At least, it seems to me that it could be slightly more
>> complicated than the two parties you mention above.
>>
>> Thanks,
>> --tim
>>
>> [1] - http://sourceforge.net/projects/nakedobjects/forums/forum/544071/topic/3742184
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Thanks
> - Mohammad Nour
>   Author of (WebSphere Application Server Community Edition 2.0 User Guide)
>   http://www.redbooks.ibm.com/abstracts/sg247585.html
> - LinkedIn: http://www.linkedin.com/in/mnour
> - Blog: http://tadabborat.blogspot.com
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
> "Writing clean code is what you must do in order to call yourself a
> professional. There is no reasonable excuse for doing anything less
> than your best."
> - Clean Code: A Handbook of Agile Software Craftsmanship
>
> "Stay hungry, stay foolish."
> - Steve Jobs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Mohammad Nour El-Din <no...@gmail.com>]

Hi Tim...

   From this link - http://sourceforge.net/projects/nakedobjects -
project details section, it is stated that the code of this project is
licensed under (Apache License v2.0), and hence it is the
responsibility of the person who contributed any code to the project
to understand that his/her contribution is going to be under the same
license as long as it is committed as a patch to source code of
project they contributed to, just like what happens from contributors
contributing code to different Apache projects. I hope this can reply
your question ? :)

On Mon, Aug 30, 2010 at 11:26 AM, Tim Williams <wi...@gmail.com> wrote:
> On Tue, Aug 24, 2010 at 1:12 PM, Dan Haywood <dk...@gmail.com> wrote:
>>  I'd like to formally propose a new project for the incubator, Apache Isis.
>
> ... snipped....
>
>> == Source and IP Submission Plan ==
>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>> Apache, while Dan is also happy to donate the various sister projects that
>> he has written. Having a single legal entity - ASF - owning the relevant
>> rights to all this software would be very desirable.
>
> Your proposal caused me to poke around the NO site and the first forum
> topic I came upon[1] had someone providing a [simple] patch.  This has
> me curious about the code provenance.  Assuming this isn't the only
> one, could you say something about getting clearance from outside
> contributors?  At least, it seems to me that it could be slightly more
> complicated than the two parties you mention above.
>
> Thanks,
> --tim
>
> [1] - http://sourceforge.net/projects/nakedobjects/forums/forum/544071/topic/3742184
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Thanks
- Mohammad Nour
  Author of (WebSphere Application Server Community Edition 2.0 User Guide)
  http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship

"Stay hungry, stay foolish."
- Steve Jobs

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Tim Williams <wi...@gmail.com>]

On Tue, Aug 24, 2010 at 1:12 PM, Dan Haywood <dk...@gmail.com> wrote:
>  I'd like to formally propose a new project for the incubator, Apache Isis.

... snipped....

> == Source and IP Submission Plan ==
> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
> Apache, while Dan is also happy to donate the various sister projects that
> he has written. Having a single legal entity - ASF - owning the relevant
> rights to all this software would be very desirable.

Your proposal caused me to poke around the NO site and the first forum
topic I came upon[1] had someone providing a [simple] patch.  This has
me curious about the code provenance.  Assuming this isn't the only
one, could you say something about getting clearance from outside
contributors?  At least, it seems to me that it could be slightly more
complicated than the two parties you mention above.

Thanks,
--tim

[1] - http://sourceforge.net/projects/nakedobjects/forums/forum/544071/topic/3742184

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Meta-mentoring needed (was: Re: [PROPOSAL] Apache Isis)

[Dan Haywood <dk...@gmail.com>]

  We're making progress on the Apache Isis proposal, and now have four 
mentors. However, only one is currently a mentor (and still quite a 
newbie), and another is really emeritus rather than active.

I'm wondering if there is any grizzled old mentor out there who might do 
a bit of meta-mentoring, ie someone for our mentors to turn to for an 
experienced eye?  The benefits are two-fold:
a) Isis improves its chance of incubating successfully
b) the Incubator itself ends up with some new mentors who might be 
disposed to mentor subsequent projects.

Looking forward to one or two +ve replies...!

Thanks
Dan


On 26/08/2010 12:24, Matthias Wessendorf wrote:
> +1 (binding)
>
> On Thu, Aug 26, 2010 at 6:23 PM, Benson Margulies<bi...@gmail.com>  wrote:
>> +1, binding.
>>
>> On Thu, Aug 26, 2010 at 12:12 PM, Siegfried Goeschl
>> <si...@it20one.at>  wrote:
>>> Hi Dan,
>>>
>>> +1 (non-binding)
>>>
>>> Cheers,
>>>
>>>
>>> Siegfried Goeschl
>>>
>>> On 24.08.10 19:12, Dan Haywood wrote:
>>>> I'd like to formally propose a new project for the incubator, Apache
>>>> Isis. If accepted, Isis will combine the existing open source Naked
>>>> Objects framework with a collection of sister projects, providing an
>>>> extensible Java-based framework for rapidly developing domain-driven
>>>> applications.
>>>>
>>>> I floated the idea of Isis on this mailing list about a month or so ago,
>>>> and we got some positive feedback and a couple of expressions of
>>>> interest in contributing. Since then, we've put together a proposal
>>>> (also copied in below) onto the incubator wiki.
>>>>
>>>> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
>>>> The current codebase is at: http://nakedobjects.org, with sister
>>>> projects hosted at: http://starobjects.org
>>>>
>>>> We currently have two mentors, but require more, and we still need a
>>>> champion. I'm hoping that this post will generate some further interest
>>>> to develop the proposal further. All being well we hope to put this
>>>> proposal to a vote in a week or two's time.
>>>>
>>>> Thanks for reading, looking forward to your feedback.
>>>> Dan Haywood
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> = Isis Proposal =
>>>> The following presents the proposal for creating a new project within
>>>> the Apache Software Foundation called Isis.
>>>>
>>>> == Abstract ==
>>>> Isis will be an extensible standards-based framework to rapidly develop
>>>> and enterprise level deploy domain-driven (DDD) applications.
>>>>
>>>> == Proposal ==
>>>> The Isis project will bring together a collection of open source
>>>> projects that collectively support the rapid development of
>>>> domain-driven applications. The heart of Isis is the Naked Objects
>>>> Framework, an established open source project that has been around since
>>>> 2002. In addition, it will incorporate a number of sister projects that
>>>> build on Naked Objects' pluggable architecture and which extend the
>>>> reach of Naked Objects in several key areas.
>>>>
>>>> In addition, the project will be reorganising the existing projects to
>>>> logically separate out the components into
>>>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]
>>>> beans. We believe that the JSR-299 programming model is likely to become
>>>> widely used for enterprise Java applications; adopting it should make it
>>>> easier for new contributors to understand how the framework fits
>>>> together and therefore to develop their own extensions. In turn, we hope
>>>> this will further extend the reach of the framework to other
>>>> complementary open source frameworks (either within Apache or outside of
>>>> it).
>>>>
>>>> == Background ==
>>>> Naked Objects is an open source Java framework that was originally
>>>> developed to explore the idea of enterprise systems that treat the user
>>>> as a "problem solver, not a process follower". Conceived by Richard
>>>> Pawson, the first version of the framework was written by Robert
>>>> Matthews (2002). Richard and Rob also wrote a book, Naked Objects
>>>> (Wiley, 2002), to explain the idea.
>>>>
>>>> More generally, Naked Objects is an implementation of the naked objects
>>>> architectural pattern. In its purest form, "all" the developer has to do
>>>> is develop their domain model as pojos; Naked Objects then provides: a
>>>> object-oriented user interface by rendering those pojos; persistence by
>>>> extracting the content of the pojos; security by wrapping access to the
>>>> pojos; remoting by turning local calls into remote ones; and
>>>> localisation by adapting all the names used in the metamodel. All of
>>>> this is done reflectively at runtime so that the developer can
>>>> concentrate on the most important aspect - the application itself. You
>>>> can think of Naked Objects' OOUI generation as analogous to Hibernate
>>>> and other ORMs, but rather than reflecting the pojo into the persistence
>>>> layer, they are reflected into the presentation layer. A number of other
>>>> open source frameworks cite it as their inspiration, including
>>>> [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and
>>>> [[http://www.trailsframework.org|Trails]].
>>>>
>>>> Over this time Naked Objects has attracted a fair degree of attention
>>>> among the early adopter crowd, generally splitting opinion as either a
>>>> very good idea or a very bad one. A common misconception is that naked
>>>> objects is only appropriate for simple CRUD based applications. While
>>>> developing CRUD applications is indeed trivial, an important innovation
>>>> is that the UI generated by NO also renders the pojo's
>>>> commands/behaviors (we call them actions). Simply stated: any public
>>>> method that does not represent a property or collection is rendered so
>>>> it can be invoked, eg with a button, a menu item or a hyperlink. We
>>>> characterize entities with such behaviors as "behaviorally complete".
>>>> It's OO as your mother taught it to you.
>>>>
>>>> At the same time that we have been developing our ideas on the naked
>>>> objects, there has been a resurgent interest in object modelling at the
>>>> enterprise level, specifically as described by Eric Evans' book,
>>>> [[http://domaindrivendesign.org/books|Domain Driven Design]].
>>>> Recognizing that there's a lot of synergy between the two ideas, the NO
>>>> framework now uses DDD terminology, such as repository, domain service
>>>> and value.
>>>>
>>>> As mentioned in the proposal section, Isis will consist of both the
>>>> original NO framework, along with a number of sister projects. These
>>>> sister projects were written by Dan Haywood to support a book he wrote
>>>> about the framework, [[http://pragprog.com/titles/dhnako|Domain Driven
>>>> Design using Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of
>>>> these projects was to demonstrate the pluggable nature of the framework.
>>>>
>>>> Both Naked Objects and its sister projects are under the ASL v2 license.
>>>>
>>>> Not directly related to this proposal but worth mentioning: Naked
>>>> Objects has also been ported to the .NET platform, as a commercial
>>>> product. Richard Pawson, the originator of the naked objects pattern,
>>>> now devotes his energies to the [[http://nakedobjects.net|.NET version]]
>>>> and is no longer involved in the open source Java version. Conversely,
>>>> Rob Matthews, the originator of the framework and a co-author of this
>>>> proposal, now devotes his energies to the Java version, not the .NET one.
>>>>
>>>> == Rationale ==
>>>> We recognize that the key to open source projects long-term success is a
>>>> large user base, along with a goodly number of diverse active and
>>>> enthusiastic committers. Being brutally honest, we cannot claim to have
>>>> either. That said, we are not naive enough to think that entrance into
>>>> the Apache incubator will automatically bring us these things. Rather,
>>>> we believe it will give us a platform to more effectively publicize the
>>>> project so that it can succeed. It will also allow us to take advantage
>>>> of the collaborative environment that the Apache Software Foundation
>>>> provides. Attracting a diverse group of developers will also provide the
>>>> opportunity for significant advancements and improvements to the Isis
>>>> framework, making it more useful for more people.
>>>>
>>>> There are, then, several reasons for us wanting to contribute the
>>>> framework to Apache.
>>>>
>>>> First, it helps us legitimize the "naked objects" concept.
>>>> Notwithstanding the fact that the project has attracted its fair share
>>>> of nay-sayers, as its developers we remain convinced of its usefulness
>>>> and contribution to enterprise development in general. Most
>>>> significantly, (v2.0 of) Naked Objects was used to develop the online
>>>> application for benefits administration of pensions and other state
>>>> benefits for the Irish Government. This project went live in 2006, is
>>>> used by 1500+ users on a day-by-day basis, consists of an enterprise
>>>> domain model of approximately 500 entities, and pushes out a new release
>>>> each month. Richard and Dan remain consultants to this project; we would
>>>> dearly like others to reap the benefit of building enterprise
>>>> applications in this way.
>>>>
>>>> Second, and as already mentioned, it gives us a platform on which to
>>>> publicize. The Naked Objects framework did have its moment in the sun
>>>> about 5~6 years back, but, at that time, it was under a GPL license
>>>> rather than ASL v2. We were also solely focused in developing the
>>>> aforementioned benefits system, rather than building an open source
>>>> community. One could argue that we had an opportunity and we blew it; at
>>>> any rate what we hope is that Apache will give us an opportunity to
>>>> build up a new community. At Devoxx 2009 we ran an informal poll to get
>>>> opinions of Naked Objects, from "best thing since sliced bread", through
>>>> "fundamentally flawed", to "never heard of it". There were 5x as many
>>>> votes in "never heard of it" as there were in all of the other columns.
>>>> That can either be taken as very disappointing, or as an opportunity. We
>>>> prefer the latter interpretation.
>>>>
>>>> Third, by renaming the project to Isis, it gives us a chance to
>>>> reposition the framework. While the "naked objects" pattern is
>>>> important, we also want to emphasize domain-driven design. Alistair
>>>> Cockburn's hexagonal (or "ports and adapters") architecture is another
>>>> influence; the plugins that the NO framework supports (see
>>>> [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either
>>>> ports/adapters from the presentation layer, or ports/adapters to the
>>>> persistence layer. Furthermore, the newer UI viewers that we have been
>>>> developing allow the UI to be customized in various ways and to various
>>>> extents; so the pojos are not necessarily naked, they are lightly (or
>>>> heavily!) clad. And also, being blunt, that term "naked", while
>>>> attracting the "bleeding edge" guys, tends to be a turn-off for the
>>>> "early majority" who we now want to target.
>>>>
>>>> Fourth, it removes doubt over its direction. Currently the NO framework
>>>> is ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard
>>>> Pawson still the figurehead of the naked objects movement. As already
>>>> mentioned, NOGL's energy is in their commercial .NET product. They are
>>>> happy to donate the relevant rights to this software to Apache because
>>>> they recognise that the framework is already critically dependent upon
>>>> the open source community, so this is the best way to encourage greater
>>>> take up, and ensure its future. Changing the name of the Java version
>>>> also means it removes confusion in the market place as to what Naked
>>>> Objects framework is (ie a .NET product only). Meanwhile the rights to
>>>> the various sister projects that Dan has written would also be donated
>>>> to ASF. Having a single legal entity - ASF - owning rights for all of
>>>> this software would be very desirable; we think it might prompt others
>>>> to explore the framework.
>>>>
>>>> Fifth, the synergies with other Apache projects will help us meet our
>>>> ambition to make the framework easier to extend. There are two principle
>>>> extension points of the framework: viewers, and object stores. While we
>>>> do understand that it isn't a goal of Apache per se to create a
>>>> portfolio of frameworks, we hope that being part of the Apache family
>>>> might encourage members of these other communities to help us develop
>>>> new viewers or object stores. One of the sister projects provides a
>>>> customizable viewer that uses Wicket; since pre-announcing this proposal
>>>> on the incubator mailing list we've had one expression of interest to
>>>> develop a new viewer using Tapestry.
>>>>
>>>> The 'domain services' angle of DDD also means there are opportunities to
>>>> integrate with frameworks that aren't just about presentation or
>>>> persistence; in Dan's book he sketches out an integration with
>>>> [[camel.apache.org|Camel]; there are multiple opportunities here. We
>>>> also hope to tap into expertise to help us refactor the framework
>>>> components into JSR-299 beans. Again, we've had an expression of
>>>> interest from the incubator mailing list along these lines.
>>>>
>>>> Sixth, it isn't finished. As has been pointed out to us, projects whose
>>>> codebases are finished don't make for good project candidates. Isis,
>>>> though, will probably never be truly finished. The hexagonal
>>>> architecture, as we think of it, is about plugging in different
>>>> presentation and persistence layers. We have several viewers that are in
>>>> active development (including the Wicket, and a RESTful-based viewer),
>>>> and object stores too (BerkleyDB, MongoDB, vanilla SQL). But there are
>>>> lots of UI frameworks we haven't even started on, either Apache's own
>>>> (eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, …)
>>>> or external (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
>>>> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
>>>> Silverlight, …). The same is true for persistence technologies, both
>>>> internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]],
>>>> [[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase,
>>>> iBATIS, ...) and external (eg neo4j, db4o,
>>>> [[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3,
>>>> JCloud … ). And… there are also lots of development tools that could be
>>>> built, either IDE integrations, or into build tools such as Maven.
>>>>
>>>> In summary: we hope that incubation will allow us to develop Isis into a
>>>> standards-based framework for building domain-driven apps, appealing
>>>> both to its user community (who just want to use it "out-of-the-box")
>>>> and to its contributor community (who want to quickly understand how it
>>>> works and what is required to extend it).
>>>>
>>>> == Initial Source ==
>>>> === 1. Combine the codebases ===
>>>> Both the core Naked Objects framework and the sister projects reside in
>>>> Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:
>>>>
>>>> * nakedobjects.sourceforge.net
>>>> * wicketobjects.sourceforge.net
>>>> * restfulobjects.sourceforge.net
>>>> * jpaobjects.sourceforge.net
>>>> * testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]],
>>>> [[http://www.concordion.org/|Concordion]])
>>>> * groovyobjects.sourceforge.net
>>>>
>>>> These will need to be moved into a single Subversion tree, hosted on
>>>> Apache infrastructure.
>>>>
>>>> === 2. Rationalize the builds ===
>>>> Both the NO codebase and the sister projects are built using Maven 2. It
>>>> shouldn't be difficult to combine these into a single build.
>>>>
>>>> === 3. Standardize package names ===
>>>> Naked Objects package names are currently:
>>>>
>>>> * org.nakedobjects.applib.* and org.nakedobjects.service.* for the
>>>> applib and domain services
>>>> * org.nakedobjects.core.* for the core
>>>> * org.nakedobjects.plugins.xxx for each plugin
>>>>
>>>> These should move, respectively, to
>>>>
>>>> * org.apache.isis.application.*
>>>> * org.apache.isis.core.* and
>>>> * org.apache.isis.alternatives.xxx (we expect that plugins will become
>>>>
>>>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]]
>>>> under JSR-299).
>>>>
>>>> The sister projects package names are currently:
>>>>
>>>> * org.starobjects.wicket.* (for wicket objects)
>>>> * org.starobjects.restful.* (for restful objects)
>>>>
>>>> etc.
>>>>
>>>> Because these are all just plugins/alternatives, they should just move
>>>> to org.apache.isis.alternatives.*.
>>>>
>>>> === 4. Move the version number down. ===
>>>> To emphasize the fact that this is a new project not yet considered
>>>> complete, we will move the number back down to<  1.0, eg v0.1. This will
>>>> allow us to work on a number of releases, hopefully getting to 1.0 as
>>>> and when we graduate from the incubator.
>>>>
>>>> === 5. Establish continuous integration ===
>>>> The Naked Objects framework currently builds on its own Hudson server;
>>>> we would move this over to run on Apache infrastructure.
>>>>
>>>> === 6. Rationalize documentation ===
>>>> The documentation for the sister projects is reasonably up-to-date, but
>>>> the documentation for Naked Objects needs rationalizing, aligning with
>>>> the core component and the various plugins. This will help make the
>>>> framework more digestible to new users/would-be committers; they can
>>>> focus on the core, or a bit of the core (say, the metamodel), or work on
>>>> just one plugin.
>>>>
>>>> === 7. Rationalize the Maven sites ===
>>>> Related to above, we need to "tell the story better" so that would-be
>>>> users can see what benefits using the framework will bring (and,
>>>> conversely, what freedom they give up in adopting a framework).
>>>>
>>>> === 8. Review/copy over outstanding tickets. ===
>>>> There are a number of tickets in the Naked Objects TRAC wiki. These
>>>> should be either moved over, or fixed.
>>>>
>>>> == Initial Goals ==
>>>> The following outlines some of the goals we have set ourselves during
>>>> incubation. Of course, these may change as we proceed and learn more.
>>>>
>>>> * Prepare ground by defining the 3 area of Isis: Application; Framework;
>>>> and Plugin.
>>>> * Address (either fix or transfer) all tickets from Naked Objects TRAC
>>>> wiki.
>>>> * Ensure existing documentation (of which there is a reasonable amount)
>>>> is correctly related to each project now that the documentation has been
>>>> separated out.
>>>> * v 0.1 - source code combination and rationalization (as per above).
>>>> * v 0.2 - refactor components to JSR-299, while maintaining backwards
>>>> compatibility for bootstrapping.
>>>> * v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
>>>> * v 0.4 - integrate with JMX for runtime management; provide profiling
>>>> of client/server and webapps (eg serialization vs domain logic vs domain
>>>> services vs object store timings).
>>>> * v 0.5 - write contract tests for all major plugin APIs (object stores,
>>>> authentication, authorization, remoting).
>>>>
>>>> We also have a number of overarching goals:
>>>>
>>>> * steadily improve the code coverage
>>>> * clean up the APIs. Some of the code dates back to Java 1.1 (at one
>>>> point in time the code was cross-compiled into J# code); so there is
>>>> opportunity to use more generics and remove use of arrays
>>>> * steadily reduce the amount of proprietary code, and the code size in
>>>> general; use newer libraries such as google-collections more extensively.
>>>>
>>>> As well as the work going on to create the Isis project there are a
>>>> number of components that are in the works, and that will be released as
>>>> they are ready:
>>>>
>>>> * Scimpi web application release.
>>>> * Introduce dynamic view design into the DnD viewer.
>>>> * [[http://wicket.apache.org|Wicket]] viewer release.
>>>> * NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]],
>>>> [[http://www.mongodb.org/|MongoDB]] and
>>>>
>>>> [[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
>>>>
>>>> * SQL persistor release.
>>>> * CLI viewer release.
>>>> * Portal integration: Examine and implement support for compatible
>>>> portals. Under consideration:
>>>> [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal
>>>> Server]].
>>>>
>>>> Whether these are part of incubation or not will depend on whether we
>>>> feel we have reached a self-sustaining community (but it's more likely
>>>> than not that they will be released during incubation). Equally, there
>>>> may be other viewers/persistors using other technologies that might be
>>>> implemented during incubation.
>>>>
>>>> == Current Status ==
>>>> Naked Objects 4.0.0 was released at the end of 2009, broadly
>>>> corresponding to the release of Dan's book.This is released into the
>>>> Maven central repo, along with an application archetype for quick-start.
>>>> The three sister projects mentioned in Dan's book (restful, tested, jpa)
>>>> are at 1.0-beta-3, but not formally released into the Maven central
>>>> repo. The remaining sister projects are in alpha status.
>>>>
>>>> The main committers for the codebases to date have been Robert Matthews
>>>> and Dan Haywood. Both Rob and Dan work on the NOF core, and each also
>>>> works independently (reflecting their individual interests) on their
>>>> respective plugins. Much work was done on the core by both Rob and Dan
>>>> leading up to the release of NOF 4.0.0, and we are now reasonably happy
>>>> with it. Much work remains (see above) in the area of
>>>> plugins/alternatives; there is work to complete and improve the existing
>>>> ones and many opportunities to develop new ones.
>>>>
>>>> We readily support users on the NO forum (on
>>>> [[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]])
>>>> and also on the forum for Dan's book (on pragprog.com). As a consequence
>>>> of Dan's book, a GWT-based viewer (non open source) has been developed
>>>> separately, and we have provided support for this (and hope it will be
>>>> contributed back to the framework in the future).
>>>>
>>>> Over the years we have received some patches for the framework, which we
>>>> have incorporated, but not many. Part of the reason for this, we
>>>> believe, is that until NOF 4.0.0 it had a monolithic architecture,
>>>> making it difficult for would-be contributors to provide small patches.
>>>> We think that NOF 4.0.0 improves in this area, but a move to JSR-299
>>>> would be a major step forward to help bring up participation.
>>>>
>>>> == Community ==
>>>> We recognize that the lack of a large (or at least, vocal) user
>>>> community is the weakest part of our proposal. That said, we do have a
>>>> steady trickle of queries on both the Naked Objects forum, and on the
>>>> forum for Dan's book. Getting NOF 4.0.0 released has rekindled interest
>>>> in at least one long-time user who is helping Rob to test one of the
>>>> object store plugins, while we've also picked up commitment to help with
>>>> this Apache proposal from a couple of people via the book forum.
>>>>
>>>> To help build up our community we intend to:
>>>>
>>>> * ensure that the website and documentation is first-rate (see initial
>>>> goals, above)
>>>> * make sure that the Isis code can be easily used and understood
>>>> * court other open source projects with compatible technologies to work
>>>> on integrations with Isis
>>>> * write a series of articles for leading web journals, eg
>>>> theserverside.com, javaworld.com, artima.com. We would want to point out
>>>> that we were in the Apache Incubator, and actively looking for help
>>>> * submit sessions to Devoxx and similar, Java-focused, conferences;
>>>> again we'd trade on the Apache Incubator status.
>>>>
>>>> We also hope that some of the newer members of our community will help
>>>> us identify what the roadblocks are to adoption, so that we can address
>>>> them.
>>>>
>>>> == Core Developers ==
>>>> The core developers are:
>>>>
>>>> * Robert Matthews, UK-based independent consultant. Original author of
>>>> the Naked Objects framework, committer to the NOF core and primary
>>>> developer of the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer,
>>>> in-memory !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL
>>>> !ObjectStore, !MongoDB ObjectStore). Until recently, worked for Naked
>>>> Objects Group Ltd on the commercial .NET version. Is now independent and
>>>> working on apps built using the open source Java version.
>>>>
>>>> * Dan Haywood, UK-based independent consultant. Contributor to the Naked
>>>> Objects framework since 2005; took lead in much of the restructuring of
>>>> the NO architecture for NOF 4.0.0. Also primary developer for sister
>>>> projects plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA
>>>> !ObjectStore, !TestedObjects "viewer", Groovy support). Part-time
>>>> consultant/advisor to the Irish Government project (since 2004); also a
>>>> trainer/consultant in agile, Java, TDD etc.
>>>>
>>>> Additional committers are:
>>>>
>>>> * Kevin Meyer, South Africa-based freelance developer and business
>>>> analyst. Kevin has been working primarily in a testing role, both on the
>>>> SQL Object Store with Rob and on the Wicket viewer with Dan. Kevin has
>>>> recently started contributing fixes to both.
>>>>
>>>> * Dave Slaughter, US-based developer/consultant who is the Lead of the
>>>> Software and Specialty Engineering group at SM&A. Dave has spent his
>>>> career in the development of enterprise applications for companies such
>>>> as Siemens, Sprint and Lockheed Martin. He has started a SWT viewer and
>>>> has also started improving code coverage of the XML !ObjectStore.
>>>>
>>>> * Alexander Krasnukhin, a Swedish-based developer who has spent more
>>>> than a year developing different applications on Naked Objects v3 and
>>>> spent six months developing a closed-source GWT viewer for Naked Objects
>>>> v4.0 for his former employer in Russia. Alexander is interested in
>>>> developing a new viewer for Android.
>>>>
>>>> As a result of a correspondence on the incubator mailing list, we have
>>>> also had interest from:
>>>>
>>>> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour
>>>> has helped us with this proposal relating to JSR-299.
>>>>
>>>> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an
>>>> interest in developing a Tapstry-based viewer.
>>>>
>>>> We also have had interest (off list) in developing a Vaadin viewer, and
>>>> we know of a student masters project that has developed a (different)
>>>> Android viewer for Naked Objects 4.0, which we're keen to incorporate if
>>>> we can. We are also hoping that we might persuade Alexander's previous
>>>> employer to donate their GWT viewer.
>>>>
>>>> == Alignment ==
>>>> The current codebase makes heavy use of Apache projects, including:
>>>> Maven, log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and
>>>> Wicket.
>>>>
>>>> There is a particular opportunity to integrate nicely with both Wicket
>>>> and Tapestry. Both Wicket and Tapestry are great way of building web
>>>> UIs, but have little to say about the "back-end". Naked Objects,
>>>> meanwhile, provides a full runtime environment with pluggable
>>>> persistence layers, and exposes a metamodel to allow generic or
>>>> customisable UIs to be built rapidly. The currently in-development
>>>> !WicketObjects viewer brings Wickets and Naked Objects together, and (as
>>>> noted above) there has been interest in writing a Tapestry viewer.
>>>>
>>>> Another ongoing integration project is the ongoing-development of an
>>>> object store using MongoDB; the intent is to make this codebase a good
>>>> basis for other similar object stores, such as Apache CouchDB.
>>>>
>>>> There are no Apache projects that we are aware of that compete with
>>>> Naked Objects. At its heart, NO is (a) a metamodel, and (b) a container
>>>> that acts as an abstraction over a persistence layer, using the identity
>>>> map pattern.
>>>>
>>>> == Known Risks ==
>>>> The biggest risk is that we fail to build a diverse community during
>>>> incubation, opening up the possibility that the project could be orphaned.
>>>>
>>>> That said, there is little risk that either Rob or Dan will move onto
>>>> other interests; we are both independent consultants and have the
>>>> resources and inclination to continue working on the codebase. Indeed,
>>>> with Rob now working only on the Java version (and not the .NET one) and
>>>> Dan having finished his book, we have more resources now than at any
>>>> time in the last couple of years.
>>>>
>>>> == Inexperience with Open Source ==
>>>> Although Naked Objects is an open source project, the number of
>>>> committers is so small then we cannot claim great experience with open
>>>> source. Neither Rob nor Dan are committers to any other open source
>>>> project, though both have submitted occasional patches to the various
>>>> open source projects that we use.
>>>>
>>>> We are, however, comfortable users of open source projects. We also
>>>> appreciate that there are lots of open source projects out there and
>>>> that most developers will form an impression of a project without
>>>> necessarily ever trying it out. This is one of the reasons why we feel
>>>> we need to bring the two different codebases together, and create a
>>>> standard message about what Apache Isis is about ("rapid development",
>>>> "domain-driven design", "standard, extensible architecture",
>>>> "customizable UIs").
>>>>
>>>> == Homogeneous Developers ==
>>>> The two main developers, Rob and Dan, are based in the UK. Although we
>>>> have collaborated on the framework over the years, we do not work for
>>>> the same company and are independent.
>>>>
>>>> The other developers mentioned in this proposal are based in South
>>>> Africa, US, Sweden, Egypt and Germany.
>>>>
>>>> == Reliance on Salaried Developers ==
>>>> There are no salaried developers working on the projects. The main
>>>> developers, Dan and Rob, are both independent consultants. We use
>>>> non-billable time to work on the codebase, with the view to developing
>>>> consultancy/services from it.
>>>>
>>>> == Documentation ==
>>>> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard
>>>> Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
>>>> * Books:
>>>> * Domain Driven Design using Naked Objects, Dan Haywood
>>>> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
>>>> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
>>>> * full text available online at
>>>> [[http://nakedobjects.org/book/|nakedobjects.org/book]]
>>>> * [[http://nakedobjects.org|nakedobjects.org]] - current website
>>>> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his
>>>> book
>>>> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's
>>>> sister projects; references the various SF websites for the sister
>>>> projects
>>>>
>>>> == Source and IP Submission Plan ==
>>>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>>>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>>>> Apache, while Dan is also happy to donate the various sister projects
>>>> that he has written. Having a single legal entity - ASF - owning the
>>>> relevant rights to all this software would be very desirable.
>>>>
>>>> == External Dependencies ==
>>>> Other than the Apache dependencies, all other open source projects used
>>>> all have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg
>>>> Hamcrest, ASM), MPL (eg javassist) or similarly permissive licenses. We
>>>> do also have a soft dependency on an LGPL-licensed library (Hibernate)
>>>> but during migration would look to migrate to the Apache equivalent
>>>> (OpenJPA).
>>>>
>>>> == Required Resources ==
>>>> * Subversion
>>>> * Jira
>>>> * Hudson CI server
>>>> * Wiki
>>>> * Website space
>>>>
>>>> == Mailing Lists ==
>>>> * isis-private
>>>> * isis-dev
>>>> * isis-commits
>>>> * isis-user
>>>>
>>>> == Subversion Repository ==
>>>> https://svn.apache.org/repos/asf/incubator/isis
>>>>
>>>> == Issue Tracking ==
>>>> Jira; project known as 'isis'
>>>>
>>>> == Initial Committers ==
>>>> * Robert Matthews
>>>> * Dan Haywood
>>>> * Kevin Meyer
>>>> * Dave Slaughter
>>>> * Alexander Krasnukhin
>>>>
>>>> == Affiliations ==
>>>> Alexander is employed as a software developer by Zenterio AB. The other
>>>> committers are independent consultants.
>>>>
>>>> == Champion ==
>>>> [none yet]
>>>>
>>>> == Sponsors: Nominated Mentors ==
>>>> * Vincent Massol
>>>> * James Carman
>>>> * [more required]
>>>>
>>>> == Sponsor ==
>>>> Apache Incubator
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>

Re: [PROPOSAL] Apache Isis

[Matthias Wessendorf <ma...@apache.org>]

+1 (binding)

On Thu, Aug 26, 2010 at 6:23 PM, Benson Margulies <bi...@gmail.com> wrote:
> +1, binding.
>
> On Thu, Aug 26, 2010 at 12:12 PM, Siegfried Goeschl
> <si...@it20one.at> wrote:
>> Hi Dan,
>>
>> +1 (non-binding)
>>
>> Cheers,
>>
>>
>> Siegfried Goeschl
>>
>> On 24.08.10 19:12, Dan Haywood wrote:
>>>
>>> I'd like to formally propose a new project for the incubator, Apache
>>> Isis. If accepted, Isis will combine the existing open source Naked
>>> Objects framework with a collection of sister projects, providing an
>>> extensible Java-based framework for rapidly developing domain-driven
>>> applications.
>>>
>>> I floated the idea of Isis on this mailing list about a month or so ago,
>>> and we got some positive feedback and a couple of expressions of
>>> interest in contributing. Since then, we've put together a proposal
>>> (also copied in below) onto the incubator wiki.
>>>
>>> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
>>> The current codebase is at: http://nakedobjects.org, with sister
>>> projects hosted at: http://starobjects.org
>>>
>>> We currently have two mentors, but require more, and we still need a
>>> champion. I'm hoping that this post will generate some further interest
>>> to develop the proposal further. All being well we hope to put this
>>> proposal to a vote in a week or two's time.
>>>
>>> Thanks for reading, looking forward to your feedback.
>>> Dan Haywood
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> = Isis Proposal =
>>> The following presents the proposal for creating a new project within
>>> the Apache Software Foundation called Isis.
>>>
>>> == Abstract ==
>>> Isis will be an extensible standards-based framework to rapidly develop
>>> and enterprise level deploy domain-driven (DDD) applications.
>>>
>>> == Proposal ==
>>> The Isis project will bring together a collection of open source
>>> projects that collectively support the rapid development of
>>> domain-driven applications. The heart of Isis is the Naked Objects
>>> Framework, an established open source project that has been around since
>>> 2002. In addition, it will incorporate a number of sister projects that
>>> build on Naked Objects' pluggable architecture and which extend the
>>> reach of Naked Objects in several key areas.
>>>
>>> In addition, the project will be reorganising the existing projects to
>>> logically separate out the components into
>>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]
>>> beans. We believe that the JSR-299 programming model is likely to become
>>> widely used for enterprise Java applications; adopting it should make it
>>> easier for new contributors to understand how the framework fits
>>> together and therefore to develop their own extensions. In turn, we hope
>>> this will further extend the reach of the framework to other
>>> complementary open source frameworks (either within Apache or outside of
>>> it).
>>>
>>> == Background ==
>>> Naked Objects is an open source Java framework that was originally
>>> developed to explore the idea of enterprise systems that treat the user
>>> as a "problem solver, not a process follower". Conceived by Richard
>>> Pawson, the first version of the framework was written by Robert
>>> Matthews (2002). Richard and Rob also wrote a book, Naked Objects
>>> (Wiley, 2002), to explain the idea.
>>>
>>> More generally, Naked Objects is an implementation of the naked objects
>>> architectural pattern. In its purest form, "all" the developer has to do
>>> is develop their domain model as pojos; Naked Objects then provides: a
>>> object-oriented user interface by rendering those pojos; persistence by
>>> extracting the content of the pojos; security by wrapping access to the
>>> pojos; remoting by turning local calls into remote ones; and
>>> localisation by adapting all the names used in the metamodel. All of
>>> this is done reflectively at runtime so that the developer can
>>> concentrate on the most important aspect - the application itself. You
>>> can think of Naked Objects' OOUI generation as analogous to Hibernate
>>> and other ORMs, but rather than reflecting the pojo into the persistence
>>> layer, they are reflected into the presentation layer. A number of other
>>> open source frameworks cite it as their inspiration, including
>>> [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and
>>> [[http://www.trailsframework.org|Trails]].
>>>
>>> Over this time Naked Objects has attracted a fair degree of attention
>>> among the early adopter crowd, generally splitting opinion as either a
>>> very good idea or a very bad one. A common misconception is that naked
>>> objects is only appropriate for simple CRUD based applications. While
>>> developing CRUD applications is indeed trivial, an important innovation
>>> is that the UI generated by NO also renders the pojo's
>>> commands/behaviors (we call them actions). Simply stated: any public
>>> method that does not represent a property or collection is rendered so
>>> it can be invoked, eg with a button, a menu item or a hyperlink. We
>>> characterize entities with such behaviors as "behaviorally complete".
>>> It's OO as your mother taught it to you.
>>>
>>> At the same time that we have been developing our ideas on the naked
>>> objects, there has been a resurgent interest in object modelling at the
>>> enterprise level, specifically as described by Eric Evans' book,
>>> [[http://domaindrivendesign.org/books|Domain Driven Design]].
>>> Recognizing that there's a lot of synergy between the two ideas, the NO
>>> framework now uses DDD terminology, such as repository, domain service
>>> and value.
>>>
>>> As mentioned in the proposal section, Isis will consist of both the
>>> original NO framework, along with a number of sister projects. These
>>> sister projects were written by Dan Haywood to support a book he wrote
>>> about the framework, [[http://pragprog.com/titles/dhnako|Domain Driven
>>> Design using Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of
>>> these projects was to demonstrate the pluggable nature of the framework.
>>>
>>> Both Naked Objects and its sister projects are under the ASL v2 license.
>>>
>>> Not directly related to this proposal but worth mentioning: Naked
>>> Objects has also been ported to the .NET platform, as a commercial
>>> product. Richard Pawson, the originator of the naked objects pattern,
>>> now devotes his energies to the [[http://nakedobjects.net|.NET version]]
>>> and is no longer involved in the open source Java version. Conversely,
>>> Rob Matthews, the originator of the framework and a co-author of this
>>> proposal, now devotes his energies to the Java version, not the .NET one.
>>>
>>> == Rationale ==
>>> We recognize that the key to open source projects long-term success is a
>>> large user base, along with a goodly number of diverse active and
>>> enthusiastic committers. Being brutally honest, we cannot claim to have
>>> either. That said, we are not naive enough to think that entrance into
>>> the Apache incubator will automatically bring us these things. Rather,
>>> we believe it will give us a platform to more effectively publicize the
>>> project so that it can succeed. It will also allow us to take advantage
>>> of the collaborative environment that the Apache Software Foundation
>>> provides. Attracting a diverse group of developers will also provide the
>>> opportunity for significant advancements and improvements to the Isis
>>> framework, making it more useful for more people.
>>>
>>> There are, then, several reasons for us wanting to contribute the
>>> framework to Apache.
>>>
>>> First, it helps us legitimize the "naked objects" concept.
>>> Notwithstanding the fact that the project has attracted its fair share
>>> of nay-sayers, as its developers we remain convinced of its usefulness
>>> and contribution to enterprise development in general. Most
>>> significantly, (v2.0 of) Naked Objects was used to develop the online
>>> application for benefits administration of pensions and other state
>>> benefits for the Irish Government. This project went live in 2006, is
>>> used by 1500+ users on a day-by-day basis, consists of an enterprise
>>> domain model of approximately 500 entities, and pushes out a new release
>>> each month. Richard and Dan remain consultants to this project; we would
>>> dearly like others to reap the benefit of building enterprise
>>> applications in this way.
>>>
>>> Second, and as already mentioned, it gives us a platform on which to
>>> publicize. The Naked Objects framework did have its moment in the sun
>>> about 5~6 years back, but, at that time, it was under a GPL license
>>> rather than ASL v2. We were also solely focused in developing the
>>> aforementioned benefits system, rather than building an open source
>>> community. One could argue that we had an opportunity and we blew it; at
>>> any rate what we hope is that Apache will give us an opportunity to
>>> build up a new community. At Devoxx 2009 we ran an informal poll to get
>>> opinions of Naked Objects, from "best thing since sliced bread", through
>>> "fundamentally flawed", to "never heard of it". There were 5x as many
>>> votes in "never heard of it" as there were in all of the other columns.
>>> That can either be taken as very disappointing, or as an opportunity. We
>>> prefer the latter interpretation.
>>>
>>> Third, by renaming the project to Isis, it gives us a chance to
>>> reposition the framework. While the "naked objects" pattern is
>>> important, we also want to emphasize domain-driven design. Alistair
>>> Cockburn's hexagonal (or "ports and adapters") architecture is another
>>> influence; the plugins that the NO framework supports (see
>>> [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either
>>> ports/adapters from the presentation layer, or ports/adapters to the
>>> persistence layer. Furthermore, the newer UI viewers that we have been
>>> developing allow the UI to be customized in various ways and to various
>>> extents; so the pojos are not necessarily naked, they are lightly (or
>>> heavily!) clad. And also, being blunt, that term "naked", while
>>> attracting the "bleeding edge" guys, tends to be a turn-off for the
>>> "early majority" who we now want to target.
>>>
>>> Fourth, it removes doubt over its direction. Currently the NO framework
>>> is ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard
>>> Pawson still the figurehead of the naked objects movement. As already
>>> mentioned, NOGL's energy is in their commercial .NET product. They are
>>> happy to donate the relevant rights to this software to Apache because
>>> they recognise that the framework is already critically dependent upon
>>> the open source community, so this is the best way to encourage greater
>>> take up, and ensure its future. Changing the name of the Java version
>>> also means it removes confusion in the market place as to what Naked
>>> Objects framework is (ie a .NET product only). Meanwhile the rights to
>>> the various sister projects that Dan has written would also be donated
>>> to ASF. Having a single legal entity - ASF - owning rights for all of
>>> this software would be very desirable; we think it might prompt others
>>> to explore the framework.
>>>
>>> Fifth, the synergies with other Apache projects will help us meet our
>>> ambition to make the framework easier to extend. There are two principle
>>> extension points of the framework: viewers, and object stores. While we
>>> do understand that it isn't a goal of Apache per se to create a
>>> portfolio of frameworks, we hope that being part of the Apache family
>>> might encourage members of these other communities to help us develop
>>> new viewers or object stores. One of the sister projects provides a
>>> customizable viewer that uses Wicket; since pre-announcing this proposal
>>> on the incubator mailing list we've had one expression of interest to
>>> develop a new viewer using Tapestry.
>>>
>>> The 'domain services' angle of DDD also means there are opportunities to
>>> integrate with frameworks that aren't just about presentation or
>>> persistence; in Dan's book he sketches out an integration with
>>> [[camel.apache.org|Camel]; there are multiple opportunities here. We
>>> also hope to tap into expertise to help us refactor the framework
>>> components into JSR-299 beans. Again, we've had an expression of
>>> interest from the incubator mailing list along these lines.
>>>
>>> Sixth, it isn't finished. As has been pointed out to us, projects whose
>>> codebases are finished don't make for good project candidates. Isis,
>>> though, will probably never be truly finished. The hexagonal
>>> architecture, as we think of it, is about plugging in different
>>> presentation and persistence layers. We have several viewers that are in
>>> active development (including the Wicket, and a RESTful-based viewer),
>>> and object stores too (BerkleyDB, MongoDB, vanilla SQL). But there are
>>> lots of UI frameworks we haven't even started on, either Apache's own
>>> (eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, …)
>>> or external (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
>>> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
>>> Silverlight, …). The same is true for persistence technologies, both
>>> internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]],
>>> [[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase,
>>> iBATIS, ...) and external (eg neo4j, db4o,
>>> [[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3,
>>> JCloud … ). And… there are also lots of development tools that could be
>>> built, either IDE integrations, or into build tools such as Maven.
>>>
>>> In summary: we hope that incubation will allow us to develop Isis into a
>>> standards-based framework for building domain-driven apps, appealing
>>> both to its user community (who just want to use it "out-of-the-box")
>>> and to its contributor community (who want to quickly understand how it
>>> works and what is required to extend it).
>>>
>>> == Initial Source ==
>>> === 1. Combine the codebases ===
>>> Both the core Naked Objects framework and the sister projects reside in
>>> Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:
>>>
>>> * nakedobjects.sourceforge.net
>>> * wicketobjects.sourceforge.net
>>> * restfulobjects.sourceforge.net
>>> * jpaobjects.sourceforge.net
>>> * testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]],
>>> [[http://www.concordion.org/|Concordion]])
>>> * groovyobjects.sourceforge.net
>>>
>>> These will need to be moved into a single Subversion tree, hosted on
>>> Apache infrastructure.
>>>
>>> === 2. Rationalize the builds ===
>>> Both the NO codebase and the sister projects are built using Maven 2. It
>>> shouldn't be difficult to combine these into a single build.
>>>
>>> === 3. Standardize package names ===
>>> Naked Objects package names are currently:
>>>
>>> * org.nakedobjects.applib.* and org.nakedobjects.service.* for the
>>> applib and domain services
>>> * org.nakedobjects.core.* for the core
>>> * org.nakedobjects.plugins.xxx for each plugin
>>>
>>> These should move, respectively, to
>>>
>>> * org.apache.isis.application.*
>>> * org.apache.isis.core.* and
>>> * org.apache.isis.alternatives.xxx (we expect that plugins will become
>>>
>>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]]
>>> under JSR-299).
>>>
>>> The sister projects package names are currently:
>>>
>>> * org.starobjects.wicket.* (for wicket objects)
>>> * org.starobjects.restful.* (for restful objects)
>>>
>>> etc.
>>>
>>> Because these are all just plugins/alternatives, they should just move
>>> to org.apache.isis.alternatives.*.
>>>
>>> === 4. Move the version number down. ===
>>> To emphasize the fact that this is a new project not yet considered
>>> complete, we will move the number back down to < 1.0, eg v0.1. This will
>>> allow us to work on a number of releases, hopefully getting to 1.0 as
>>> and when we graduate from the incubator.
>>>
>>> === 5. Establish continuous integration ===
>>> The Naked Objects framework currently builds on its own Hudson server;
>>> we would move this over to run on Apache infrastructure.
>>>
>>> === 6. Rationalize documentation ===
>>> The documentation for the sister projects is reasonably up-to-date, but
>>> the documentation for Naked Objects needs rationalizing, aligning with
>>> the core component and the various plugins. This will help make the
>>> framework more digestible to new users/would-be committers; they can
>>> focus on the core, or a bit of the core (say, the metamodel), or work on
>>> just one plugin.
>>>
>>> === 7. Rationalize the Maven sites ===
>>> Related to above, we need to "tell the story better" so that would-be
>>> users can see what benefits using the framework will bring (and,
>>> conversely, what freedom they give up in adopting a framework).
>>>
>>> === 8. Review/copy over outstanding tickets. ===
>>> There are a number of tickets in the Naked Objects TRAC wiki. These
>>> should be either moved over, or fixed.
>>>
>>> == Initial Goals ==
>>> The following outlines some of the goals we have set ourselves during
>>> incubation. Of course, these may change as we proceed and learn more.
>>>
>>> * Prepare ground by defining the 3 area of Isis: Application; Framework;
>>> and Plugin.
>>> * Address (either fix or transfer) all tickets from Naked Objects TRAC
>>> wiki.
>>> * Ensure existing documentation (of which there is a reasonable amount)
>>> is correctly related to each project now that the documentation has been
>>> separated out.
>>> * v 0.1 - source code combination and rationalization (as per above).
>>> * v 0.2 - refactor components to JSR-299, while maintaining backwards
>>> compatibility for bootstrapping.
>>> * v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
>>> * v 0.4 - integrate with JMX for runtime management; provide profiling
>>> of client/server and webapps (eg serialization vs domain logic vs domain
>>> services vs object store timings).
>>> * v 0.5 - write contract tests for all major plugin APIs (object stores,
>>> authentication, authorization, remoting).
>>>
>>> We also have a number of overarching goals:
>>>
>>> * steadily improve the code coverage
>>> * clean up the APIs. Some of the code dates back to Java 1.1 (at one
>>> point in time the code was cross-compiled into J# code); so there is
>>> opportunity to use more generics and remove use of arrays
>>> * steadily reduce the amount of proprietary code, and the code size in
>>> general; use newer libraries such as google-collections more extensively.
>>>
>>> As well as the work going on to create the Isis project there are a
>>> number of components that are in the works, and that will be released as
>>> they are ready:
>>>
>>> * Scimpi web application release.
>>> * Introduce dynamic view design into the DnD viewer.
>>> * [[http://wicket.apache.org|Wicket]] viewer release.
>>> * NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]],
>>> [[http://www.mongodb.org/|MongoDB]] and
>>>
>>> [[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
>>>
>>> * SQL persistor release.
>>> * CLI viewer release.
>>> * Portal integration: Examine and implement support for compatible
>>> portals. Under consideration:
>>> [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal
>>> Server]].
>>>
>>> Whether these are part of incubation or not will depend on whether we
>>> feel we have reached a self-sustaining community (but it's more likely
>>> than not that they will be released during incubation). Equally, there
>>> may be other viewers/persistors using other technologies that might be
>>> implemented during incubation.
>>>
>>> == Current Status ==
>>> Naked Objects 4.0.0 was released at the end of 2009, broadly
>>> corresponding to the release of Dan's book.This is released into the
>>> Maven central repo, along with an application archetype for quick-start.
>>> The three sister projects mentioned in Dan's book (restful, tested, jpa)
>>> are at 1.0-beta-3, but not formally released into the Maven central
>>> repo. The remaining sister projects are in alpha status.
>>>
>>> The main committers for the codebases to date have been Robert Matthews
>>> and Dan Haywood. Both Rob and Dan work on the NOF core, and each also
>>> works independently (reflecting their individual interests) on their
>>> respective plugins. Much work was done on the core by both Rob and Dan
>>> leading up to the release of NOF 4.0.0, and we are now reasonably happy
>>> with it. Much work remains (see above) in the area of
>>> plugins/alternatives; there is work to complete and improve the existing
>>> ones and many opportunities to develop new ones.
>>>
>>> We readily support users on the NO forum (on
>>> [[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]])
>>> and also on the forum for Dan's book (on pragprog.com). As a consequence
>>> of Dan's book, a GWT-based viewer (non open source) has been developed
>>> separately, and we have provided support for this (and hope it will be
>>> contributed back to the framework in the future).
>>>
>>> Over the years we have received some patches for the framework, which we
>>> have incorporated, but not many. Part of the reason for this, we
>>> believe, is that until NOF 4.0.0 it had a monolithic architecture,
>>> making it difficult for would-be contributors to provide small patches.
>>> We think that NOF 4.0.0 improves in this area, but a move to JSR-299
>>> would be a major step forward to help bring up participation.
>>>
>>> == Community ==
>>> We recognize that the lack of a large (or at least, vocal) user
>>> community is the weakest part of our proposal. That said, we do have a
>>> steady trickle of queries on both the Naked Objects forum, and on the
>>> forum for Dan's book. Getting NOF 4.0.0 released has rekindled interest
>>> in at least one long-time user who is helping Rob to test one of the
>>> object store plugins, while we've also picked up commitment to help with
>>> this Apache proposal from a couple of people via the book forum.
>>>
>>> To help build up our community we intend to:
>>>
>>> * ensure that the website and documentation is first-rate (see initial
>>> goals, above)
>>> * make sure that the Isis code can be easily used and understood
>>> * court other open source projects with compatible technologies to work
>>> on integrations with Isis
>>> * write a series of articles for leading web journals, eg
>>> theserverside.com, javaworld.com, artima.com. We would want to point out
>>> that we were in the Apache Incubator, and actively looking for help
>>> * submit sessions to Devoxx and similar, Java-focused, conferences;
>>> again we'd trade on the Apache Incubator status.
>>>
>>> We also hope that some of the newer members of our community will help
>>> us identify what the roadblocks are to adoption, so that we can address
>>> them.
>>>
>>> == Core Developers ==
>>> The core developers are:
>>>
>>> * Robert Matthews, UK-based independent consultant. Original author of
>>> the Naked Objects framework, committer to the NOF core and primary
>>> developer of the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer,
>>> in-memory !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL
>>> !ObjectStore, !MongoDB ObjectStore). Until recently, worked for Naked
>>> Objects Group Ltd on the commercial .NET version. Is now independent and
>>> working on apps built using the open source Java version.
>>>
>>> * Dan Haywood, UK-based independent consultant. Contributor to the Naked
>>> Objects framework since 2005; took lead in much of the restructuring of
>>> the NO architecture for NOF 4.0.0. Also primary developer for sister
>>> projects plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA
>>> !ObjectStore, !TestedObjects "viewer", Groovy support). Part-time
>>> consultant/advisor to the Irish Government project (since 2004); also a
>>> trainer/consultant in agile, Java, TDD etc.
>>>
>>> Additional committers are:
>>>
>>> * Kevin Meyer, South Africa-based freelance developer and business
>>> analyst. Kevin has been working primarily in a testing role, both on the
>>> SQL Object Store with Rob and on the Wicket viewer with Dan. Kevin has
>>> recently started contributing fixes to both.
>>>
>>> * Dave Slaughter, US-based developer/consultant who is the Lead of the
>>> Software and Specialty Engineering group at SM&A. Dave has spent his
>>> career in the development of enterprise applications for companies such
>>> as Siemens, Sprint and Lockheed Martin. He has started a SWT viewer and
>>> has also started improving code coverage of the XML !ObjectStore.
>>>
>>> * Alexander Krasnukhin, a Swedish-based developer who has spent more
>>> than a year developing different applications on Naked Objects v3 and
>>> spent six months developing a closed-source GWT viewer for Naked Objects
>>> v4.0 for his former employer in Russia. Alexander is interested in
>>> developing a new viewer for Android.
>>>
>>> As a result of a correspondence on the incubator mailing list, we have
>>> also had interest from:
>>>
>>> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour
>>> has helped us with this proposal relating to JSR-299.
>>>
>>> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an
>>> interest in developing a Tapstry-based viewer.
>>>
>>> We also have had interest (off list) in developing a Vaadin viewer, and
>>> we know of a student masters project that has developed a (different)
>>> Android viewer for Naked Objects 4.0, which we're keen to incorporate if
>>> we can. We are also hoping that we might persuade Alexander's previous
>>> employer to donate their GWT viewer.
>>>
>>> == Alignment ==
>>> The current codebase makes heavy use of Apache projects, including:
>>> Maven, log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and
>>> Wicket.
>>>
>>> There is a particular opportunity to integrate nicely with both Wicket
>>> and Tapestry. Both Wicket and Tapestry are great way of building web
>>> UIs, but have little to say about the "back-end". Naked Objects,
>>> meanwhile, provides a full runtime environment with pluggable
>>> persistence layers, and exposes a metamodel to allow generic or
>>> customisable UIs to be built rapidly. The currently in-development
>>> !WicketObjects viewer brings Wickets and Naked Objects together, and (as
>>> noted above) there has been interest in writing a Tapestry viewer.
>>>
>>> Another ongoing integration project is the ongoing-development of an
>>> object store using MongoDB; the intent is to make this codebase a good
>>> basis for other similar object stores, such as Apache CouchDB.
>>>
>>> There are no Apache projects that we are aware of that compete with
>>> Naked Objects. At its heart, NO is (a) a metamodel, and (b) a container
>>> that acts as an abstraction over a persistence layer, using the identity
>>> map pattern.
>>>
>>> == Known Risks ==
>>> The biggest risk is that we fail to build a diverse community during
>>> incubation, opening up the possibility that the project could be orphaned.
>>>
>>> That said, there is little risk that either Rob or Dan will move onto
>>> other interests; we are both independent consultants and have the
>>> resources and inclination to continue working on the codebase. Indeed,
>>> with Rob now working only on the Java version (and not the .NET one) and
>>> Dan having finished his book, we have more resources now than at any
>>> time in the last couple of years.
>>>
>>> == Inexperience with Open Source ==
>>> Although Naked Objects is an open source project, the number of
>>> committers is so small then we cannot claim great experience with open
>>> source. Neither Rob nor Dan are committers to any other open source
>>> project, though both have submitted occasional patches to the various
>>> open source projects that we use.
>>>
>>> We are, however, comfortable users of open source projects. We also
>>> appreciate that there are lots of open source projects out there and
>>> that most developers will form an impression of a project without
>>> necessarily ever trying it out. This is one of the reasons why we feel
>>> we need to bring the two different codebases together, and create a
>>> standard message about what Apache Isis is about ("rapid development",
>>> "domain-driven design", "standard, extensible architecture",
>>> "customizable UIs").
>>>
>>> == Homogeneous Developers ==
>>> The two main developers, Rob and Dan, are based in the UK. Although we
>>> have collaborated on the framework over the years, we do not work for
>>> the same company and are independent.
>>>
>>> The other developers mentioned in this proposal are based in South
>>> Africa, US, Sweden, Egypt and Germany.
>>>
>>> == Reliance on Salaried Developers ==
>>> There are no salaried developers working on the projects. The main
>>> developers, Dan and Rob, are both independent consultants. We use
>>> non-billable time to work on the codebase, with the view to developing
>>> consultancy/services from it.
>>>
>>> == Documentation ==
>>> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard
>>> Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
>>> * Books:
>>> * Domain Driven Design using Naked Objects, Dan Haywood
>>> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
>>> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
>>> * full text available online at
>>> [[http://nakedobjects.org/book/|nakedobjects.org/book]]
>>> * [[http://nakedobjects.org|nakedobjects.org]] - current website
>>> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his
>>> book
>>> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's
>>> sister projects; references the various SF websites for the sister
>>> projects
>>>
>>> == Source and IP Submission Plan ==
>>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>>> Apache, while Dan is also happy to donate the various sister projects
>>> that he has written. Having a single legal entity - ASF - owning the
>>> relevant rights to all this software would be very desirable.
>>>
>>> == External Dependencies ==
>>> Other than the Apache dependencies, all other open source projects used
>>> all have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg
>>> Hamcrest, ASM), MPL (eg javassist) or similarly permissive licenses. We
>>> do also have a soft dependency on an LGPL-licensed library (Hibernate)
>>> but during migration would look to migrate to the Apache equivalent
>>> (OpenJPA).
>>>
>>> == Required Resources ==
>>> * Subversion
>>> * Jira
>>> * Hudson CI server
>>> * Wiki
>>> * Website space
>>>
>>> == Mailing Lists ==
>>> * isis-private
>>> * isis-dev
>>> * isis-commits
>>> * isis-user
>>>
>>> == Subversion Repository ==
>>> https://svn.apache.org/repos/asf/incubator/isis
>>>
>>> == Issue Tracking ==
>>> Jira; project known as 'isis'
>>>
>>> == Initial Committers ==
>>> * Robert Matthews
>>> * Dan Haywood
>>> * Kevin Meyer
>>> * Dave Slaughter
>>> * Alexander Krasnukhin
>>>
>>> == Affiliations ==
>>> Alexander is employed as a software developer by Zenterio AB. The other
>>> committers are independent consultants.
>>>
>>> == Champion ==
>>> [none yet]
>>>
>>> == Sponsors: Nominated Mentors ==
>>> * Vincent Massol
>>> * James Carman
>>> * [more required]
>>>
>>> == Sponsor ==
>>> Apache Incubator
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Benson Margulies <bi...@gmail.com>]

+1, binding.

On Thu, Aug 26, 2010 at 12:12 PM, Siegfried Goeschl
<si...@it20one.at> wrote:
> Hi Dan,
>
> +1 (non-binding)
>
> Cheers,
>
>
> Siegfried Goeschl
>
> On 24.08.10 19:12, Dan Haywood wrote:
>>
>> I'd like to formally propose a new project for the incubator, Apache
>> Isis. If accepted, Isis will combine the existing open source Naked
>> Objects framework with a collection of sister projects, providing an
>> extensible Java-based framework for rapidly developing domain-driven
>> applications.
>>
>> I floated the idea of Isis on this mailing list about a month or so ago,
>> and we got some positive feedback and a couple of expressions of
>> interest in contributing. Since then, we've put together a proposal
>> (also copied in below) onto the incubator wiki.
>>
>> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
>> The current codebase is at: http://nakedobjects.org, with sister
>> projects hosted at: http://starobjects.org
>>
>> We currently have two mentors, but require more, and we still need a
>> champion. I'm hoping that this post will generate some further interest
>> to develop the proposal further. All being well we hope to put this
>> proposal to a vote in a week or two's time.
>>
>> Thanks for reading, looking forward to your feedback.
>> Dan Haywood
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> = Isis Proposal =
>> The following presents the proposal for creating a new project within
>> the Apache Software Foundation called Isis.
>>
>> == Abstract ==
>> Isis will be an extensible standards-based framework to rapidly develop
>> and enterprise level deploy domain-driven (DDD) applications.
>>
>> == Proposal ==
>> The Isis project will bring together a collection of open source
>> projects that collectively support the rapid development of
>> domain-driven applications. The heart of Isis is the Naked Objects
>> Framework, an established open source project that has been around since
>> 2002. In addition, it will incorporate a number of sister projects that
>> build on Naked Objects' pluggable architecture and which extend the
>> reach of Naked Objects in several key areas.
>>
>> In addition, the project will be reorganising the existing projects to
>> logically separate out the components into
>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]
>> beans. We believe that the JSR-299 programming model is likely to become
>> widely used for enterprise Java applications; adopting it should make it
>> easier for new contributors to understand how the framework fits
>> together and therefore to develop their own extensions. In turn, we hope
>> this will further extend the reach of the framework to other
>> complementary open source frameworks (either within Apache or outside of
>> it).
>>
>> == Background ==
>> Naked Objects is an open source Java framework that was originally
>> developed to explore the idea of enterprise systems that treat the user
>> as a "problem solver, not a process follower". Conceived by Richard
>> Pawson, the first version of the framework was written by Robert
>> Matthews (2002). Richard and Rob also wrote a book, Naked Objects
>> (Wiley, 2002), to explain the idea.
>>
>> More generally, Naked Objects is an implementation of the naked objects
>> architectural pattern. In its purest form, "all" the developer has to do
>> is develop their domain model as pojos; Naked Objects then provides: a
>> object-oriented user interface by rendering those pojos; persistence by
>> extracting the content of the pojos; security by wrapping access to the
>> pojos; remoting by turning local calls into remote ones; and
>> localisation by adapting all the names used in the metamodel. All of
>> this is done reflectively at runtime so that the developer can
>> concentrate on the most important aspect - the application itself. You
>> can think of Naked Objects' OOUI generation as analogous to Hibernate
>> and other ORMs, but rather than reflecting the pojo into the persistence
>> layer, they are reflected into the presentation layer. A number of other
>> open source frameworks cite it as their inspiration, including
>> [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and
>> [[http://www.trailsframework.org|Trails]].
>>
>> Over this time Naked Objects has attracted a fair degree of attention
>> among the early adopter crowd, generally splitting opinion as either a
>> very good idea or a very bad one. A common misconception is that naked
>> objects is only appropriate for simple CRUD based applications. While
>> developing CRUD applications is indeed trivial, an important innovation
>> is that the UI generated by NO also renders the pojo's
>> commands/behaviors (we call them actions). Simply stated: any public
>> method that does not represent a property or collection is rendered so
>> it can be invoked, eg with a button, a menu item or a hyperlink. We
>> characterize entities with such behaviors as "behaviorally complete".
>> It's OO as your mother taught it to you.
>>
>> At the same time that we have been developing our ideas on the naked
>> objects, there has been a resurgent interest in object modelling at the
>> enterprise level, specifically as described by Eric Evans' book,
>> [[http://domaindrivendesign.org/books|Domain Driven Design]].
>> Recognizing that there's a lot of synergy between the two ideas, the NO
>> framework now uses DDD terminology, such as repository, domain service
>> and value.
>>
>> As mentioned in the proposal section, Isis will consist of both the
>> original NO framework, along with a number of sister projects. These
>> sister projects were written by Dan Haywood to support a book he wrote
>> about the framework, [[http://pragprog.com/titles/dhnako|Domain Driven
>> Design using Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of
>> these projects was to demonstrate the pluggable nature of the framework.
>>
>> Both Naked Objects and its sister projects are under the ASL v2 license.
>>
>> Not directly related to this proposal but worth mentioning: Naked
>> Objects has also been ported to the .NET platform, as a commercial
>> product. Richard Pawson, the originator of the naked objects pattern,
>> now devotes his energies to the [[http://nakedobjects.net|.NET version]]
>> and is no longer involved in the open source Java version. Conversely,
>> Rob Matthews, the originator of the framework and a co-author of this
>> proposal, now devotes his energies to the Java version, not the .NET one.
>>
>> == Rationale ==
>> We recognize that the key to open source projects long-term success is a
>> large user base, along with a goodly number of diverse active and
>> enthusiastic committers. Being brutally honest, we cannot claim to have
>> either. That said, we are not naive enough to think that entrance into
>> the Apache incubator will automatically bring us these things. Rather,
>> we believe it will give us a platform to more effectively publicize the
>> project so that it can succeed. It will also allow us to take advantage
>> of the collaborative environment that the Apache Software Foundation
>> provides. Attracting a diverse group of developers will also provide the
>> opportunity for significant advancements and improvements to the Isis
>> framework, making it more useful for more people.
>>
>> There are, then, several reasons for us wanting to contribute the
>> framework to Apache.
>>
>> First, it helps us legitimize the "naked objects" concept.
>> Notwithstanding the fact that the project has attracted its fair share
>> of nay-sayers, as its developers we remain convinced of its usefulness
>> and contribution to enterprise development in general. Most
>> significantly, (v2.0 of) Naked Objects was used to develop the online
>> application for benefits administration of pensions and other state
>> benefits for the Irish Government. This project went live in 2006, is
>> used by 1500+ users on a day-by-day basis, consists of an enterprise
>> domain model of approximately 500 entities, and pushes out a new release
>> each month. Richard and Dan remain consultants to this project; we would
>> dearly like others to reap the benefit of building enterprise
>> applications in this way.
>>
>> Second, and as already mentioned, it gives us a platform on which to
>> publicize. The Naked Objects framework did have its moment in the sun
>> about 5~6 years back, but, at that time, it was under a GPL license
>> rather than ASL v2. We were also solely focused in developing the
>> aforementioned benefits system, rather than building an open source
>> community. One could argue that we had an opportunity and we blew it; at
>> any rate what we hope is that Apache will give us an opportunity to
>> build up a new community. At Devoxx 2009 we ran an informal poll to get
>> opinions of Naked Objects, from "best thing since sliced bread", through
>> "fundamentally flawed", to "never heard of it". There were 5x as many
>> votes in "never heard of it" as there were in all of the other columns.
>> That can either be taken as very disappointing, or as an opportunity. We
>> prefer the latter interpretation.
>>
>> Third, by renaming the project to Isis, it gives us a chance to
>> reposition the framework. While the "naked objects" pattern is
>> important, we also want to emphasize domain-driven design. Alistair
>> Cockburn's hexagonal (or "ports and adapters") architecture is another
>> influence; the plugins that the NO framework supports (see
>> [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either
>> ports/adapters from the presentation layer, or ports/adapters to the
>> persistence layer. Furthermore, the newer UI viewers that we have been
>> developing allow the UI to be customized in various ways and to various
>> extents; so the pojos are not necessarily naked, they are lightly (or
>> heavily!) clad. And also, being blunt, that term "naked", while
>> attracting the "bleeding edge" guys, tends to be a turn-off for the
>> "early majority" who we now want to target.
>>
>> Fourth, it removes doubt over its direction. Currently the NO framework
>> is ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard
>> Pawson still the figurehead of the naked objects movement. As already
>> mentioned, NOGL's energy is in their commercial .NET product. They are
>> happy to donate the relevant rights to this software to Apache because
>> they recognise that the framework is already critically dependent upon
>> the open source community, so this is the best way to encourage greater
>> take up, and ensure its future. Changing the name of the Java version
>> also means it removes confusion in the market place as to what Naked
>> Objects framework is (ie a .NET product only). Meanwhile the rights to
>> the various sister projects that Dan has written would also be donated
>> to ASF. Having a single legal entity - ASF - owning rights for all of
>> this software would be very desirable; we think it might prompt others
>> to explore the framework.
>>
>> Fifth, the synergies with other Apache projects will help us meet our
>> ambition to make the framework easier to extend. There are two principle
>> extension points of the framework: viewers, and object stores. While we
>> do understand that it isn't a goal of Apache per se to create a
>> portfolio of frameworks, we hope that being part of the Apache family
>> might encourage members of these other communities to help us develop
>> new viewers or object stores. One of the sister projects provides a
>> customizable viewer that uses Wicket; since pre-announcing this proposal
>> on the incubator mailing list we've had one expression of interest to
>> develop a new viewer using Tapestry.
>>
>> The 'domain services' angle of DDD also means there are opportunities to
>> integrate with frameworks that aren't just about presentation or
>> persistence; in Dan's book he sketches out an integration with
>> [[camel.apache.org|Camel]; there are multiple opportunities here. We
>> also hope to tap into expertise to help us refactor the framework
>> components into JSR-299 beans. Again, we've had an expression of
>> interest from the incubator mailing list along these lines.
>>
>> Sixth, it isn't finished. As has been pointed out to us, projects whose
>> codebases are finished don't make for good project candidates. Isis,
>> though, will probably never be truly finished. The hexagonal
>> architecture, as we think of it, is about plugging in different
>> presentation and persistence layers. We have several viewers that are in
>> active development (including the Wicket, and a RESTful-based viewer),
>> and object stores too (BerkleyDB, MongoDB, vanilla SQL). But there are
>> lots of UI frameworks we haven't even started on, either Apache's own
>> (eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, …)
>> or external (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
>> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
>> Silverlight, …). The same is true for persistence technologies, both
>> internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]],
>> [[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase,
>> iBATIS, ...) and external (eg neo4j, db4o,
>> [[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3,
>> JCloud … ). And… there are also lots of development tools that could be
>> built, either IDE integrations, or into build tools such as Maven.
>>
>> In summary: we hope that incubation will allow us to develop Isis into a
>> standards-based framework for building domain-driven apps, appealing
>> both to its user community (who just want to use it "out-of-the-box")
>> and to its contributor community (who want to quickly understand how it
>> works and what is required to extend it).
>>
>> == Initial Source ==
>> === 1. Combine the codebases ===
>> Both the core Naked Objects framework and the sister projects reside in
>> Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:
>>
>> * nakedobjects.sourceforge.net
>> * wicketobjects.sourceforge.net
>> * restfulobjects.sourceforge.net
>> * jpaobjects.sourceforge.net
>> * testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]],
>> [[http://www.concordion.org/|Concordion]])
>> * groovyobjects.sourceforge.net
>>
>> These will need to be moved into a single Subversion tree, hosted on
>> Apache infrastructure.
>>
>> === 2. Rationalize the builds ===
>> Both the NO codebase and the sister projects are built using Maven 2. It
>> shouldn't be difficult to combine these into a single build.
>>
>> === 3. Standardize package names ===
>> Naked Objects package names are currently:
>>
>> * org.nakedobjects.applib.* and org.nakedobjects.service.* for the
>> applib and domain services
>> * org.nakedobjects.core.* for the core
>> * org.nakedobjects.plugins.xxx for each plugin
>>
>> These should move, respectively, to
>>
>> * org.apache.isis.application.*
>> * org.apache.isis.core.* and
>> * org.apache.isis.alternatives.xxx (we expect that plugins will become
>>
>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]]
>> under JSR-299).
>>
>> The sister projects package names are currently:
>>
>> * org.starobjects.wicket.* (for wicket objects)
>> * org.starobjects.restful.* (for restful objects)
>>
>> etc.
>>
>> Because these are all just plugins/alternatives, they should just move
>> to org.apache.isis.alternatives.*.
>>
>> === 4. Move the version number down. ===
>> To emphasize the fact that this is a new project not yet considered
>> complete, we will move the number back down to < 1.0, eg v0.1. This will
>> allow us to work on a number of releases, hopefully getting to 1.0 as
>> and when we graduate from the incubator.
>>
>> === 5. Establish continuous integration ===
>> The Naked Objects framework currently builds on its own Hudson server;
>> we would move this over to run on Apache infrastructure.
>>
>> === 6. Rationalize documentation ===
>> The documentation for the sister projects is reasonably up-to-date, but
>> the documentation for Naked Objects needs rationalizing, aligning with
>> the core component and the various plugins. This will help make the
>> framework more digestible to new users/would-be committers; they can
>> focus on the core, or a bit of the core (say, the metamodel), or work on
>> just one plugin.
>>
>> === 7. Rationalize the Maven sites ===
>> Related to above, we need to "tell the story better" so that would-be
>> users can see what benefits using the framework will bring (and,
>> conversely, what freedom they give up in adopting a framework).
>>
>> === 8. Review/copy over outstanding tickets. ===
>> There are a number of tickets in the Naked Objects TRAC wiki. These
>> should be either moved over, or fixed.
>>
>> == Initial Goals ==
>> The following outlines some of the goals we have set ourselves during
>> incubation. Of course, these may change as we proceed and learn more.
>>
>> * Prepare ground by defining the 3 area of Isis: Application; Framework;
>> and Plugin.
>> * Address (either fix or transfer) all tickets from Naked Objects TRAC
>> wiki.
>> * Ensure existing documentation (of which there is a reasonable amount)
>> is correctly related to each project now that the documentation has been
>> separated out.
>> * v 0.1 - source code combination and rationalization (as per above).
>> * v 0.2 - refactor components to JSR-299, while maintaining backwards
>> compatibility for bootstrapping.
>> * v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
>> * v 0.4 - integrate with JMX for runtime management; provide profiling
>> of client/server and webapps (eg serialization vs domain logic vs domain
>> services vs object store timings).
>> * v 0.5 - write contract tests for all major plugin APIs (object stores,
>> authentication, authorization, remoting).
>>
>> We also have a number of overarching goals:
>>
>> * steadily improve the code coverage
>> * clean up the APIs. Some of the code dates back to Java 1.1 (at one
>> point in time the code was cross-compiled into J# code); so there is
>> opportunity to use more generics and remove use of arrays
>> * steadily reduce the amount of proprietary code, and the code size in
>> general; use newer libraries such as google-collections more extensively.
>>
>> As well as the work going on to create the Isis project there are a
>> number of components that are in the works, and that will be released as
>> they are ready:
>>
>> * Scimpi web application release.
>> * Introduce dynamic view design into the DnD viewer.
>> * [[http://wicket.apache.org|Wicket]] viewer release.
>> * NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]],
>> [[http://www.mongodb.org/|MongoDB]] and
>>
>> [[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
>>
>> * SQL persistor release.
>> * CLI viewer release.
>> * Portal integration: Examine and implement support for compatible
>> portals. Under consideration:
>> [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal
>> Server]].
>>
>> Whether these are part of incubation or not will depend on whether we
>> feel we have reached a self-sustaining community (but it's more likely
>> than not that they will be released during incubation). Equally, there
>> may be other viewers/persistors using other technologies that might be
>> implemented during incubation.
>>
>> == Current Status ==
>> Naked Objects 4.0.0 was released at the end of 2009, broadly
>> corresponding to the release of Dan's book.This is released into the
>> Maven central repo, along with an application archetype for quick-start.
>> The three sister projects mentioned in Dan's book (restful, tested, jpa)
>> are at 1.0-beta-3, but not formally released into the Maven central
>> repo. The remaining sister projects are in alpha status.
>>
>> The main committers for the codebases to date have been Robert Matthews
>> and Dan Haywood. Both Rob and Dan work on the NOF core, and each also
>> works independently (reflecting their individual interests) on their
>> respective plugins. Much work was done on the core by both Rob and Dan
>> leading up to the release of NOF 4.0.0, and we are now reasonably happy
>> with it. Much work remains (see above) in the area of
>> plugins/alternatives; there is work to complete and improve the existing
>> ones and many opportunities to develop new ones.
>>
>> We readily support users on the NO forum (on
>> [[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]])
>> and also on the forum for Dan's book (on pragprog.com). As a consequence
>> of Dan's book, a GWT-based viewer (non open source) has been developed
>> separately, and we have provided support for this (and hope it will be
>> contributed back to the framework in the future).
>>
>> Over the years we have received some patches for the framework, which we
>> have incorporated, but not many. Part of the reason for this, we
>> believe, is that until NOF 4.0.0 it had a monolithic architecture,
>> making it difficult for would-be contributors to provide small patches.
>> We think that NOF 4.0.0 improves in this area, but a move to JSR-299
>> would be a major step forward to help bring up participation.
>>
>> == Community ==
>> We recognize that the lack of a large (or at least, vocal) user
>> community is the weakest part of our proposal. That said, we do have a
>> steady trickle of queries on both the Naked Objects forum, and on the
>> forum for Dan's book. Getting NOF 4.0.0 released has rekindled interest
>> in at least one long-time user who is helping Rob to test one of the
>> object store plugins, while we've also picked up commitment to help with
>> this Apache proposal from a couple of people via the book forum.
>>
>> To help build up our community we intend to:
>>
>> * ensure that the website and documentation is first-rate (see initial
>> goals, above)
>> * make sure that the Isis code can be easily used and understood
>> * court other open source projects with compatible technologies to work
>> on integrations with Isis
>> * write a series of articles for leading web journals, eg
>> theserverside.com, javaworld.com, artima.com. We would want to point out
>> that we were in the Apache Incubator, and actively looking for help
>> * submit sessions to Devoxx and similar, Java-focused, conferences;
>> again we'd trade on the Apache Incubator status.
>>
>> We also hope that some of the newer members of our community will help
>> us identify what the roadblocks are to adoption, so that we can address
>> them.
>>
>> == Core Developers ==
>> The core developers are:
>>
>> * Robert Matthews, UK-based independent consultant. Original author of
>> the Naked Objects framework, committer to the NOF core and primary
>> developer of the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer,
>> in-memory !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL
>> !ObjectStore, !MongoDB ObjectStore). Until recently, worked for Naked
>> Objects Group Ltd on the commercial .NET version. Is now independent and
>> working on apps built using the open source Java version.
>>
>> * Dan Haywood, UK-based independent consultant. Contributor to the Naked
>> Objects framework since 2005; took lead in much of the restructuring of
>> the NO architecture for NOF 4.0.0. Also primary developer for sister
>> projects plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA
>> !ObjectStore, !TestedObjects "viewer", Groovy support). Part-time
>> consultant/advisor to the Irish Government project (since 2004); also a
>> trainer/consultant in agile, Java, TDD etc.
>>
>> Additional committers are:
>>
>> * Kevin Meyer, South Africa-based freelance developer and business
>> analyst. Kevin has been working primarily in a testing role, both on the
>> SQL Object Store with Rob and on the Wicket viewer with Dan. Kevin has
>> recently started contributing fixes to both.
>>
>> * Dave Slaughter, US-based developer/consultant who is the Lead of the
>> Software and Specialty Engineering group at SM&A. Dave has spent his
>> career in the development of enterprise applications for companies such
>> as Siemens, Sprint and Lockheed Martin. He has started a SWT viewer and
>> has also started improving code coverage of the XML !ObjectStore.
>>
>> * Alexander Krasnukhin, a Swedish-based developer who has spent more
>> than a year developing different applications on Naked Objects v3 and
>> spent six months developing a closed-source GWT viewer for Naked Objects
>> v4.0 for his former employer in Russia. Alexander is interested in
>> developing a new viewer for Android.
>>
>> As a result of a correspondence on the incubator mailing list, we have
>> also had interest from:
>>
>> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour
>> has helped us with this proposal relating to JSR-299.
>>
>> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an
>> interest in developing a Tapstry-based viewer.
>>
>> We also have had interest (off list) in developing a Vaadin viewer, and
>> we know of a student masters project that has developed a (different)
>> Android viewer for Naked Objects 4.0, which we're keen to incorporate if
>> we can. We are also hoping that we might persuade Alexander's previous
>> employer to donate their GWT viewer.
>>
>> == Alignment ==
>> The current codebase makes heavy use of Apache projects, including:
>> Maven, log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and
>> Wicket.
>>
>> There is a particular opportunity to integrate nicely with both Wicket
>> and Tapestry. Both Wicket and Tapestry are great way of building web
>> UIs, but have little to say about the "back-end". Naked Objects,
>> meanwhile, provides a full runtime environment with pluggable
>> persistence layers, and exposes a metamodel to allow generic or
>> customisable UIs to be built rapidly. The currently in-development
>> !WicketObjects viewer brings Wickets and Naked Objects together, and (as
>> noted above) there has been interest in writing a Tapestry viewer.
>>
>> Another ongoing integration project is the ongoing-development of an
>> object store using MongoDB; the intent is to make this codebase a good
>> basis for other similar object stores, such as Apache CouchDB.
>>
>> There are no Apache projects that we are aware of that compete with
>> Naked Objects. At its heart, NO is (a) a metamodel, and (b) a container
>> that acts as an abstraction over a persistence layer, using the identity
>> map pattern.
>>
>> == Known Risks ==
>> The biggest risk is that we fail to build a diverse community during
>> incubation, opening up the possibility that the project could be orphaned.
>>
>> That said, there is little risk that either Rob or Dan will move onto
>> other interests; we are both independent consultants and have the
>> resources and inclination to continue working on the codebase. Indeed,
>> with Rob now working only on the Java version (and not the .NET one) and
>> Dan having finished his book, we have more resources now than at any
>> time in the last couple of years.
>>
>> == Inexperience with Open Source ==
>> Although Naked Objects is an open source project, the number of
>> committers is so small then we cannot claim great experience with open
>> source. Neither Rob nor Dan are committers to any other open source
>> project, though both have submitted occasional patches to the various
>> open source projects that we use.
>>
>> We are, however, comfortable users of open source projects. We also
>> appreciate that there are lots of open source projects out there and
>> that most developers will form an impression of a project without
>> necessarily ever trying it out. This is one of the reasons why we feel
>> we need to bring the two different codebases together, and create a
>> standard message about what Apache Isis is about ("rapid development",
>> "domain-driven design", "standard, extensible architecture",
>> "customizable UIs").
>>
>> == Homogeneous Developers ==
>> The two main developers, Rob and Dan, are based in the UK. Although we
>> have collaborated on the framework over the years, we do not work for
>> the same company and are independent.
>>
>> The other developers mentioned in this proposal are based in South
>> Africa, US, Sweden, Egypt and Germany.
>>
>> == Reliance on Salaried Developers ==
>> There are no salaried developers working on the projects. The main
>> developers, Dan and Rob, are both independent consultants. We use
>> non-billable time to work on the codebase, with the view to developing
>> consultancy/services from it.
>>
>> == Documentation ==
>> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard
>> Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
>> * Books:
>> * Domain Driven Design using Naked Objects, Dan Haywood
>> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
>> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
>> * full text available online at
>> [[http://nakedobjects.org/book/|nakedobjects.org/book]]
>> * [[http://nakedobjects.org|nakedobjects.org]] - current website
>> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his
>> book
>> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's
>> sister projects; references the various SF websites for the sister
>> projects
>>
>> == Source and IP Submission Plan ==
>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>> Apache, while Dan is also happy to donate the various sister projects
>> that he has written. Having a single legal entity - ASF - owning the
>> relevant rights to all this software would be very desirable.
>>
>> == External Dependencies ==
>> Other than the Apache dependencies, all other open source projects used
>> all have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg
>> Hamcrest, ASM), MPL (eg javassist) or similarly permissive licenses. We
>> do also have a soft dependency on an LGPL-licensed library (Hibernate)
>> but during migration would look to migrate to the Apache equivalent
>> (OpenJPA).
>>
>> == Required Resources ==
>> * Subversion
>> * Jira
>> * Hudson CI server
>> * Wiki
>> * Website space
>>
>> == Mailing Lists ==
>> * isis-private
>> * isis-dev
>> * isis-commits
>> * isis-user
>>
>> == Subversion Repository ==
>> https://svn.apache.org/repos/asf/incubator/isis
>>
>> == Issue Tracking ==
>> Jira; project known as 'isis'
>>
>> == Initial Committers ==
>> * Robert Matthews
>> * Dan Haywood
>> * Kevin Meyer
>> * Dave Slaughter
>> * Alexander Krasnukhin
>>
>> == Affiliations ==
>> Alexander is employed as a software developer by Zenterio AB. The other
>> committers are independent consultants.
>>
>> == Champion ==
>> [none yet]
>>
>> == Sponsors: Nominated Mentors ==
>> * Vincent Massol
>> * James Carman
>> * [more required]
>>
>> == Sponsor ==
>> Apache Incubator
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] Apache Isis

["Noel J. Bergman" <no...@devtech.com>]

> I'm not actually putting this to a vote, yet

I'm glad that you said that; votes would be marked as such.  :-)

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Apache Isis

[Dan Haywood <dk...@gmail.com>]

  Thanks for that, Siegfried.

I'm not actually putting this to a vote, yet, because we still need to 
find more mentors and a champion.  If haven't yet done any "cold 
calling" of possible would-be mentors, but if you have any suggestions 
of anyone who might have the bandwidth for either role, I'd very much 
appreciate it!

Thanks
Dan

~~~~~~~~~~~

On 26/08/2010 17:12, Siegfried Goeschl wrote:
> Hi Dan,
>
> +1 (non-binding)
>
> Cheers,
>
>
> Siegfried Goeschl
>
> On 24.08.10 19:12, Dan Haywood wrote:
>> I'd like to formally propose a new project for the incubator, Apache
>> Isis. If accepted, Isis will combine the existing open source Naked
>> Objects framework with a collection of sister projects, providing an
>> extensible Java-based framework for rapidly developing domain-driven
>> applications.
>>
>> I floated the idea of Isis on this mailing list about a month or so ago,
>> and we got some positive feedback and a couple of expressions of
>> interest in contributing. Since then, we've put together a proposal
>> (also copied in below) onto the incubator wiki.
>>
>> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
>> The current codebase is at: http://nakedobjects.org, with sister
>> projects hosted at: http://starobjects.org
>>
>> We currently have two mentors, but require more, and we still need a
>> champion. I'm hoping that this post will generate some further interest
>> to develop the proposal further. All being well we hope to put this
>> proposal to a vote in a week or two's time.
>>
>> Thanks for reading, looking forward to your feedback.
>> Dan Haywood
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> = Isis Proposal =
>> The following presents the proposal for creating a new project within
>> the Apache Software Foundation called Isis.
>>
>> == Abstract ==
>> Isis will be an extensible standards-based framework to rapidly develop
>> and enterprise level deploy domain-driven (DDD) applications.
>>
>> == Proposal ==
>> The Isis project will bring together a collection of open source
>> projects that collectively support the rapid development of
>> domain-driven applications. The heart of Isis is the Naked Objects
>> Framework, an established open source project that has been around since
>> 2002. In addition, it will incorporate a number of sister projects that
>> build on Naked Objects' pluggable architecture and which extend the
>> reach of Naked Objects in several key areas.
>>
>> In addition, the project will be reorganising the existing projects to
>> logically separate out the components into
>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]
>> beans. We believe that the JSR-299 programming model is likely to become
>> widely used for enterprise Java applications; adopting it should make it
>> easier for new contributors to understand how the framework fits
>> together and therefore to develop their own extensions. In turn, we hope
>> this will further extend the reach of the framework to other
>> complementary open source frameworks (either within Apache or outside of
>> it).
>>
>> == Background ==
>> Naked Objects is an open source Java framework that was originally
>> developed to explore the idea of enterprise systems that treat the user
>> as a "problem solver, not a process follower". Conceived by Richard
>> Pawson, the first version of the framework was written by Robert
>> Matthews (2002). Richard and Rob also wrote a book, Naked Objects
>> (Wiley, 2002), to explain the idea.
>>
>> More generally, Naked Objects is an implementation of the naked objects
>> architectural pattern. In its purest form, "all" the developer has to do
>> is develop their domain model as pojos; Naked Objects then provides: a
>> object-oriented user interface by rendering those pojos; persistence by
>> extracting the content of the pojos; security by wrapping access to the
>> pojos; remoting by turning local calls into remote ones; and
>> localisation by adapting all the names used in the metamodel. All of
>> this is done reflectively at runtime so that the developer can
>> concentrate on the most important aspect - the application itself. You
>> can think of Naked Objects' OOUI generation as analogous to Hibernate
>> and other ORMs, but rather than reflecting the pojo into the persistence
>> layer, they are reflected into the presentation layer. A number of other
>> open source frameworks cite it as their inspiration, including
>> [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and
>> [[http://www.trailsframework.org|Trails]].
>>
>> Over this time Naked Objects has attracted a fair degree of attention
>> among the early adopter crowd, generally splitting opinion as either a
>> very good idea or a very bad one. A common misconception is that naked
>> objects is only appropriate for simple CRUD based applications. While
>> developing CRUD applications is indeed trivial, an important innovation
>> is that the UI generated by NO also renders the pojo's
>> commands/behaviors (we call them actions). Simply stated: any public
>> method that does not represent a property or collection is rendered so
>> it can be invoked, eg with a button, a menu item or a hyperlink. We
>> characterize entities with such behaviors as "behaviorally complete".
>> It's OO as your mother taught it to you.
>>
>> At the same time that we have been developing our ideas on the naked
>> objects, there has been a resurgent interest in object modelling at the
>> enterprise level, specifically as described by Eric Evans' book,
>> [[http://domaindrivendesign.org/books|Domain Driven Design]].
>> Recognizing that there's a lot of synergy between the two ideas, the NO
>> framework now uses DDD terminology, such as repository, domain service
>> and value.
>>
>> As mentioned in the proposal section, Isis will consist of both the
>> original NO framework, along with a number of sister projects. These
>> sister projects were written by Dan Haywood to support a book he wrote
>> about the framework, [[http://pragprog.com/titles/dhnako|Domain Driven
>> Design using Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of
>> these projects was to demonstrate the pluggable nature of the framework.
>>
>> Both Naked Objects and its sister projects are under the ASL v2 license.
>>
>> Not directly related to this proposal but worth mentioning: Naked
>> Objects has also been ported to the .NET platform, as a commercial
>> product. Richard Pawson, the originator of the naked objects pattern,
>> now devotes his energies to the [[http://nakedobjects.net|.NET version]]
>> and is no longer involved in the open source Java version. Conversely,
>> Rob Matthews, the originator of the framework and a co-author of this
>> proposal, now devotes his energies to the Java version, not the .NET 
>> one.
>>
>> == Rationale ==
>> We recognize that the key to open source projects long-term success is a
>> large user base, along with a goodly number of diverse active and
>> enthusiastic committers. Being brutally honest, we cannot claim to have
>> either. That said, we are not naive enough to think that entrance into
>> the Apache incubator will automatically bring us these things. Rather,
>> we believe it will give us a platform to more effectively publicize the
>> project so that it can succeed. It will also allow us to take advantage
>> of the collaborative environment that the Apache Software Foundation
>> provides. Attracting a diverse group of developers will also provide the
>> opportunity for significant advancements and improvements to the Isis
>> framework, making it more useful for more people.
>>
>> There are, then, several reasons for us wanting to contribute the
>> framework to Apache.
>>
>> First, it helps us legitimize the "naked objects" concept.
>> Notwithstanding the fact that the project has attracted its fair share
>> of nay-sayers, as its developers we remain convinced of its usefulness
>> and contribution to enterprise development in general. Most
>> significantly, (v2.0 of) Naked Objects was used to develop the online
>> application for benefits administration of pensions and other state
>> benefits for the Irish Government. This project went live in 2006, is
>> used by 1500+ users on a day-by-day basis, consists of an enterprise
>> domain model of approximately 500 entities, and pushes out a new release
>> each month. Richard and Dan remain consultants to this project; we would
>> dearly like others to reap the benefit of building enterprise
>> applications in this way.
>>
>> Second, and as already mentioned, it gives us a platform on which to
>> publicize. The Naked Objects framework did have its moment in the sun
>> about 5~6 years back, but, at that time, it was under a GPL license
>> rather than ASL v2. We were also solely focused in developing the
>> aforementioned benefits system, rather than building an open source
>> community. One could argue that we had an opportunity and we blew it; at
>> any rate what we hope is that Apache will give us an opportunity to
>> build up a new community. At Devoxx 2009 we ran an informal poll to get
>> opinions of Naked Objects, from "best thing since sliced bread", through
>> "fundamentally flawed", to "never heard of it". There were 5x as many
>> votes in "never heard of it" as there were in all of the other columns.
>> That can either be taken as very disappointing, or as an opportunity. We
>> prefer the latter interpretation.
>>
>> Third, by renaming the project to Isis, it gives us a chance to
>> reposition the framework. While the "naked objects" pattern is
>> important, we also want to emphasize domain-driven design. Alistair
>> Cockburn's hexagonal (or "ports and adapters") architecture is another
>> influence; the plugins that the NO framework supports (see
>> [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either
>> ports/adapters from the presentation layer, or ports/adapters to the
>> persistence layer. Furthermore, the newer UI viewers that we have been
>> developing allow the UI to be customized in various ways and to various
>> extents; so the pojos are not necessarily naked, they are lightly (or
>> heavily!) clad. And also, being blunt, that term "naked", while
>> attracting the "bleeding edge" guys, tends to be a turn-off for the
>> "early majority" who we now want to target.
>>
>> Fourth, it removes doubt over its direction. Currently the NO framework
>> is ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard
>> Pawson still the figurehead of the naked objects movement. As already
>> mentioned, NOGL's energy is in their commercial .NET product. They are
>> happy to donate the relevant rights to this software to Apache because
>> they recognise that the framework is already critically dependent upon
>> the open source community, so this is the best way to encourage greater
>> take up, and ensure its future. Changing the name of the Java version
>> also means it removes confusion in the market place as to what Naked
>> Objects framework is (ie a .NET product only). Meanwhile the rights to
>> the various sister projects that Dan has written would also be donated
>> to ASF. Having a single legal entity - ASF - owning rights for all of
>> this software would be very desirable; we think it might prompt others
>> to explore the framework.
>>
>> Fifth, the synergies with other Apache projects will help us meet our
>> ambition to make the framework easier to extend. There are two principle
>> extension points of the framework: viewers, and object stores. While we
>> do understand that it isn't a goal of Apache per se to create a
>> portfolio of frameworks, we hope that being part of the Apache family
>> might encourage members of these other communities to help us develop
>> new viewers or object stores. One of the sister projects provides a
>> customizable viewer that uses Wicket; since pre-announcing this proposal
>> on the incubator mailing list we've had one expression of interest to
>> develop a new viewer using Tapestry.
>>
>> The 'domain services' angle of DDD also means there are opportunities to
>> integrate with frameworks that aren't just about presentation or
>> persistence; in Dan's book he sketches out an integration with
>> [[camel.apache.org|Camel]; there are multiple opportunities here. We
>> also hope to tap into expertise to help us refactor the framework
>> components into JSR-299 beans. Again, we've had an expression of
>> interest from the incubator mailing list along these lines.
>>
>> Sixth, it isn't finished. As has been pointed out to us, projects whose
>> codebases are finished don't make for good project candidates. Isis,
>> though, will probably never be truly finished. The hexagonal
>> architecture, as we think of it, is about plugging in different
>> presentation and persistence layers. We have several viewers that are in
>> active development (including the Wicket, and a RESTful-based viewer),
>> and object stores too (BerkleyDB, MongoDB, vanilla SQL). But there are
>> lots of UI frameworks we haven't even started on, either Apache's own
>> (eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, …)
>> or external (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
>> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
>> Silverlight, …). The same is true for persistence technologies, both
>> internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]],
>> [[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase,
>> iBATIS, ...) and external (eg neo4j, db4o,
>> [[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3,
>> JCloud … ). And… there are also lots of development tools that could be
>> built, either IDE integrations, or into build tools such as Maven.
>>
>> In summary: we hope that incubation will allow us to develop Isis into a
>> standards-based framework for building domain-driven apps, appealing
>> both to its user community (who just want to use it "out-of-the-box")
>> and to its contributor community (who want to quickly understand how it
>> works and what is required to extend it).
>>
>> == Initial Source ==
>> === 1. Combine the codebases ===
>> Both the core Naked Objects framework and the sister projects reside in
>> Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:
>>
>> * nakedobjects.sourceforge.net
>> * wicketobjects.sourceforge.net
>> * restfulobjects.sourceforge.net
>> * jpaobjects.sourceforge.net
>> * testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]],
>> [[http://www.concordion.org/|Concordion]])
>> * groovyobjects.sourceforge.net
>>
>> These will need to be moved into a single Subversion tree, hosted on
>> Apache infrastructure.
>>
>> === 2. Rationalize the builds ===
>> Both the NO codebase and the sister projects are built using Maven 2. It
>> shouldn't be difficult to combine these into a single build.
>>
>> === 3. Standardize package names ===
>> Naked Objects package names are currently:
>>
>> * org.nakedobjects.applib.* and org.nakedobjects.service.* for the
>> applib and domain services
>> * org.nakedobjects.core.* for the core
>> * org.nakedobjects.plugins.xxx for each plugin
>>
>> These should move, respectively, to
>>
>> * org.apache.isis.application.*
>> * org.apache.isis.core.* and
>> * org.apache.isis.alternatives.xxx (we expect that plugins will become
>> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]] 
>>
>> under JSR-299).
>>
>> The sister projects package names are currently:
>>
>> * org.starobjects.wicket.* (for wicket objects)
>> * org.starobjects.restful.* (for restful objects)
>>
>> etc.
>>
>> Because these are all just plugins/alternatives, they should just move
>> to org.apache.isis.alternatives.*.
>>
>> === 4. Move the version number down. ===
>> To emphasize the fact that this is a new project not yet considered
>> complete, we will move the number back down to < 1.0, eg v0.1. This will
>> allow us to work on a number of releases, hopefully getting to 1.0 as
>> and when we graduate from the incubator.
>>
>> === 5. Establish continuous integration ===
>> The Naked Objects framework currently builds on its own Hudson server;
>> we would move this over to run on Apache infrastructure.
>>
>> === 6. Rationalize documentation ===
>> The documentation for the sister projects is reasonably up-to-date, but
>> the documentation for Naked Objects needs rationalizing, aligning with
>> the core component and the various plugins. This will help make the
>> framework more digestible to new users/would-be committers; they can
>> focus on the core, or a bit of the core (say, the metamodel), or work on
>> just one plugin.
>>
>> === 7. Rationalize the Maven sites ===
>> Related to above, we need to "tell the story better" so that would-be
>> users can see what benefits using the framework will bring (and,
>> conversely, what freedom they give up in adopting a framework).
>>
>> === 8. Review/copy over outstanding tickets. ===
>> There are a number of tickets in the Naked Objects TRAC wiki. These
>> should be either moved over, or fixed.
>>
>> == Initial Goals ==
>> The following outlines some of the goals we have set ourselves during
>> incubation. Of course, these may change as we proceed and learn more.
>>
>> * Prepare ground by defining the 3 area of Isis: Application; Framework;
>> and Plugin.
>> * Address (either fix or transfer) all tickets from Naked Objects TRAC
>> wiki.
>> * Ensure existing documentation (of which there is a reasonable amount)
>> is correctly related to each project now that the documentation has been
>> separated out.
>> * v 0.1 - source code combination and rationalization (as per above).
>> * v 0.2 - refactor components to JSR-299, while maintaining backwards
>> compatibility for bootstrapping.
>> * v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
>> * v 0.4 - integrate with JMX for runtime management; provide profiling
>> of client/server and webapps (eg serialization vs domain logic vs domain
>> services vs object store timings).
>> * v 0.5 - write contract tests for all major plugin APIs (object stores,
>> authentication, authorization, remoting).
>>
>> We also have a number of overarching goals:
>>
>> * steadily improve the code coverage
>> * clean up the APIs. Some of the code dates back to Java 1.1 (at one
>> point in time the code was cross-compiled into J# code); so there is
>> opportunity to use more generics and remove use of arrays
>> * steadily reduce the amount of proprietary code, and the code size in
>> general; use newer libraries such as google-collections more 
>> extensively.
>>
>> As well as the work going on to create the Isis project there are a
>> number of components that are in the works, and that will be released as
>> they are ready:
>>
>> * Scimpi web application release.
>> * Introduce dynamic view design into the DnD viewer.
>> * [[http://wicket.apache.org|Wicket]] viewer release.
>> * NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]],
>> [[http://www.mongodb.org/|MongoDB]] and
>> [[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]). 
>>
>>
>> * SQL persistor release.
>> * CLI viewer release.
>> * Portal integration: Examine and implement support for compatible
>> portals. Under consideration:
>> [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal
>> Server]].
>>
>> Whether these are part of incubation or not will depend on whether we
>> feel we have reached a self-sustaining community (but it's more likely
>> than not that they will be released during incubation). Equally, there
>> may be other viewers/persistors using other technologies that might be
>> implemented during incubation.
>>
>> == Current Status ==
>> Naked Objects 4.0.0 was released at the end of 2009, broadly
>> corresponding to the release of Dan's book.This is released into the
>> Maven central repo, along with an application archetype for quick-start.
>> The three sister projects mentioned in Dan's book (restful, tested, jpa)
>> are at 1.0-beta-3, but not formally released into the Maven central
>> repo. The remaining sister projects are in alpha status.
>>
>> The main committers for the codebases to date have been Robert Matthews
>> and Dan Haywood. Both Rob and Dan work on the NOF core, and each also
>> works independently (reflecting their individual interests) on their
>> respective plugins. Much work was done on the core by both Rob and Dan
>> leading up to the release of NOF 4.0.0, and we are now reasonably happy
>> with it. Much work remains (see above) in the area of
>> plugins/alternatives; there is work to complete and improve the existing
>> ones and many opportunities to develop new ones.
>>
>> We readily support users on the NO forum (on
>> [[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]])
>> and also on the forum for Dan's book (on pragprog.com). As a consequence
>> of Dan's book, a GWT-based viewer (non open source) has been developed
>> separately, and we have provided support for this (and hope it will be
>> contributed back to the framework in the future).
>>
>> Over the years we have received some patches for the framework, which we
>> have incorporated, but not many. Part of the reason for this, we
>> believe, is that until NOF 4.0.0 it had a monolithic architecture,
>> making it difficult for would-be contributors to provide small patches.
>> We think that NOF 4.0.0 improves in this area, but a move to JSR-299
>> would be a major step forward to help bring up participation.
>>
>> == Community ==
>> We recognize that the lack of a large (or at least, vocal) user
>> community is the weakest part of our proposal. That said, we do have a
>> steady trickle of queries on both the Naked Objects forum, and on the
>> forum for Dan's book. Getting NOF 4.0.0 released has rekindled interest
>> in at least one long-time user who is helping Rob to test one of the
>> object store plugins, while we've also picked up commitment to help with
>> this Apache proposal from a couple of people via the book forum.
>>
>> To help build up our community we intend to:
>>
>> * ensure that the website and documentation is first-rate (see initial
>> goals, above)
>> * make sure that the Isis code can be easily used and understood
>> * court other open source projects with compatible technologies to work
>> on integrations with Isis
>> * write a series of articles for leading web journals, eg
>> theserverside.com, javaworld.com, artima.com. We would want to point out
>> that we were in the Apache Incubator, and actively looking for help
>> * submit sessions to Devoxx and similar, Java-focused, conferences;
>> again we'd trade on the Apache Incubator status.
>>
>> We also hope that some of the newer members of our community will help
>> us identify what the roadblocks are to adoption, so that we can address
>> them.
>>
>> == Core Developers ==
>> The core developers are:
>>
>> * Robert Matthews, UK-based independent consultant. Original author of
>> the Naked Objects framework, committer to the NOF core and primary
>> developer of the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer,
>> in-memory !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL
>> !ObjectStore, !MongoDB ObjectStore). Until recently, worked for Naked
>> Objects Group Ltd on the commercial .NET version. Is now independent and
>> working on apps built using the open source Java version.
>>
>> * Dan Haywood, UK-based independent consultant. Contributor to the Naked
>> Objects framework since 2005; took lead in much of the restructuring of
>> the NO architecture for NOF 4.0.0. Also primary developer for sister
>> projects plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA
>> !ObjectStore, !TestedObjects "viewer", Groovy support). Part-time
>> consultant/advisor to the Irish Government project (since 2004); also a
>> trainer/consultant in agile, Java, TDD etc.
>>
>> Additional committers are:
>>
>> * Kevin Meyer, South Africa-based freelance developer and business
>> analyst. Kevin has been working primarily in a testing role, both on the
>> SQL Object Store with Rob and on the Wicket viewer with Dan. Kevin has
>> recently started contributing fixes to both.
>>
>> * Dave Slaughter, US-based developer/consultant who is the Lead of the
>> Software and Specialty Engineering group at SM&A. Dave has spent his
>> career in the development of enterprise applications for companies such
>> as Siemens, Sprint and Lockheed Martin. He has started a SWT viewer and
>> has also started improving code coverage of the XML !ObjectStore.
>>
>> * Alexander Krasnukhin, a Swedish-based developer who has spent more
>> than a year developing different applications on Naked Objects v3 and
>> spent six months developing a closed-source GWT viewer for Naked Objects
>> v4.0 for his former employer in Russia. Alexander is interested in
>> developing a new viewer for Android.
>>
>> As a result of a correspondence on the incubator mailing list, we have
>> also had interest from:
>>
>> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour
>> has helped us with this proposal relating to JSR-299.
>>
>> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an
>> interest in developing a Tapstry-based viewer.
>>
>> We also have had interest (off list) in developing a Vaadin viewer, and
>> we know of a student masters project that has developed a (different)
>> Android viewer for Naked Objects 4.0, which we're keen to incorporate if
>> we can. We are also hoping that we might persuade Alexander's previous
>> employer to donate their GWT viewer.
>>
>> == Alignment ==
>> The current codebase makes heavy use of Apache projects, including:
>> Maven, log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and
>> Wicket.
>>
>> There is a particular opportunity to integrate nicely with both Wicket
>> and Tapestry. Both Wicket and Tapestry are great way of building web
>> UIs, but have little to say about the "back-end". Naked Objects,
>> meanwhile, provides a full runtime environment with pluggable
>> persistence layers, and exposes a metamodel to allow generic or
>> customisable UIs to be built rapidly. The currently in-development
>> !WicketObjects viewer brings Wickets and Naked Objects together, and (as
>> noted above) there has been interest in writing a Tapestry viewer.
>>
>> Another ongoing integration project is the ongoing-development of an
>> object store using MongoDB; the intent is to make this codebase a good
>> basis for other similar object stores, such as Apache CouchDB.
>>
>> There are no Apache projects that we are aware of that compete with
>> Naked Objects. At its heart, NO is (a) a metamodel, and (b) a container
>> that acts as an abstraction over a persistence layer, using the identity
>> map pattern.
>>
>> == Known Risks ==
>> The biggest risk is that we fail to build a diverse community during
>> incubation, opening up the possibility that the project could be 
>> orphaned.
>>
>> That said, there is little risk that either Rob or Dan will move onto
>> other interests; we are both independent consultants and have the
>> resources and inclination to continue working on the codebase. Indeed,
>> with Rob now working only on the Java version (and not the .NET one) and
>> Dan having finished his book, we have more resources now than at any
>> time in the last couple of years.
>>
>> == Inexperience with Open Source ==
>> Although Naked Objects is an open source project, the number of
>> committers is so small then we cannot claim great experience with open
>> source. Neither Rob nor Dan are committers to any other open source
>> project, though both have submitted occasional patches to the various
>> open source projects that we use.
>>
>> We are, however, comfortable users of open source projects. We also
>> appreciate that there are lots of open source projects out there and
>> that most developers will form an impression of a project without
>> necessarily ever trying it out. This is one of the reasons why we feel
>> we need to bring the two different codebases together, and create a
>> standard message about what Apache Isis is about ("rapid development",
>> "domain-driven design", "standard, extensible architecture",
>> "customizable UIs").
>>
>> == Homogeneous Developers ==
>> The two main developers, Rob and Dan, are based in the UK. Although we
>> have collaborated on the framework over the years, we do not work for
>> the same company and are independent.
>>
>> The other developers mentioned in this proposal are based in South
>> Africa, US, Sweden, Egypt and Germany.
>>
>> == Reliance on Salaried Developers ==
>> There are no salaried developers working on the projects. The main
>> developers, Dan and Rob, are both independent consultants. We use
>> non-billable time to work on the codebase, with the view to developing
>> consultancy/services from it.
>>
>> == Documentation ==
>> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard
>> Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
>> * Books:
>> * Domain Driven Design using Naked Objects, Dan Haywood
>> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
>> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
>> * full text available online at
>> [[http://nakedobjects.org/book/|nakedobjects.org/book]]
>> * [[http://nakedobjects.org|nakedobjects.org]] - current website
>> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his
>> book
>> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's
>> sister projects; references the various SF websites for the sister 
>> projects
>>
>> == Source and IP Submission Plan ==
>> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
>> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
>> Apache, while Dan is also happy to donate the various sister projects
>> that he has written. Having a single legal entity - ASF - owning the
>> relevant rights to all this software would be very desirable.
>>
>> == External Dependencies ==
>> Other than the Apache dependencies, all other open source projects used
>> all have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg
>> Hamcrest, ASM), MPL (eg javassist) or similarly permissive licenses. We
>> do also have a soft dependency on an LGPL-licensed library (Hibernate)
>> but during migration would look to migrate to the Apache equivalent
>> (OpenJPA).
>>
>> == Required Resources ==
>> * Subversion
>> * Jira
>> * Hudson CI server
>> * Wiki
>> * Website space
>>
>> == Mailing Lists ==
>> * isis-private
>> * isis-dev
>> * isis-commits
>> * isis-user
>>
>> == Subversion Repository ==
>> https://svn.apache.org/repos/asf/incubator/isis
>>
>> == Issue Tracking ==
>> Jira; project known as 'isis'
>>
>> == Initial Committers ==
>> * Robert Matthews
>> * Dan Haywood
>> * Kevin Meyer
>> * Dave Slaughter
>> * Alexander Krasnukhin
>>
>> == Affiliations ==
>> Alexander is employed as a software developer by Zenterio AB. The other
>> committers are independent consultants.
>>
>> == Champion ==
>> [none yet]
>>
>> == Sponsors: Nominated Mentors ==
>> * Vincent Massol
>> * James Carman
>> * [more required]
>>
>> == Sponsor ==
>> Apache Incubator
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [PROPOSAL] Apache Isis

[Siegfried Goeschl <si...@it20one.at>]

Hi Dan,

+1 (non-binding)

Cheers,


Siegfried Goeschl

On 24.08.10 19:12, Dan Haywood wrote:
> I'd like to formally propose a new project for the incubator, Apache
> Isis. If accepted, Isis will combine the existing open source Naked
> Objects framework with a collection of sister projects, providing an
> extensible Java-based framework for rapidly developing domain-driven
> applications.
>
> I floated the idea of Isis on this mailing list about a month or so ago,
> and we got some positive feedback and a couple of expressions of
> interest in contributing. Since then, we've put together a proposal
> (also copied in below) onto the incubator wiki.
>
> The proposal is at: http://wiki.apache.org/incubator/IsisProposal.
> The current codebase is at: http://nakedobjects.org, with sister
> projects hosted at: http://starobjects.org
>
> We currently have two mentors, but require more, and we still need a
> champion. I'm hoping that this post will generate some further interest
> to develop the proposal further. All being well we hope to put this
> proposal to a vote in a week or two's time.
>
> Thanks for reading, looking forward to your feedback.
> Dan Haywood
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> = Isis Proposal =
> The following presents the proposal for creating a new project within
> the Apache Software Foundation called Isis.
>
> == Abstract ==
> Isis will be an extensible standards-based framework to rapidly develop
> and enterprise level deploy domain-driven (DDD) applications.
>
> == Proposal ==
> The Isis project will bring together a collection of open source
> projects that collectively support the rapid development of
> domain-driven applications. The heart of Isis is the Naked Objects
> Framework, an established open source project that has been around since
> 2002. In addition, it will incorporate a number of sister projects that
> build on Naked Objects' pluggable architecture and which extend the
> reach of Naked Objects in several key areas.
>
> In addition, the project will be reorganising the existing projects to
> logically separate out the components into
> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/|JSR-299]]
> beans. We believe that the JSR-299 programming model is likely to become
> widely used for enterprise Java applications; adopting it should make it
> easier for new contributors to understand how the framework fits
> together and therefore to develop their own extensions. In turn, we hope
> this will further extend the reach of the framework to other
> complementary open source frameworks (either within Apache or outside of
> it).
>
> == Background ==
> Naked Objects is an open source Java framework that was originally
> developed to explore the idea of enterprise systems that treat the user
> as a "problem solver, not a process follower". Conceived by Richard
> Pawson, the first version of the framework was written by Robert
> Matthews (2002). Richard and Rob also wrote a book, Naked Objects
> (Wiley, 2002), to explain the idea.
>
> More generally, Naked Objects is an implementation of the naked objects
> architectural pattern. In its purest form, "all" the developer has to do
> is develop their domain model as pojos; Naked Objects then provides: a
> object-oriented user interface by rendering those pojos; persistence by
> extracting the content of the pojos; security by wrapping access to the
> pojos; remoting by turning local calls into remote ones; and
> localisation by adapting all the names used in the metamodel. All of
> this is done reflectively at runtime so that the developer can
> concentrate on the most important aspect - the application itself. You
> can think of Naked Objects' OOUI generation as analogous to Hibernate
> and other ORMs, but rather than reflecting the pojo into the persistence
> layer, they are reflected into the presentation layer. A number of other
> open source frameworks cite it as their inspiration, including
> [[http://jmatter.org|JMatter]], [[http://openxava.org|OpenXava]], and
> [[http://www.trailsframework.org|Trails]].
>
> Over this time Naked Objects has attracted a fair degree of attention
> among the early adopter crowd, generally splitting opinion as either a
> very good idea or a very bad one. A common misconception is that naked
> objects is only appropriate for simple CRUD based applications. While
> developing CRUD applications is indeed trivial, an important innovation
> is that the UI generated by NO also renders the pojo's
> commands/behaviors (we call them actions). Simply stated: any public
> method that does not represent a property or collection is rendered so
> it can be invoked, eg with a button, a menu item or a hyperlink. We
> characterize entities with such behaviors as "behaviorally complete".
> It's OO as your mother taught it to you.
>
> At the same time that we have been developing our ideas on the naked
> objects, there has been a resurgent interest in object modelling at the
> enterprise level, specifically as described by Eric Evans' book,
> [[http://domaindrivendesign.org/books|Domain Driven Design]].
> Recognizing that there's a lot of synergy between the two ideas, the NO
> framework now uses DDD terminology, such as repository, domain service
> and value.
>
> As mentioned in the proposal section, Isis will consist of both the
> original NO framework, along with a number of sister projects. These
> sister projects were written by Dan Haywood to support a book he wrote
> about the framework, [[http://pragprog.com/titles/dhnako|Domain Driven
> Design using Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of
> these projects was to demonstrate the pluggable nature of the framework.
>
> Both Naked Objects and its sister projects are under the ASL v2 license.
>
> Not directly related to this proposal but worth mentioning: Naked
> Objects has also been ported to the .NET platform, as a commercial
> product. Richard Pawson, the originator of the naked objects pattern,
> now devotes his energies to the [[http://nakedobjects.net|.NET version]]
> and is no longer involved in the open source Java version. Conversely,
> Rob Matthews, the originator of the framework and a co-author of this
> proposal, now devotes his energies to the Java version, not the .NET one.
>
> == Rationale ==
> We recognize that the key to open source projects long-term success is a
> large user base, along with a goodly number of diverse active and
> enthusiastic committers. Being brutally honest, we cannot claim to have
> either. That said, we are not naive enough to think that entrance into
> the Apache incubator will automatically bring us these things. Rather,
> we believe it will give us a platform to more effectively publicize the
> project so that it can succeed. It will also allow us to take advantage
> of the collaborative environment that the Apache Software Foundation
> provides. Attracting a diverse group of developers will also provide the
> opportunity for significant advancements and improvements to the Isis
> framework, making it more useful for more people.
>
> There are, then, several reasons for us wanting to contribute the
> framework to Apache.
>
> First, it helps us legitimize the "naked objects" concept.
> Notwithstanding the fact that the project has attracted its fair share
> of nay-sayers, as its developers we remain convinced of its usefulness
> and contribution to enterprise development in general. Most
> significantly, (v2.0 of) Naked Objects was used to develop the online
> application for benefits administration of pensions and other state
> benefits for the Irish Government. This project went live in 2006, is
> used by 1500+ users on a day-by-day basis, consists of an enterprise
> domain model of approximately 500 entities, and pushes out a new release
> each month. Richard and Dan remain consultants to this project; we would
> dearly like others to reap the benefit of building enterprise
> applications in this way.
>
> Second, and as already mentioned, it gives us a platform on which to
> publicize. The Naked Objects framework did have its moment in the sun
> about 5~6 years back, but, at that time, it was under a GPL license
> rather than ASL v2. We were also solely focused in developing the
> aforementioned benefits system, rather than building an open source
> community. One could argue that we had an opportunity and we blew it; at
> any rate what we hope is that Apache will give us an opportunity to
> build up a new community. At Devoxx 2009 we ran an informal poll to get
> opinions of Naked Objects, from "best thing since sliced bread", through
> "fundamentally flawed", to "never heard of it". There were 5x as many
> votes in "never heard of it" as there were in all of the other columns.
> That can either be taken as very disappointing, or as an opportunity. We
> prefer the latter interpretation.
>
> Third, by renaming the project to Isis, it gives us a chance to
> reposition the framework. While the "naked objects" pattern is
> important, we also want to emphasize domain-driven design. Alistair
> Cockburn's hexagonal (or "ports and adapters") architecture is another
> influence; the plugins that the NO framework supports (see
> [[http://nakedobjects.org/plugins|nakedobjects.org/plugins]]) are either
> ports/adapters from the presentation layer, or ports/adapters to the
> persistence layer. Furthermore, the newer UI viewers that we have been
> developing allow the UI to be customized in various ways and to various
> extents; so the pojos are not necessarily naked, they are lightly (or
> heavily!) clad. And also, being blunt, that term "naked", while
> attracting the "bleeding edge" guys, tends to be a turn-off for the
> "early majority" who we now want to target.
>
> Fourth, it removes doubt over its direction. Currently the NO framework
> is ASLv2 but copyright Naked Objects Group Ltd (NOGL), with Richard
> Pawson still the figurehead of the naked objects movement. As already
> mentioned, NOGL's energy is in their commercial .NET product. They are
> happy to donate the relevant rights to this software to Apache because
> they recognise that the framework is already critically dependent upon
> the open source community, so this is the best way to encourage greater
> take up, and ensure its future. Changing the name of the Java version
> also means it removes confusion in the market place as to what Naked
> Objects framework is (ie a .NET product only). Meanwhile the rights to
> the various sister projects that Dan has written would also be donated
> to ASF. Having a single legal entity - ASF - owning rights for all of
> this software would be very desirable; we think it might prompt others
> to explore the framework.
>
> Fifth, the synergies with other Apache projects will help us meet our
> ambition to make the framework easier to extend. There are two principle
> extension points of the framework: viewers, and object stores. While we
> do understand that it isn't a goal of Apache per se to create a
> portfolio of frameworks, we hope that being part of the Apache family
> might encourage members of these other communities to help us develop
> new viewers or object stores. One of the sister projects provides a
> customizable viewer that uses Wicket; since pre-announcing this proposal
> on the incubator mailing list we've had one expression of interest to
> develop a new viewer using Tapestry.
>
> The 'domain services' angle of DDD also means there are opportunities to
> integrate with frameworks that aren't just about presentation or
> persistence; in Dan's book he sketches out an integration with
> [[camel.apache.org|Camel]; there are multiple opportunities here. We
> also hope to tap into expertise to help us refactor the framework
> components into JSR-299 beans. Again, we've had an expression of
> interest from the incubator mailing list along these lines.
>
> Sixth, it isn't finished. As has been pointed out to us, projects whose
> codebases are finished don't make for good project candidates. Isis,
> though, will probably never be truly finished. The hexagonal
> architecture, as we think of it, is about plugging in different
> presentation and persistence layers. We have several viewers that are in
> active development (including the Wicket, and a RESTful-based viewer),
> and object stores too (BerkleyDB, MongoDB, vanilla SQL). But there are
> lots of UI frameworks we haven't even started on, either Apache's own
> (eg Click, Tapestry, [[http://myfaces.apache.org/|MyFaces]], Pivot, …)
> or external (eg [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
> Silverlight, …). The same is true for persistence technologies, both
> internal to Apache (eg [[http://couchdb.apache.org/|CouchDB]],
> [[http://openjpa.apache.org|OpenJPA]], Cassandra, Cayenne, HBase,
> iBATIS, ...) and external (eg neo4j, db4o,
> [[http://labs.google.com/papers/bigtable.html|BigTable]], Amazon S3,
> JCloud … ). And… there are also lots of development tools that could be
> built, either IDE integrations, or into build tools such as Maven.
>
> In summary: we hope that incubation will allow us to develop Isis into a
> standards-based framework for building domain-driven apps, appealing
> both to its user community (who just want to use it "out-of-the-box")
> and to its contributor community (who want to quickly understand how it
> works and what is required to extend it).
>
> == Initial Source ==
> === 1. Combine the codebases ===
> Both the core Naked Objects framework and the sister projects reside in
> Subversion trees, hosted on [[http://sourceforge.net|SourceForge]]:
>
> * nakedobjects.sourceforge.net
> * wicketobjects.sourceforge.net
> * restfulobjects.sourceforge.net
> * jpaobjects.sourceforge.net
> * testedobjects.sourceforge.net ([[http://fitnesse.org/|FitNesse]],
> [[http://www.concordion.org/|Concordion]])
> * groovyobjects.sourceforge.net
>
> These will need to be moved into a single Subversion tree, hosted on
> Apache infrastructure.
>
> === 2. Rationalize the builds ===
> Both the NO codebase and the sister projects are built using Maven 2. It
> shouldn't be difficult to combine these into a single build.
>
> === 3. Standardize package names ===
> Naked Objects package names are currently:
>
> * org.nakedobjects.applib.* and org.nakedobjects.service.* for the
> applib and domain services
> * org.nakedobjects.core.* for the core
> * org.nakedobjects.plugins.xxx for each plugin
>
> These should move, respectively, to
>
> * org.apache.isis.application.*
> * org.apache.isis.core.* and
> * org.apache.isis.alternatives.xxx (we expect that plugins will become
> [[http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives|alternatives]]
> under JSR-299).
>
> The sister projects package names are currently:
>
> * org.starobjects.wicket.* (for wicket objects)
> * org.starobjects.restful.* (for restful objects)
>
> etc.
>
> Because these are all just plugins/alternatives, they should just move
> to org.apache.isis.alternatives.*.
>
> === 4. Move the version number down. ===
> To emphasize the fact that this is a new project not yet considered
> complete, we will move the number back down to < 1.0, eg v0.1. This will
> allow us to work on a number of releases, hopefully getting to 1.0 as
> and when we graduate from the incubator.
>
> === 5. Establish continuous integration ===
> The Naked Objects framework currently builds on its own Hudson server;
> we would move this over to run on Apache infrastructure.
>
> === 6. Rationalize documentation ===
> The documentation for the sister projects is reasonably up-to-date, but
> the documentation for Naked Objects needs rationalizing, aligning with
> the core component and the various plugins. This will help make the
> framework more digestible to new users/would-be committers; they can
> focus on the core, or a bit of the core (say, the metamodel), or work on
> just one plugin.
>
> === 7. Rationalize the Maven sites ===
> Related to above, we need to "tell the story better" so that would-be
> users can see what benefits using the framework will bring (and,
> conversely, what freedom they give up in adopting a framework).
>
> === 8. Review/copy over outstanding tickets. ===
> There are a number of tickets in the Naked Objects TRAC wiki. These
> should be either moved over, or fixed.
>
> == Initial Goals ==
> The following outlines some of the goals we have set ourselves during
> incubation. Of course, these may change as we proceed and learn more.
>
> * Prepare ground by defining the 3 area of Isis: Application; Framework;
> and Plugin.
> * Address (either fix or transfer) all tickets from Naked Objects TRAC
> wiki.
> * Ensure existing documentation (of which there is a reasonable amount)
> is correctly related to each project now that the documentation has been
> separated out.
> * v 0.1 - source code combination and rationalization (as per above).
> * v 0.2 - refactor components to JSR-299, while maintaining backwards
> compatibility for bootstrapping.
> * v 0.3 - JPA persistor ported from Hibernate to Apache OpenJPA.
> * v 0.4 - integrate with JMX for runtime management; provide profiling
> of client/server and webapps (eg serialization vs domain logic vs domain
> services vs object store timings).
> * v 0.5 - write contract tests for all major plugin APIs (object stores,
> authentication, authorization, remoting).
>
> We also have a number of overarching goals:
>
> * steadily improve the code coverage
> * clean up the APIs. Some of the code dates back to Java 1.1 (at one
> point in time the code was cross-compiled into J# code); so there is
> opportunity to use more generics and remove use of arrays
> * steadily reduce the amount of proprietary code, and the code size in
> general; use newer libraries such as google-collections more extensively.
>
> As well as the work going on to create the Isis project there are a
> number of components that are in the works, and that will be released as
> they are ready:
>
> * Scimpi web application release.
> * Introduce dynamic view design into the DnD viewer.
> * [[http://wicket.apache.org|Wicket]] viewer release.
> * NOSQL persistor release (using [[http://couchdb.apache.org|CouchDB]],
> [[http://www.mongodb.org/|MongoDB]] and
> [[http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html|BerkeleyDB]]).
>
> * SQL persistor release.
> * CLI viewer release.
> * Portal integration: Examine and implement support for compatible
> portals. Under consideration:
> [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal
> Server]].
>
> Whether these are part of incubation or not will depend on whether we
> feel we have reached a self-sustaining community (but it's more likely
> than not that they will be released during incubation). Equally, there
> may be other viewers/persistors using other technologies that might be
> implemented during incubation.
>
> == Current Status ==
> Naked Objects 4.0.0 was released at the end of 2009, broadly
> corresponding to the release of Dan's book.This is released into the
> Maven central repo, along with an application archetype for quick-start.
> The three sister projects mentioned in Dan's book (restful, tested, jpa)
> are at 1.0-beta-3, but not formally released into the Maven central
> repo. The remaining sister projects are in alpha status.
>
> The main committers for the codebases to date have been Robert Matthews
> and Dan Haywood. Both Rob and Dan work on the NOF core, and each also
> works independently (reflecting their individual interests) on their
> respective plugins. Much work was done on the core by both Rob and Dan
> leading up to the release of NOF 4.0.0, and we are now reasonably happy
> with it. Much work remains (see above) in the area of
> plugins/alternatives; there is work to complete and improve the existing
> ones and many opportunities to develop new ones.
>
> We readily support users on the NO forum (on
> [[http://sourceforge.net/projects/nakedobjects/forums/|SourceForge]])
> and also on the forum for Dan's book (on pragprog.com). As a consequence
> of Dan's book, a GWT-based viewer (non open source) has been developed
> separately, and we have provided support for this (and hope it will be
> contributed back to the framework in the future).
>
> Over the years we have received some patches for the framework, which we
> have incorporated, but not many. Part of the reason for this, we
> believe, is that until NOF 4.0.0 it had a monolithic architecture,
> making it difficult for would-be contributors to provide small patches.
> We think that NOF 4.0.0 improves in this area, but a move to JSR-299
> would be a major step forward to help bring up participation.
>
> == Community ==
> We recognize that the lack of a large (or at least, vocal) user
> community is the weakest part of our proposal. That said, we do have a
> steady trickle of queries on both the Naked Objects forum, and on the
> forum for Dan's book. Getting NOF 4.0.0 released has rekindled interest
> in at least one long-time user who is helping Rob to test one of the
> object store plugins, while we've also picked up commitment to help with
> this Apache proposal from a couple of people via the book forum.
>
> To help build up our community we intend to:
>
> * ensure that the website and documentation is first-rate (see initial
> goals, above)
> * make sure that the Isis code can be easily used and understood
> * court other open source projects with compatible technologies to work
> on integrations with Isis
> * write a series of articles for leading web journals, eg
> theserverside.com, javaworld.com, artima.com. We would want to point out
> that we were in the Apache Incubator, and actively looking for help
> * submit sessions to Devoxx and similar, Java-focused, conferences;
> again we'd trade on the Apache Incubator status.
>
> We also hope that some of the newer members of our community will help
> us identify what the roadblocks are to adoption, so that we can address
> them.
>
> == Core Developers ==
> The core developers are:
>
> * Robert Matthews, UK-based independent consultant. Original author of
> the Naked Objects framework, committer to the NOF core and primary
> developer of the NOF plugins (DnD viewer, HTML viewer, Scimpi viewer,
> in-memory !ObjectStore, XML !ObjectStore, !BerkeleyDB !ObjectStore, SQL
> !ObjectStore, !MongoDB ObjectStore). Until recently, worked for Naked
> Objects Group Ltd on the commercial .NET version. Is now independent and
> working on apps built using the open source Java version.
>
> * Dan Haywood, UK-based independent consultant. Contributor to the Naked
> Objects framework since 2005; took lead in much of the restructuring of
> the NO architecture for NOF 4.0.0. Also primary developer for sister
> projects plugins (!RestfulObjects viewer, !WicketObjects viewer, JPA
> !ObjectStore, !TestedObjects "viewer", Groovy support). Part-time
> consultant/advisor to the Irish Government project (since 2004); also a
> trainer/consultant in agile, Java, TDD etc.
>
> Additional committers are:
>
> * Kevin Meyer, South Africa-based freelance developer and business
> analyst. Kevin has been working primarily in a testing role, both on the
> SQL Object Store with Rob and on the Wicket viewer with Dan. Kevin has
> recently started contributing fixes to both.
>
> * Dave Slaughter, US-based developer/consultant who is the Lead of the
> Software and Specialty Engineering group at SM&A. Dave has spent his
> career in the development of enterprise applications for companies such
> as Siemens, Sprint and Lockheed Martin. He has started a SWT viewer and
> has also started improving code coverage of the XML !ObjectStore.
>
> * Alexander Krasnukhin, a Swedish-based developer who has spent more
> than a year developing different applications on Naked Objects v3 and
> spent six months developing a closed-source GWT viewer for Naked Objects
> v4.0 for his former employer in Russia. Alexander is interested in
> developing a new viewer for Android.
>
> As a result of a correspondence on the incubator mailing list, we have
> also had interest from:
>
> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour
> has helped us with this proposal relating to JSR-299.
>
> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an
> interest in developing a Tapstry-based viewer.
>
> We also have had interest (off list) in developing a Vaadin viewer, and
> we know of a student masters project that has developed a (different)
> Android viewer for Naked Objects 4.0, which we're keen to incorporate if
> we can. We are also hoping that we might persuade Alexander's previous
> employer to donate their GWT viewer.
>
> == Alignment ==
> The current codebase makes heavy use of Apache projects, including:
> Maven, log4j, Apache Commons Codec/Collections/CLI/Lang/HttpClient and
> Wicket.
>
> There is a particular opportunity to integrate nicely with both Wicket
> and Tapestry. Both Wicket and Tapestry are great way of building web
> UIs, but have little to say about the "back-end". Naked Objects,
> meanwhile, provides a full runtime environment with pluggable
> persistence layers, and exposes a metamodel to allow generic or
> customisable UIs to be built rapidly. The currently in-development
> !WicketObjects viewer brings Wickets and Naked Objects together, and (as
> noted above) there has been interest in writing a Tapestry viewer.
>
> Another ongoing integration project is the ongoing-development of an
> object store using MongoDB; the intent is to make this codebase a good
> basis for other similar object stores, such as Apache CouchDB.
>
> There are no Apache projects that we are aware of that compete with
> Naked Objects. At its heart, NO is (a) a metamodel, and (b) a container
> that acts as an abstraction over a persistence layer, using the identity
> map pattern.
>
> == Known Risks ==
> The biggest risk is that we fail to build a diverse community during
> incubation, opening up the possibility that the project could be orphaned.
>
> That said, there is little risk that either Rob or Dan will move onto
> other interests; we are both independent consultants and have the
> resources and inclination to continue working on the codebase. Indeed,
> with Rob now working only on the Java version (and not the .NET one) and
> Dan having finished his book, we have more resources now than at any
> time in the last couple of years.
>
> == Inexperience with Open Source ==
> Although Naked Objects is an open source project, the number of
> committers is so small then we cannot claim great experience with open
> source. Neither Rob nor Dan are committers to any other open source
> project, though both have submitted occasional patches to the various
> open source projects that we use.
>
> We are, however, comfortable users of open source projects. We also
> appreciate that there are lots of open source projects out there and
> that most developers will form an impression of a project without
> necessarily ever trying it out. This is one of the reasons why we feel
> we need to bring the two different codebases together, and create a
> standard message about what Apache Isis is about ("rapid development",
> "domain-driven design", "standard, extensible architecture",
> "customizable UIs").
>
> == Homogeneous Developers ==
> The two main developers, Rob and Dan, are based in the UK. Although we
> have collaborated on the framework over the years, we do not work for
> the same company and are independent.
>
> The other developers mentioned in this proposal are based in South
> Africa, US, Sweden, Egypt and Germany.
>
> == Reliance on Salaried Developers ==
> There are no salaried developers working on the projects. The main
> developers, Dan and Rob, are both independent consultants. We use
> non-billable time to work on the codebase, with the view to developing
> consultancy/services from it.
>
> == Documentation ==
> * [[http://www.nakedobjects.org/Pawson-Naked-Objects-thesis.pdf|Richard
> Pawson's PhD Thesis]], with foreword by Trygve Reenskaug
> * Books:
> * Domain Driven Design using Naked Objects, Dan Haywood
> * [[http://pragprog.com/titles/dhnako|pragprog.com/titles/dhnako]]
> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
> * full text available online at
> [[http://nakedobjects.org/book/|nakedobjects.org/book]]
> * [[http://nakedobjects.org|nakedobjects.org]] - current website
> * [[http://danhaywood.com|danhaywood.com]] - Dan's blog to accompany his
> book
> * [[http://starobjects.org|starobjects.org]] - parent to Dan Haywood's
> sister projects; references the various SF websites for the sister projects
>
> == Source and IP Submission Plan ==
> As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
> Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
> Apache, while Dan is also happy to donate the various sister projects
> that he has written. Having a single legal entity - ASF - owning the
> relevant rights to all this software would be very desirable.
>
> == External Dependencies ==
> Other than the Apache dependencies, all other open source projects used
> all have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg
> Hamcrest, ASM), MPL (eg javassist) or similarly permissive licenses. We
> do also have a soft dependency on an LGPL-licensed library (Hibernate)
> but during migration would look to migrate to the Apache equivalent
> (OpenJPA).
>
> == Required Resources ==
> * Subversion
> * Jira
> * Hudson CI server
> * Wiki
> * Website space
>
> == Mailing Lists ==
> * isis-private
> * isis-dev
> * isis-commits
> * isis-user
>
> == Subversion Repository ==
> https://svn.apache.org/repos/asf/incubator/isis
>
> == Issue Tracking ==
> Jira; project known as 'isis'
>
> == Initial Committers ==
> * Robert Matthews
> * Dan Haywood
> * Kevin Meyer
> * Dave Slaughter
> * Alexander Krasnukhin
>
> == Affiliations ==
> Alexander is employed as a software developer by Zenterio AB. The other
> committers are independent consultants.
>
> == Champion ==
> [none yet]
>
> == Sponsors: Nominated Mentors ==
> * Vincent Massol
> * James Carman
> * [more required]
>
> == Sponsor ==
> Apache Incubator
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org