Re: [morph-developer] ASF incubation proposal take 2

[Matt B. <gud...@ya...>]

Sorry for the lack of communication on my end.  I've
been fairly busy, as well as trying to decide exactly
what I think and how to verbalize it all:

  To be honest, the main reason I hesitate to attempt
to bring Composite into the ASF standalone is that I
expect it will complicate the resolution for Jakarta
to sponsor Morph:  more "moving pieces" means more
complexity in simply apprehending the concept of what
is being requested, IMHO.

  Additionally I'm not sure Composite is fully baked,
meaning no offense, Matt.  I think the project has
potential, but as yet the main benefit it delivers,
AFAICT, is some utility code to implement mixins
slightly less painfully than otherwise.  Please
correct me if I'm wrong.  Additionally it has no tests
of its own.  I realize that these arguments are red
herrings, as it's not necessary for an incubating
project to be fully baked at entry.  Actually AIUI
it's somewhat discouraged--I guess it's like padawans,
Morph being somewhat along the lines of Luke
Skywalker, nearly too old to begin the training.  ;) 
Despite these indicators in favor of incubating
Composite, I don't know that we should attempt it with
any project unless we really expect it can graduate. 
I'm not saying it couldn't, but based on my
familiarity with commons (the destination I would
expect) I don't expect it would attract many
committers--most commons projects suffer that syndrome
these days, it seems.

  Finally, I will attempt to disclose some of the
heretical thoughts I've been having about Morph
lately.  :)  Let me start by pointing out that in
addition to Composite, there is another piece of Morph
that might (eventually) be a candidate for extraction
to an independent project:  the reflection package. 
This is analogous to the dormant commons-clazz
project, so really perfectly mirrors the situation
between Morph's transformation API (IMHO its primary
function) and commons-convert.  Incidentally I believe
that Morph has an excellent chance of success on the
conversion front because I expect that part of the
reason convert "failed" is that (with no slight to
Henri or Stephen C intended) its committers shied away
from the sheer tedium of implementing the various
obvious conversions--Matt S has already done this,
much to his credit (I guess that's what real-world
projects and (presumably) deadlines will do for you ;)
 ).  But I digress...

  I'm starting a new paragraph now not because it
makes sense from a literary standpoint, but because my
eyes are starting to bleed.  To return to my point,
Morph's Reflector component would make an excellent
replacement for clazz down the line.  This would allow
a drastic shift in Morph's goals.  Currently there are
places in Morph where code from ASF commons projects
has been co-opted.  If Morph enters the Jakarta
community, I think it should use the original
libraries where that makes sense.  The specific
example I am thinking of is the reflectionToString
stuff ripped from lang, thought it's possible the
implementation was modified for Morph, in which case
that's a bad example.  But anywhere feasible I think
using commons libs makes sense from the perspectives
of
community/doing-things-the-Apache-way-so-as-to-make-a-good-impression-on-the-Incubator-PMC/dogfood-consumption.
 New paragraph again for no apparent reason:

  Let me go a step further (Here comes the heretical
part):  Morph's Language facility is IMHO
inappropriately designed.  It is designed such that
the entire language is switchable, and I think this
places the focus in the wrong place.  There are lots
of other language APIs out there--three of them are in
Jakarta commons; Morph's is unnecessary.  Or, rather,
it _would_ be if not for the emphasis that rightfully
belongs to the fact that Reflectors are used to
implement Languages with Morph.  The customizable part
of Morph Languages therefore should be not on the
end-to-end get/set process.  Instead what is
customizable should be the _syntax_ used to generate
known types of "steps" that are then used with
customizable reflectors.  The fact that the steps are
applied to a reflector should remain constant; else
you'd just use EL/Jexl/JXPath/OGNL/Groovy/etc. .  But
let's step back:  EL, Jexl, and JXPath all belong to
commons.  Of these, EL and JXPath appear to be easily
adaptable to (e.g.) a commons-reflect library and
could then immediately be able to interpret anything
that could be represented in its model.  I think this
makes a real case for the eventual extraction of the
Reflector package, and simultaneous deprecation of
Morph's Language API.  And the ability to use that
code in conjunction with EL and JXPath--and possibly
even Jexl?--would be another win in the realm of
inter-project cooperation.

Finally, I know there exists at least one recent
precedent for an incubating project having a
subproject:  Ivy + IvyDE.  So I feel like it could be
considered acceptable to bring in Morph while being
completely aboveboard about the fact that it contains
one subproject as well as additional code ripe for
extraction to another, and that both might later be
considered for extraction (presumably to commons). 
Maybe we should just present the case on
general@jakarta and see which way the wind blows
before submitting any proposals... WDYT?

br,
Matt

--- Niall Pemberton <nia...@gm...> wrote:

> I don't have a problem with bringing in Composite
> and Morph together -
> seems straight forward - two sf projects developed
> by the same people
> with the same IP(?). I think if the intention is to
> do that then its
> best to be clear about it right from the start.
> Whether any of the
> incubator folks would have issues with it I have no
> idea since I'm a
> newbie at the Apache Incubator game.
> 
> Niall
> 
> On 3/13/07, Matt Benson <gud...@ya...>
> wrote:
> > Second draft after Matt S's input:
> > -------------------------------------
> >
> > 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 difficult to gauge the exact 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) ????? Fold in if Niall thinks it's OK
> >
> >   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
> > generator.
> >
> >
> > 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
> > provenanceis 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 13, 2007
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Food fight? Enjoy some healthy debate
> > in the Yahoo! Answers Food & Drink Q&A.
> >
>
http://answers.yahoo.com/dir/?link=list&sid=396545367
> >
> >
>
-------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of
> IT
> > Join SourceForge.net's Techsay panel and you'll
> get the chance to share your
> > opinions on IT & business topics through brief
> surveys-and earn cash
> >
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 




 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121