incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Trivial Update of "IsisProposal" by RobertMatthews
Date Sun, 22 Aug 2010 19:35:03 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "IsisProposal" page has been changed by RobertMatthews.
http://wiki.apache.org/incubator/IsisProposal?action=diff&rev1=5&rev2=6

--------------------------------------------------

  = Isis Proposal =
- 
- The following presents the proposal for creating a new Isis project within the Apache Software
Foundation.
+ The following presents the proposal for creating a new project within the Apache Software
Foundation called Isis.
  
  == Abstract ==
- 
- Isis will be a pojo-based framework providing RAD for domain-driven (DDD) applications.
+ Isis will be a pojo-based framework to rapidly develop and deploy domain-driven (DDD) applications.
  
  == Proposal ==
- 
- The Isis project will bring together a collection of open source projects which collectively
support the rapid development for domain-driven applications.  The heart of Isis is the Naked
Objects Framework, an 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.
+ 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 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,
which extend the reach of Naked Objects in several key areas.
  
- In addition, the project will aim to make it easy for new contributors to develop their
own plugins, thereby extending the reach of the framework to other complementary open source
frameworks (either with Apache or outside).
+ In addition, the project will aim to make it easy for new contributors to develop their
own plugins, thereby further extending 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 takes care of rendering those pojos in a UI, generated reflectively at runtime.
 You can think of it 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 JMatter, OpenXava,
and Trails.
@@ -31, +27 @@

  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 .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 collaborate 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.
+ 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 ~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.
+ 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 approxi500 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.
  
@@ -49, +44 @@

  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.  There are lots of UI frameworks we haven't even started on (eg Vaadin,
JavaFX, Eclipse RCP, NetBeans RCP, Eclipse RAP, FLEX, Silverlight, ...), as well as lots of
new persistence stores (eg MongoDB, neo4j, Cassandra, db4o, BigTable, Amazon S3, JCloud …
).  There are also lots of development tools that could be built, either plugins into IDEs,
or into build tools such as Maven.
  
  == Initial Source ==
- 
  === 1. Combine the codebases ===
- 
  Both the core Naked Objects framework and the sister projects reside in Subversion trees,
hosted on SourceForge:
+ 
   * nakedobjects.sourceforge.net
   * wicketobjects.sourceforge.net
   * restfulobjects.sourceforge.net
@@ -63, +57 @@

  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, though they do both define a "corporate" parent POM
that will need merging.
  
  === 3. Standardize package names ===
- 
  Naked Objects package names are currently:
+ 
   * org.nakedobjects.core.* for the  core
   * org.nakedobjects.plugins.xxx for each plugin
  
  These should move to org.apache.isis.core.* and org.apache.isis.plugins.xxx
  
  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, they should just move to org.apache.isis.plugins.*.
  
  === 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 down to < 1.0, eg v0.5.  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 ===
- 
  NO 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 in Sourceforge.  These should
be either moved over, or fixed.
+ 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.
  
  [ co-authors, please edit ... ]
  
+  * Prepare ground by defining the 3 area of Isis: Application; Framework; and Plugin.
-  * v 0.1 - initial source take-on and rationalization (as per above); all tickets from Naked
Objects TRAC wiki in Sourceforge addressed
+  * v 0.1 - source code combination and rationalization (as per above); all tickets from
Naked Objects TRAC wiki addressed or transferred.
-  * v 0.2 - go through existing documentation (of which there is a reasonable amount) and
ensure correctly packaged against source
+  * v 0.2 - 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.3 - replace bootstrapping with Guice/JSR-330 support; use JSR-299 internally (if
appropriate); use META-INF/Services to locate components
-  * v 0.4 - wicket viewer release, couchdb release
+  * v 0.4 - Wicket viewer release, NOSQL release (using Couchd, MongoDB and BerkeleyDB).
+  * v 0.5 - SQL persistor release, CLI viewer release.
-  * v 0.5 - porting to apache implementations:  jpa persistor ported from hibernate to apache
openjpa; restful objects ported from resteasy to either apache wink and/or apache cxf
+  * v 0.6 - porting to Apache implementations: JPA persistor ported from Hibernate to Apache
OpenJPA; restful objects ported from resteasy to either Apache Wink and/or Apache CXF.
-  * v 0.6 - manageability: 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.7 - manageability: 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.7 - Portal integration: Examine and implement support for compatible portals. Under
consideration: [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal Server]].
+  * v 0.8 - Portal integration: Examine and implement support for compatible portals. Under
consideration: [[http://www-01.ibm.com/software/websphere/portal/|WebSphere Portal Server]].
-  * v 0.8 - 
-  * v 0.9 - contract tests for all major plugin APIs (object stores, authentication, authorization,
remoting)
+  * v 0.9 - contract tests for all major plugin APIs (object stores, authentication, authorization,
remoting).
-  * v 1.0 - 
+  * v 1.0 -
  
  We also have a number of overarching goals:
+ 
   * steadily ratchet up the code coverage
-  * clean up the APIs.  Some of the code dates back to 2002, prior to generics and use of
functional libraries.
+  * clean up the APIs. Our original requirement was to recompile as J# code so some of the
code is prior to generics and the use of functional libraries.
-  * steadily reduce the amount of proprietary code/code size in general.
+  * steadily reduce the amount of proprietary code and just the code size in general.
  
  == Current Status ==
- 
  Naked Objects 4.0.0 was released at the end of 2009, broadly corresponding to the release
of Dan's book.  These are 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 work 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.  
+ 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 work 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.
  
  We readily support users on the NO forum (on 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 the architecture
of the codebase was not particular clean, making it difficult for would-be contributors to
provide small patches.  We think that NOF 4.0.0 addresses this issue, but we need to explain
the architecture better (see current goals) to 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)
   * 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, CouchDB 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.
@@ -168, +155 @@

  
  We also have had interest (off list) in developing a Vaadin viewer and/or a GWT viewer;
we hope one of these at least might progress.
  
- 
  == 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 has 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 Wicket Objects viewer brings Wickets and Naked Objects together,
and there has been interest in writing a Tapestry viewer.
  
- Another ongoing integration project is the ongoing-development of an object store using
Apache CouchDB. 
+ Another ongoing integration project is the ongoing-development of an object store using
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, leaving
a risk 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 and not .NET version 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, because 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", "pluggable 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 and the US.  Other
interest over the years has come worldwide, such as Russia and various countries in Europe.
  
- 
  == 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
+   * Domain Driven Design using Naked Objects, Dan Haywood
-       * [[http://pragprog.com/titles/dhnako|http://pragprog.com/titles/dhnako]]
+    * http://pragprog.com/titles/dhnako
-    * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
+   * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
-       * full text available online at [[http://nakedobjects.org/book/|nakedobjects.org/book]]
+    * 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 Naked Objects Group Ltd. 
NOGL would be 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 copyright of 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
@@ -237, +207 @@

   * 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
  
- 
  == Affiliations ==
- 
  All committers are independent consultants.
  
- 
  == Champion ==
- 
  [none yet]
  
- 
  == Sponsors: Nominated Mentors ==
- 
   * Vincent Massol
   * James Carman
   * [more required]
  
  == Sponsor ==
- 
  Apache Incubator
  

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


Mime
View raw message