incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Stärk <>
Subject Re: [VOTE] Isis to enter the incubator
Date Thu, 02 Sep 2010 11:06:32 GMT
+1 (not binding)


On 01.09.2010 11:42, Dan Haywood wrote:
> The Isis proposal has now been updated with a champion and several new mentors (thanks
again guys),
> and is ready to be voted on.
> The proposal is at: , the text is also
copied below.
> Please, cast your vote.
> [ ] +1, please indicate whether binding
> [ ] =0
> [ ] -1, please indicate your reason
> I'll close the vote at end of Monday 6th Sept PST, to include the weekend and the US'
Labor Day
> holiday. That's about 6 days (144 hours) from now.
> Thanks,
> Dan
> --------------------------------------
> = Isis Proposal =
> The following presents the proposal for creating a new project within the Apache Software
> 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
> 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
> 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 [[|JSR-299]]
beans. We
> believe that the JSR-299 programming model is likely to become widely used for enterprise
> 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
> extend the reach of the framework to other complementary open source frameworks (either
> 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).
> 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
> including [[|JMatter]], [[|OpenXava]], and
> [[|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
> that naked objects is only appropriate for simple CRUD based applications. While developing
> 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, [[|Domain Driven Design]]. Recognizing
that there's
> a lot of synergy between the two ideas, the NO framework now uses DDD terminology, such
> repository, domain service and value.
> As mentioned in the proposal section, Isis will consist of both the original NO framework,
> with a number of sister projects. These sister projects were written by Dan Haywood to
support a
> book he wrote about the framework, [[|Domain Driven
Design using
> Naked Objects]] (Pragmatic Bookshelf, 2009). The intent of these projects was to demonstrate
> 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
> 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 collaborative environment that the Apache Software Foundation provides.
> a diverse group of developers will also provide the opportunity for significant advancements
> 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
> 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
> system, rather than building an open source community. One could argue that we had an
> 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.
> Cockburn's hexagonal (or "ports and adapters") architecture is another influence; the
plugins that
> the NO framework supports (see [[|]])
> either ports/adapters from the presentation layer, or ports/adapters to the persistence
> Furthermore, the newer UI viewers that we have been developing allow the UI to be customized
> 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
> 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
> 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
> frameworks, we hope that being part of the Apache family might encourage members of these
> 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
> 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
> that aren't just about presentation or persistence; in Dan's book he sketches out an
> with [[|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
> 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,
> [[|MyFaces]], Pivot, …) or external (eg [[|Vaadin]],
> Portals, Android, JavaFX, [[|NetBeans]] RCP, Eclipse RCP, Eclipse
> Silverlight, …). The same is true for persistence technologies, both internal to Apache
> [[|CouchDB]], [[|OpenJPA]], Cassandra,
> HBase, iBATIS, ...) and external (eg neo4j, db4o,
> [[|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
> 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
> [[|SourceForge]]:
> *
> *
> *
> *
> * ([[|FitNesse]],
> [[|Concordion]])
> *
> 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
> * org.nakedobjects.core.* for the core
> * for each plugin
> These should move, respectively, to
> * org.apache.isis.application.*
> * org.apache.isis.core.* and
> * (we expect that plugins will become
> [[|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,
> 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
> 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
> * 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
> 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.
> * [[|Wicket]] viewer release.
> * NOSQL persistor release (using [[|CouchDB]],
> [[|MongoDB]] and
> [[|BerkeleyDB]]).
> * SQL persistor release.
> * CLI viewer release.
> * Portal integration: Examine and implement support for compatible portals. Under consideration:
> [[|WebSphere Portal Server]].
> Whether these are part of incubation or not will depend on whether we feel we have reached
> 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
> 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
> 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
> [[|SourceForge]]) and also on the
forum for
> Dan's book (on 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
> 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
> 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
> 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,,
> We would want to point out that we were in the Apache Incubator, and actively
> 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
> 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
> 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
> 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
> 2005; took lead in much of the restructuring of the NO architecture for NOF 4.0.0. Also
> developer for sister projects plugins (!RestfulObjects viewer, !WicketObjects viewer,
> !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
> 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.0.3 and spent six months developing a closed-source
> viewer for Naked Objects v4.0 for his former employer in Russia (Novosoft). 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
> * Mohammad Nour El-Din, Egypt-based committer to Apache OpenEJB. Nour has helped us with
> proposal relating to JSR-299.
> * Ulrich Stark, committer to Apache Tapestry. Uli has expressed an interest in developing
> 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
> 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".
> Objects, meanwhile, provides a full runtime environment with pluggable persistence layers,
> 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
> 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
> == 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
> developing consultancy/services from it.
> == Documentation ==
> * [[|Richard Pawson's PhD
Thesis]], with
> foreword by Trygve Reenskaug
> * Books:
> * Domain Driven Design using Naked Objects, Dan Haywood
> * [[|]]
> * Naked Objects, Richard Pawson and Rob Matthews book Naked Objects
> * full text available online at [[|]]
> * [[|]] - current website
> * [[|]] - Dan's blog to accompany his book
> * [[|]] - parent to Dan Haywood's sister projects;
> 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.
> All the existing committers to the Naked Objects framework have formally granted their
> as the copyright of NOGL; there have been no committers to Dan's sister projects other
than Dan
> himself.
> According to our checks in email archives and the SVN log, there have in addition been
patches to
> the Naked Objects framework from 4 other individuals in the community. None of these
patches is
> significant, and we don't believe that any infringe any other existing IP, and were provided
in good
> faith to be the copyright of NOGL. That said, we have e-mailed these individuals in order
to verify
> this. Worst comes to worst, we can back out their patches (based on svn diffs) and reimplement
> patches as required. These steps will be performed during incubation, before our first
> == 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
> licenses. We do also have a soft dependency on an LGPL-licensed library (Hibernate) but
> 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 ==
> == 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 engineer by Zenterio AB. The other committers are
> consultants.
> == Champion ==
> * Mark Struberg
> == Sponsors: Nominated Mentors ==
> * Mark Struberg
> * Benson Marguiles
> * Siegfried Goeschl
> * James Carman
> * Vincent Massol
> == Sponsor ==
> Apache Incubator
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message