I'm definitely interested. BeanUtils tries to do too many things in one lib, and besides it is really ugly internally. So something like Morph would be very useful to have.
For a commons-digester 2.x (if it ever occurs) I would definitely like to get rid of the existing BeanUtils dependency, and that means finding some alternative. However I don't personally have the time necessary to work on this at the moment. Regards, Simon On Tue, 2007-04-03 at 07:16 -0700, Matt Benson wrote: > Just wanted to confirm the complete lack of interest > here. Unless I hear differently, I'll assume that's > lazy [-0]s all around and let the matter drop. > > Thanks, > Matt > > --- Matt Benson <[EMAIL PROTECTED]> wrote: > > > Morph's incubation proposal follows, sent here first > > in an effort to gain the sponsorship of Jakarta, and > > possibly to attract mentors as well. :) Thanks! > > > > Morph defines a comprehensive API for performing > > object-to-object conversions in > > Java. > > > > PROPOSAL > > > > > > BACKGROUND/RATIONALE > > > > As information flows through an application, it > > undergoes multiple transformations. While the most > > prevalent examples of this in the J2EE space are > > well-known (e.g. HTTP request parameters to > > domain/data transfer objects, DTOs to domain > > objects) > > the overall problem space is characterized by the > > lack > > of a simple, well-known, conveniently extensible > > solution. At least one JSR (295) describes such a > > facility as a dependency. Having identified the > > basic > > commonalities among the best known application > > operations requiring object conversion, Morph > > consolidates these into a single API which, along > > with > > various bundled implementation classes, seeks to > > achieve the oft-repeated software development goal > > of > > making "the simple things easy, and the hard things > > possible" with regard to its problem domain. > > > > > > CURRENT STATUS > > > > Meritocracy: > > The Morph team is eager to invest more fully in > > the > > meritocracy approach taken by the ASF. To date, > > however, Morph's development team has been > > accumulated > > by a sort of "meritocracy-on-spec" approach: Matt > > Benson was originally given > > commit rights solely on the basis of his ideas; only > > later did his work vindicate that decision. [If > > sponsored by Jakarta: This is a similar approach > > to that taken in the Jakarta community: a community > > member simply announces his desire to work on a > > component, then proceeds with the community's > > blessing.] > > > > Community: > > It is somewhat difficult to gauge the size of > > Morph's community. There have been modest but > > consistent downloads of the project since its > > initial > > prerelease: these average 21/month over 28 months. > > The traffic on its user and developer lists is > > similarly light, but several bug fixes and > > enhancements have resulted from the input of Morph's > > users. An additional possible benefit of > > Morph's joining the Apache community is that > > increased > > cooperation with and buy-in from other ASF projects > > may increase its user and/or developer communities. > > > > Core Developers: > > Matt Sgarlata is Morph's founding architect and > > developer. He has been a member of the Jakarta and > > Struts user communities for some years. Matt Benson > > is a member of the Apache Ant PMC and a Jakarta > > committer, so is familiar with (and fond of) the > > consensus and transparency encouraged in ASF > > development. > > > > Alignment: > > Morph currently contains interoperability code for > > commons-beanutils, commons-chain, and Velocity. > > Because it is Morph's secondary purpose to provide > > implementations of common conversions, code that > > facilitates Morph's use with well-known libraries in > > easily anticipated ways is considered in-scope. As > > has already been implied, it is expected that > > citizenship at the ASF would facilitate cooperation > > with existing projects to mutal benefit. Finally, > > precedent demonstrating the desirability of such a > > project at Apache exists in the form of Jakarta > > commons-convert (this component ultimately failed to > > achieve maturity). Morph's original design > > specifications are actually the generic > > subset of those drafted on the commons-dev mailing > > list as a next-generation implementation of this > > project. > > > > > > KNOWN RISKS > > > > Orphaned Products: > > The Morph developers are part of its user base. > > Object conversion may be relevant to any of various > > components of a basic Java application. The risk of > > "itch cessation" is therefore minimized; Morph > > should > > continue to be an applicable technology at low risk > > for being abandoned by its developers. > > > > Inexperience with Open Source: > > As previously indicated, one of the initial > > committers has some years of experience as a > > committer > > and PMC member at the ASF. Additionally, Morph has > > always been open-source software, with its evolution > > being directly guided by user input and developer > > consensus in similar fashion to other Apache > > projects. > > > > Homogenous Developers: > > On the plus side, the initial committers are > > united > > only by their common interest in Morph (and their > > coincidental first names and middle initials). > > However, both hail from the United States, and > > acknowledge this as a less-than-optimal level of > > diversity. As Java Locale support is a key strength > > of Morph's transformation API, wider geographical > > dispersal would be a boon. The inevitable input of > > the ASF's diverse community could only be of > > positive > > influence in this regard. > > > > Reliance on Salaried Developers: > > The core developers use Morph in their own paid > > development jobs, but are not paid to develop Morph > > per se. Withdrawal of support is not an issue from > > this perspective. > > > > No Ties to Other Apache Products: > > As described in the Alignment section, this > > library > > already has ties to many Apache products. > > Additionally, Morph's codebase is already licensed > > under the Apache Software License v2.0. > > > > A Fascination with the Apache Brand: > > While "Apache" undeniably marks a project as a > > force > > to be reckoned with, the Morph team is more > > impressed > > by the ASF's organization, procedure, community, > > transparency, and camaraderie than anything else. > > Morph's developers share a > > high opinion of Apache software in general, and > > believe that Morph is of sufficient quality and > > purity > > that it simply "belongs" at the ASF. > > > > > > DOCUMENTATION > > > > More information about Morph is available at > > http://morph.sourceforge.net . > > > > > > INITIAL SOURCE > > > > The initial code base is at > > svn://development.spiderstrategies.com/morph . > > > > > > EXTERNAL DEPENDENCIES > > > > Mandatory runtime dependencies are: > > > > - Apache Jakarta commons-logging > > - Composite @ http://composite.sourceforge.net > > (ASL2) > > > > Additionally Morph has the following compile-time > > dependencies: > > > > - Apache Jakarta commons-beanutils > > - Apache Jakarta commons-chain > > - Apache Velocity > > - J2EE Servlet API > > - Spring Framework (ASL2) > > > > Finally, Morph's test bed currently relies on > > Apache > > Jakarta commons-lang, and will soon include code > > that > > depends on the public domain ANTLR 2 parser library. > > > > > > REQUIRED RESOURCES > > > > Mailing Lists: > > (Return to this subject after a sponsor is found) > > > > Subversion Directory: > > (Return to this subject after a sponsor is found) > > > > Issue Tracking: > > (Return to this subject after a sponsor is found) > > > > > > INITIAL COMMITTERS > > > > - Matt Sgarlata (matthew DOT sgarlata DOT wh02 AT > > wharton DOT upenn DOT edu) > > - Matt Benson (mbenson AT apache DOT org) > > > > > > AFFILIATIONS > > > > Morph has no corporate affiliations. Matt > > Sgarlata > > is employed by Spider Strategies, who have > > graciously > > agreed to host Morph's Subversion repository (due to > > ongoing problems experienced with Sourceforge.net > > infrastructure); this is the extent of the claim > > Spider Strategies makes on the Morph project (i.e. > > none). The current source code correctly lists the > > copyright holder as "the original author or > > authors." > > In case the intellectual property provenance is > > still > > unclear (due to Spider Strategies' physical > > possession > > of the code > > repository), the company has indicated its > > willingness > > to sign any required documentation indicating that > > it > > holds no claims whatsoever over Morph, its source > > code, or any related electronic information. > > > > > > SPONSORS > > > > Champion: Niall Pemberton > > > > Nominated Mentors: TBD > > > > Sponsoring Entity: TBD > > > > > > March 28, 2007 > > > > > > > > > > > ____________________________________________________________________________________ > > Need Mail bonding? > > Go to the Yahoo! Mail Q&A for great tips from Yahoo! > > Answers users. > > > http://answers.yahoo.com/dir/?link=list&sid=396546091 > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > ____________________________________________________________________________________ > No need to miss a message. Get email on-the-go > with Yahoo! Mail for Mobile. Get started. > http://mobile.yahoo.com/mail > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
