You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Simon Kitching <sk...@apache.org> on 2007/04/09 07:44:56 UTC

Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal

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 <gu...@yahoo.com> 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:
> > general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > general-help@jakarta.apache.org
> > 
> > 
> 
> 
> 
>  
> ____________________________________________________________________________________
> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal

Posted by Henri Yandell <fl...@gmail.com>.
On 4/9/07, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Simon Kitching <sk...@apache.org> wrote:
>
> > 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.
>
> To be honest, Morph currently does probably as much as
> or more than BeanUtils.  However, its functionality
> areas are fairly well compartmentalized so that a
> Morph @ ASF could be easily "digested" into smaller
> components over time.  This is what I actually hope to
> see, FWIW...

Never did reply to this. Sorry.

I'm aiming to call a proper vote on commons-dev about TLP stuff in a
week or so (for the board meeting in a month) then I'm +1 for Morph to
wind its way through the Incubator into Commons after that.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal

Posted by Matt Benson <gu...@yahoo.com>.
--- Simon Kitching <sk...@apache.org> wrote:

> 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.

To be honest, Morph currently does probably as much as
or more than BeanUtils.  However, its functionality
areas are fairly well compartmentalized so that a
Morph @ ASF could be easily "digested" into smaller
components over time.  This is what I actually hope to
see, FWIW...

-Matt

> 
> 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 <gu...@yahoo.com> 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:
> > > general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > general-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> > 
> >  
> >
>
____________________________________________________________________________________
> > 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:
> general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> general-help@jakarta.apache.org
> > 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> general-help@jakarta.apache.org
> 
> 



 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org