Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of nour.mohammad@gmail.com
 designates 209.85.161.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Ex+lPv8daJhpfzEEPkh/GCME8GDqt40fQ58va2sMo5TGJShsLAeWitove/fohKxE9i
         Nmh+2Zg5JwU0sDHg+E/LCwn8Xw49quAxVA2/qT/OLhJHZ93UEyXyIRnJYxcV5i3MT/T0
         0GjHkSpjW3M8mBP2Ax848J8RQzXfNXKkhU248=
MIME-Version: 1.0
In-Reply-To: <4C73FD6A.10009@gmail.com>
References: <4C73FD6A.10009@gmail.com>
Date: Wed, 25 Aug 2010 08:33:42 +0000
Message-ID: <AANLkTinFGb7vf0fg95-0kAsmCuAcpg4fJ+EUW9nR6hO9@mail.gmail.com>
Subject: Re: [PROPOSAL] Apache Isis
From: Mohammad Nour El-Din <nour.mohammad@gmail.com>
To: general@incubator.apache.org, dan@haywood-associates.co.uk
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1 (Not binding)

On Tue, Aug 24, 2010 at 5:12 PM, Dan Haywood <dkhaywood@gmail.com> wrote:
> =A0I'd like to formally propose a new project for the incubator, Apache I=
sis.
> 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 t=
o
> 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> =3D Isis Proposal =3D
> The following presents the proposal for creating a new project within the
> Apache Software Foundation called Isis.
>
> =3D=3D Abstract =3D=3D
> Isis will be an extensible standards-based framework to rapidly develop a=
nd
> enterprise level deploy domain-driven (DDD) applications.
>
> =3D=3D Proposal =3D=3D
> 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 sou=
rce
> frameworks (either within Apache or outside of it).
>
> =3D=3D Background =3D=3D
> Naked Objects is an open source Java framework that was originally develo=
ped
> to explore the idea of enterprise systems that treat the user as a "probl=
em
> solver, not a process follower". Conceived by Richard Pawson, the first
> version of the framework was written by Robert Matthews (2002). Richard a=
nd
> 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 t=
he
> 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 amo=
ng
> the early adopter crowd, generally splitting opinion as either a very goo=
d
> idea or a very bad one. A common misconception is that naked objects is o=
nly
> 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 origi=
nal
> NO framework, along with a number of sister projects. These sister projec=
ts
> were written by Dan Haywood to support a book he wrote about the framewor=
k,
> [[http://pragprog.com/titles/dhnako|Domain Driven Design using Naked
> Objects]] (Pragmatic Bookshelf, 2009). The intent of these projects was t=
o
> 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. Richa=
rd
> 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.
>
> =3D=3D Rationale =3D=3D
> 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 th=
e
> Apache incubator will automatically bring us these things. Rather, we
> believe it will give us a platform to more effectively publicize the proj=
ect
> 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 opportunit=
y
> for significant advancements and improvements to the Isis framework, maki=
ng
> it more useful for more people.
>
> There are, then, several reasons for us wanting to contribute the framewo=
rk
> to Apache.
>
> First, it helps us legitimize the "naked objects" concept. Notwithstandin=
g
> 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 t=
he
> 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 abo=
ut
> 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, fro=
m
> "best thing since sliced bread", through "fundamentally flawed", to "neve=
r
> 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 repositio=
n
> the framework. While the "naked objects" pattern is important, we also wa=
nt
> to emphasize domain-driven design. Alistair Cockburn's hexagonal (or "por=
ts
> 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 attractin=
g
> 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 i=
s
> 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 dona=
te
> the relevant rights to this software to Apache because they recognise tha=
t
> the framework is already critically dependent upon the open source
> community, so this is the best way to encourage greater take up, and ensu=
re
> 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 t=
hat
> Dan has written would also be donated to ASF. Having a single legal entit=
y -
> 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 d=
o
> 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 obje=
ct
> stores. One of the sister projects provides a customizable viewer that us=
es
> Wicket; since pre-announcing this proposal on the incubator mailing list
> we've had one expression of interest to develop a new viewer using Tapest=
ry.
>
> 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 i=
nto
> JSR-299 beans. Again, we've had an expression of interest from the incuba=
tor
> 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, thou=
gh,
> 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 eve=
n
> started on, either Apache's own (eg Click, Tapestry,
> [[http://myfaces.apache.org/|MyFaces]], Pivot, =85) or external (eg
> [[http://vaadin.com|Vaadin]], Portals, Android, JavaFX,
> [[http://netbeans.org|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,
> Silverlight, =85). 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, JClo=
ud
> =85 ). And=85 there are also lots of development tools that could be buil=
t,
> 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 wh=
at
> is required to extend it).
>
> =3D=3D Initial Source =3D=3D
> =3D=3D=3D 1. Combine the codebases =3D=3D=3D
> 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 Apac=
he
> infrastructure.
>
> =3D=3D=3D 2. Rationalize the builds =3D=3D=3D
> 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.
>
> =3D=3D=3D 3. Standardize package names =3D=3D=3D
> 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.h=
tml#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.*.
>
> =3D=3D=3D 4. Move the version number down. =3D=3D=3D
> 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.
>
> =3D=3D=3D 5. Establish continuous integration =3D=3D=3D
> The Naked Objects framework currently builds on its own Hudson server; we
> would move this over to run on Apache infrastructure.
>
> =3D=3D=3D 6. Rationalize documentation =3D=3D=3D
> The documentation for the sister projects is reasonably up-to-date, but t=
he
> documentation for Naked Objects needs rationalizing, aligning with the co=
re
> 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.
>
> =3D=3D=3D 7. Rationalize the Maven sites =3D=3D=3D
> Related to above, we need to "tell the story better" so that would-be use=
rs
> can see what benefits using the framework will bring (and, conversely, wh=
at
> freedom they give up in adopting a framework).
>
> =3D=3D=3D 8. Review/copy over outstanding tickets. =3D=3D=3D
> There are a number of tickets in the Naked Objects TRAC wiki. These shoul=
d
> be either moved over, or fixed.
>
> =3D=3D Initial Goals =3D=3D
> 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 wi=
ki.
> * Ensure existing documentation (of which there is a reasonable amount) i=
s
> 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 poin=
t
> in time the code was cross-compiled into J# code); so there is opportunit=
y
> 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 numbe=
r
> of components that are in the works, and that will be released as they ar=
e
> 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.ht=
ml|BerkeleyDB]]).
> * SQL persistor release.
> * CLI viewer release.
> * Portal integration: Examine and implement support for compatible portal=
s.
> 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 fee=
l
> we have reached a self-sustaining community (but it's more likely than no=
t
> that they will be released during incubation). Equally, there may be othe=
r
> viewers/persistors using other technologies that might be implemented dur=
ing
> incubation.
>
> =3D=3D Current Status =3D=3D
> Naked Objects 4.0.0 was released at the end of 2009, broadly correspondin=
g
> 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 sist=
er
> projects are in alpha status.
>
> The main committers for the codebases to date have been Robert Matthews a=
nd
> 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 w=
ork
> 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 difficul=
t
> 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 forwar=
d
> to help bring up participation.
>
> =3D=3D Community =3D=3D
> 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-ti=
me
> 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 o=
n
> integrations with Isis
> * write a series of articles for leading web journals, eg theserverside.c=
om,
> 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=
.
>
> =3D=3D Core Developers =3D=3D
> The core developers are:
>
> * Robert Matthews, UK-based independent consultant. Original author of th=
e
> 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 !ObjectStor=
e,
> !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 t=
he
> 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 analys=
t.
> Kevin has been working primarily in a testing role, both on the SQL Objec=
t
> Store with Rob and on the Wicket viewer with Dan. Kevin has recently star=
ted
> 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 care=
er
> in the development of enterprise applications for companies such as Sieme=
ns,
> Sprint and Lockheed Martin. He has started a SWT viewer and has also star=
ted
> 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 h=
is
> 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 al=
so
> 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 intere=
st
> in developing a Tapstry-based viewer.
>
> We also have had interest (off list) in developing a Vaadin viewer, and w=
e
> know of a student masters project that has developed a (different) Androi=
d
> 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.
>
> =3D=3D Alignment =3D=3D
> 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 an=
d
> Tapestry. Both Wicket and Tapestry are great way of building web UIs, but
> have little to say about the "back-end". Naked Objects, meanwhile, provid=
es
> 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 obje=
ct
> 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 ac=
ts
> as an abstraction over a persistence layer, using the identity map patter=
n.
>
> =3D=3D Known Risks =3D=3D
> 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 oth=
er
> 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 las=
t
> couple of years.
>
> =3D=3D Inexperience with Open Source =3D=3D
> Although Naked Objects is an open source project, the number of committer=
s
> is so small then we cannot claim great experience with open source. Neith=
er
> Rob nor Dan are committers to any other open source project, though both
> have submitted occasional patches to the various open source projects tha=
t
> 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 bri=
ng
> 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").
>
> =3D=3D Homogeneous Developers =3D=3D
> The two main developers, Rob and Dan, are based in the UK. Although we ha=
ve
> 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.
>
> =3D=3D Reliance on Salaried Developers =3D=3D
> 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.
>
> =3D=3D Documentation =3D=3D
> * [[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 projec=
ts
>
> =3D=3D Source and IP Submission Plan =3D=3D
> 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 tha=
t
> he has written. Having a single legal entity - ASF - owning the relevant
> rights to all this software would be very desirable.
>
> =3D=3D External Dependencies =3D=3D
> Other than the Apache dependencies, all other open source projects used a=
ll
> have ASL v2.0 (eg Google Collections, cglib, objenesis), BSD (eg Hamcrest=
,
> ASM), MPL (eg javassist) or similarly permissive licenses. We do also hav=
e a
> soft dependency on an LGPL-licensed library (Hibernate) but during migrat=
ion
> would look to migrate to the Apache equivalent (OpenJPA).
>
> =3D=3D Required Resources =3D=3D
> * Subversion
> * Jira
> * Hudson CI server
> * Wiki
> * Website space
>
> =3D=3D Mailing Lists =3D=3D
> * isis-private
> * isis-dev
> * isis-commits
> * isis-user
>
> =3D=3D Subversion Repository =3D=3D
> https://svn.apache.org/repos/asf/incubator/isis
>
> =3D=3D Issue Tracking =3D=3D
> Jira; project known as 'isis'
>
> =3D=3D Initial Committers =3D=3D
> * Robert Matthews
> * Dan Haywood
> * Kevin Meyer
> * Dave Slaughter
> * Alexander Krasnukhin
>
> =3D=3D Affiliations =3D=3D
> Alexander is employed as a software developer by Zenterio AB. The other
> committers are independent consultants.
>
> =3D=3D Champion =3D=3D
> [none yet]
>
> =3D=3D Sponsors: Nominated Mentors =3D=3D
> * Vincent Massol
> * James Carman
> * [more required]
>
> =3D=3D Sponsor =3D=3D
> Apache Incubator
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


--=20
Thanks
- Mohammad Nour
=A0 Author of (WebSphere Application Server Community Edition 2.0 User Guid=
e)
=A0 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