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<bimargul...@gmail.com>  wrote:
+1, binding.

On Thu, Aug 26, 2010 at 12:12 PM, Siegfried Goeschl
<siegfried.goes...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


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





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

Reply via email to