incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: [PROPOSAL] Apache Isis
Date Fri, 27 Aug 2010 16:36:40 GMT


----- Original Message ----
> From: Dan Haywood <>
> To:
> Cc:
> Sent: Tue, August 24, 2010 7:12:10 PM
> Subject: [PROPOSAL] Apache Isis
> I'd like to formally propose a new project for the incubator, Apache Isis. If  
>accepted, Isis will combine the existing open source Naked Objects framework  
>with a collection of sister projects, providing an extensible Java-based  
>framework for rapidly developing domain-driven applications.
> I floated  the idea of Isis on this mailing list about a month or so ago, and 
>we got some  positive feedback and a couple of expressions of interest in 
>contributing. Since  then, we've put together a proposal (also copied in below) 
>onto the incubator  wiki.
> The proposal is at:
> The current codebase is  at:, with sister projects 
>hosted at:
> 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 
>[[|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 
>[[|JMatter]], [[|OpenXava]], and 
> 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, 
>[[|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, 
>[[|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 
>[[|.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 
> 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 [[|]]) 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 
> 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]; 
>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, [[|MyFaces]], Pivot, 
>…) or external  (eg [[|Vaadin]], Portals, Android, JavaFX, 
>[[|NetBeans]] RCP, Eclipse RCP, Eclipse RAP, FLEX,  
>Silverlight, …). The same is true for persistence technologies, both internal to  
>Apache (eg [[|CouchDB]], 
>[[|OpenJPA]], Cassandra, Cayenne, 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 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  [[|SourceForge]]:
> *
> *
> *
> *
> * ([[|FitNesse]], 
> *
> These will need to be moved into a single  Subversion tree, hosted on Apache 
> === 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
> * for each plugin
> These should move,  respectively, to
> * org.apache.isis.application.*
> *  org.apache.isis.core.* and
> * (we expect that  plugins will become 
>  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  
> === 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 
> * 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 
> *  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.
> * [[|Wicket]] viewer release.
> * NOSQL persistor  release (using [[|CouchDB]], 
>[[|MongoDB]] and 
> *  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 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 
> == 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 
>[[|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 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, 
> *  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 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 
> 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  ==
> * [[|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; 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 ==
> ==  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:
> For  additional commands, e-mail: 


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

View raw message