morph-developer

[morph-developer] ASF incubation proposal take 2

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

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

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

[Matt S. <Mat...@wh...>]

Take 2 looks great to me.  Nice job Matt B :)

Matt S

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

[Niall P. <nia...@gm...>]

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
>

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

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

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
>   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.
>   
I think you're right.  I think the way you originally wrote up the 
proposal is good, but perhaps we need an "additional notes" section or 
something where we explain what Composite is and why we didn't include 
it in the move to Apache.  Who knows, maybe they will say Composite 
needs to move too or maybe they will say to leave it on SF because it's 
not high enough quality for Apache in terms of test cases, 
documentation, etc.
>   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. 
>   
I hadn't really thought about that, but excellent point.  Maybe we could 
make this another "additional note"
>   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.
This stuff was partly an experiment on my part.  I don't think it's very 
useful and it doesn't work well anyway, so we could always deprecate it 
and get rid of it alltogether.

I don't want to introduce any new dependencies of Morph on anything 
else.  The reason for this is that I am using Morph in Java Applets and 
I don't want the applets to have to balloon out to include commons-lang, 
commons-collection or who knows what else.  I don't think there's much 
Apache code copy/pasted into Morph.  The few bits that are copied I 
think are justifiable to copy if they save a us from a dependency.
>   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.
>   
The one thing I don't like about those other APIs is that, forgive me if 
I'm wrong, it takes like 5 lines to do anything.  I really like the 
ability to just say Morph.getIntegerObject(domainObject, 
"some.random[1].nested.path") without having to compile stuff, figure 
out if the output is going to be of the type I want, etc.  If I am 
mistaken and there is some other library that lets me do all this in one 
line (or we can move this to some other project) I'd be perfectly happy 
getting rid of the Language API.  You're right, this API is straying 
someone from Morph's original purpose.

I don't understand what you mean when you say languages should not be 
customizable on the get/set process.  Are you saying that it shouldn't 
be this high level where the customization takes place?  There is the 
ExpressionParser interface as well as a possible entry point for 
customization.  I'm not trying to defend this design, because a better 
one probably could be crafted.  I guess the idea here was that you could 
use Morph to implement whatever language you wanted and leverage the 
Reflection API.  Is your argument that in some cases you do want the 
facilities in these other packages, for example expression compilation?
> 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?
>   
As I said before, I think we should just submit what you wrote up before 
and just add an additional notes section that includes:
- Reflection mechanism is ripe for extraction, possibly to replace 
commons-clazz.  Could be a powerful extension point for existing Jakarta 
language libraries.
- Composite is a child project that we weren't sure if it should be 
brought over or not because it's not as mature.  We're happy either way, 
but our real focus is on Morph right now.

Matt S

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

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

whew... I'll try this inline. ;)

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Matt Benson wrote:
> >   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.
> >   
> I think you're right.  I think the way you
> originally wrote up the 
> proposal is good, but perhaps we need an "additional
> notes" section or 
> something where we explain what Composite is and why
> we didn't include 
> it in the move to Apache.  Who knows, maybe they
> will say Composite 
> needs to move too or maybe they will say to leave it
> on SF because it's 
> not high enough quality for Apache in terms of test
> cases, 
> documentation, etc.

Again, I'm not necessarily opposed to bringing it
over, but if it could come as a subproject that
removes the burden on composite to survive on its own.

> >   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. 
> >   
> I hadn't really thought about that, but excellent
> point.  Maybe we could 
> make this another "additional note"
> >   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.
> This stuff was partly an experiment on my part.  I
> don't think it's very 
> useful and it doesn't work well anyway, so we could
> always deprecate it 
> and get rid of it alltogether.

oh... I was thinking of the MorphEqualsBuilder here I
think.  Now I'm not sure what you're talking about. 
:)
> 
> I don't want to introduce any new dependencies of
> Morph on anything 
> else.  The reason for this is that I am using Morph
> in Java Applets and 
> I don't want the applets to have to balloon out to
> include commons-lang, 
> commons-collection or who knows what else.  I don't
> think there's much 
> Apache code copy/pasted into Morph.  The few bits
> that are copied I 
> think are justifiable to copy if they save a us from
> a dependency.
> >   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.
> >   
> The one thing I don't like about those other APIs is
> that, forgive me if 
> I'm wrong, it takes like 5 lines to do anything.  I
> really like the 
> ability to just say
> Morph.getIntegerObject(domainObject, 
> "some.random[1].nested.path") without having to
> compile stuff, figure 
> out if the output is going to be of the type I want,
> etc.  If I am 
> mistaken and there is some other library that lets
> me do all this in one 
> line (or we can move this to some other project) I'd
> be perfectly happy 
> getting rid of the Language API.  You're right, this
> API is straying 
> someone from Morph's original purpose.

Point taken on verbosity, though JXPath is pretty
painless, and IIRC so is OGNL.  I don't claim to know
much about Groovy... I think you can do EL in one
line, albeit a long one.  But maybe certain libraries
just need submissions of convenience methods.  ;)

> 
> I don't understand what you mean when you say
> languages should not be 
> customizable on the get/set process.  Are you saying
> that it shouldn't 
> be this high level where the customization takes
> place?  There is the 
> ExpressionParser interface as well as a possible
> entry point for 
> customization.

Right.  And I did see that, but ExpressionParser's
results are pretty generic, which means that some of
the precision available in the other libraries wrt
detecting e.g. indexed vs. named properties would be
lost arguably unnecessarily.  And because
ExpressionParser is documented as only being
applicable to the SimpleLanguageParser, we have an IMO
unnecessary proliferation of extension points.  My
point was that the Morph Language API is useful
because of the Reflector API, so I see no reason to
subvert that by making it optional.  My vision of a
Morph "language" API would be more of maybe an
interpreter utility that, given a set of graph
traversal steps in its own terms, could navigate the
object graph using a (delegating) reflector using
pretty much the existing relevant code in
SimpleLanguage.  Shifting the customization focus to
parser implementations that provide a list of steps
would allow more detailed uses of graph traversal...
So yes, I'm thinking where we now have

[LANGUAGE]

I'm thinking

[PARSER] - Interpret steps - [REFLECTOR]

with the boxes representing the customizable parts.

I'll end this slight digression (I think it's at least
somewhat relevant but Niall might not ;)  )

>  I'm not trying to defend this
> design, because a better 
> one probably could be crafted.

And I hope you don't take my criticism as attack. 
It's certainly not intended that way.  I've told you
more than once how much I like this codebase; I tend
to find good things and try to figure out how to make
them great... :|

>  I guess the idea
> here was that you could 
> use Morph to implement whatever language you wanted
> and leverage the 
> Reflection API.

I suppose I'm just saying to make the use of the
reflection API mandatory.  :)

>  Is your argument that in some cases
> you do want the 
> facilities in these other packages, for example
> expression compilation?

Right... the SimpleExpressionLanguage is very
rudimentary, as you well know.  If you can interop
with a more mature expression parser, why not go for
it?  As for JXPath, I think it might already be
possible to plug the Reflector API into it, and
provide the implementing class in Morph at least for
the time being.  Interop = good wrt incubation!  :) 
Big win here since JXPath does things other languages
don't like AFAIK selecting multiple matching points of
a graph.

> > 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?
> >   
> As I said before, I think we should just submit what
> you wrote up before 
> and just add an additional notes section that
> includes:
> - Reflection mechanism is ripe for extraction,
> possibly to replace 
> commons-clazz.  Could be a powerful extension point
> for existing Jakarta 
> language libraries.
> - Composite is a child project that we weren't sure
> if it should be 
> brought over or not because it's not as mature. 
> We're happy either way, 
> but our real focus is on Morph right now.
> 

I'd like to know what Niall thinks here too.

-Matt B

> Matt S
> 
>
-------------------------------------------------------------------------
> 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
> 



 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> Matt Benson wrote:
>>     
>>>   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.
>>>   
>>>       
>> I think you're right.  I think the way you
>> originally wrote up the 
>> proposal is good, but perhaps we need an "additional
>> notes" section or 
>> something where we explain what Composite is and why
>> we didn't include 
>> it in the move to Apache.  Who knows, maybe they
>> will say Composite 
>> needs to move too or maybe they will say to leave it
>> on SF because it's 
>> not high enough quality for Apache in terms of test
>> cases, 
>> documentation, etc.
>>     
>
> Again, I'm not necessarily opposed to bringing it
> over, but if it could come as a subproject that
> removes the burden on composite to survive on its own.
>   
That would be ideal IMO.  Next best would be to have Composite as a 
separate project inside and Apache.  My least favorite idea is keeping 
Composite separate, but I think it's also the easiest one to propose 
initially.  I guess we could always just start in the proposal with what 
we think is ideal and then they can tell us no ;)
>>> 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. 
>>     
>>>   
>>>       
>> I hadn't really thought about that, but excellent
>> point.  Maybe we could 
>> make this another "additional note"
>>     
>>>   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.
>>>       
>> This stuff was partly an experiment on my part.  I
>> don't think it's very 
>> useful and it doesn't work well anyway, so we could
>> always deprecate it 
>> and get rid of it alltogether.
>>     
>
> oh... I was thinking of the MorphEqualsBuilder here I
> think.  Now I'm not sure what you're talking about. 
> :)
>   
Oh, I was talking about the PrettyText transformers, which are prone to 
infinite loops and really confusing blowups.  I don't use them myself, 
and I doubt anyone would want to use them over the stuff already in 
something like commons-lang.

The MorphsEqualsBuilder is only used for testing Morph (it's only 
references are completely within the src\test directory and nothing 
within src\core touches it).  The reason I didn't submit patches for 
this stuff was because I liked the existing commons-lang functionality, 
I just wanted to make the definition of "equals" a lot more loose than 
the one they use in commons-lang.

Matt S

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

[Niall P. <nia...@gm...>]

On 3/16/07, Matt Sgarlata <Mat...@wh...> wrote:
> Matt Benson wrote:
> >   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.
> >
> I think you're right.  I think the way you originally wrote up the
> proposal is good, but perhaps we need an "additional notes" section or
> something where we explain what Composite is and why we didn't include
> it in the move to Apache.  Who knows, maybe they will say Composite
> needs to move too or maybe they will say to leave it on SF because it's
> not high enough quality for Apache in terms of test cases,
> documentation, etc.

I think theres two things here - first my impression of Incubator is
that its mainly about 2 things 1) IP/legal and 2) community - if you
meet those req. then they'll let you graduate. Second is having met
the graduation criteria is the destination. If you want to join an
existing project then you have to convince that PMC that you would
make a good fit/addition. This is where (IMO) issues about the various
bits of Morph/Composite come in - since the "receiving" project like
Jakarta would raise these sorts of questions. At this stage though I
think the barriers to getting in are lower than getting out - so if we
want Jakarta sponsorship hopefully we can pursuade them that it is the
type of project that fits. Sponsoring us doesn't mean that Jakarta is
committed to accepting Morph on graduation  (or commits Morph to
having to join Jakarta) . So I don't think at this point in time its a
big issue whether we choose to take both Morph and Composite into
incubation or just Morph. Just down to your preference. As a precedent
WebWork went through incubation without bringing in XWork which was
developed by the same people and on which WebWork (now Struts 2) is
completely dependant.

Niall

> >   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.
> >
> I hadn't really thought about that, but excellent point.  Maybe we could
> make this another "additional note"
> >   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.
> This stuff was partly an experiment on my part.  I don't think it's very
> useful and it doesn't work well anyway, so we could always deprecate it
> and get rid of it alltogether.
>
> I don't want to introduce any new dependencies of Morph on anything
> else.  The reason for this is that I am using Morph in Java Applets and
> I don't want the applets to have to balloon out to include commons-lang,
> commons-collection or who knows what else.  I don't think there's much
> Apache code copy/pasted into Morph.  The few bits that are copied I
> think are justifiable to copy if they save a us from a dependency.
> >   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.
> >
> The one thing I don't like about those other APIs is that, forgive me if
> I'm wrong, it takes like 5 lines to do anything.  I really like the
> ability to just say Morph.getIntegerObject(domainObject,
> "some.random[1].nested.path") without having to compile stuff, figure
> out if the output is going to be of the type I want, etc.  If I am
> mistaken and there is some other library that lets me do all this in one
> line (or we can move this to some other project) I'd be perfectly happy
> getting rid of the Language API.  You're right, this API is straying
> someone from Morph's original purpose.
>
> I don't understand what you mean when you say languages should not be
> customizable on the get/set process.  Are you saying that it shouldn't
> be this high level where the customization takes place?  There is the
> ExpressionParser interface as well as a possible entry point for
> customization.  I'm not trying to defend this design, because a better
> one probably could be crafted.  I guess the idea here was that you could
> use Morph to implement whatever language you wanted and leverage the
> Reflection API.  Is your argument that in some cases you do want the
> facilities in these other packages, for example expression compilation?
> > 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?
> >
> As I said before, I think we should just submit what you wrote up before
> and just add an additional notes section that includes:
> - Reflection mechanism is ripe for extraction, possibly to replace
> commons-clazz.  Could be a powerful extension point for existing Jakarta
> language libraries.
> - Composite is a child project that we weren't sure if it should be
> brought over or not because it's not as mature.  We're happy either way,
> but our real focus is on Morph right now.
>
> Matt S
>
> -------------------------------------------------------------------------
> 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
>

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

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

Hi--we're all suffering from latency, but here I am. 
:)

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

> On 3/16/07, Matt Sgarlata
> <Mat...@wh...> wrote:
> > Matt Benson wrote:
> > >   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.
> > >
> > I think you're right.  I think the way you
> originally wrote up the
> > proposal is good, but perhaps we need an
> "additional notes" section or
> > something where we explain what Composite is and
> why we didn't include
> > it in the move to Apache.  Who knows, maybe they
> will say Composite
> > needs to move too or maybe they will say to leave
> it on SF because it's
> > not high enough quality for Apache in terms of
> test cases,
> > documentation, etc.
> 
> I think theres two things here - first my impression
> of Incubator is
> that its mainly about 2 things 1) IP/legal and 2)
> community - if you
> meet those req. then they'll let you graduate.
> Second is having met
> the graduation criteria is the destination. If you
> want to join an
> existing project then you have to convince that PMC
> that you would
> make a good fit/addition. This is where (IMO) issues
> about the various
> bits of Morph/Composite come in - since the
> "receiving" project like
> Jakarta would raise these sorts of questions. At

Gotcha.

> this stage though I
> think the barriers to getting in are lower than
> getting out - so if we
> want Jakarta sponsorship hopefully we can pursuade
> them that it is the
> type of project that fits. Sponsoring us doesn't

Oh, so now it's "us", is it?  >;)

> mean that Jakarta is
> committed to accepting Morph on graduation  (or
> commits Morph to
> having to join Jakarta) . So I don't think at this
> point in time its a
> big issue whether we choose to take both Morph and
> Composite into
> incubation or just Morph. Just down to your
> preference. As a precedent
> WebWork went through incubation without bringing in
> XWork which was
> developed by the same people and on which WebWork
> (now Struts 2) is
> completely dependant.

I am still undecided on what's the best way to go. 
There appear to be three options:

 A - Incubate Morph and Composite separately
 B - Incubate Morph with Composite as a subproject
 C - Incubate Morph; possibly revisit Composite later

Of these, I just have this feeling that (A) is going
to be a PITA.  I am ambivalent to options (B) and (C),
especially because Composite did actually begin as a
subset of Morph's code (why'd you have to break it
out, Matt? ;) ).  I would say we could present the
situation on general@jakarta, but my expectation is
that the obvious reaction would "path of least effort"
i.e. (C).

>From what I can tell, Composite's completeness level
might be pretty close to "the right level" for
incubation, which is too say not _too_ complete.  You
can't attract developers to, and thereby develop a
community for, code for which there is nothing to do,
after all.  Composite seems to specify a development
direction and just need completion of what has already
been specified, plus maybe one or two more niceties,
e.g. a delegating proxy that will recursively forward
method calls to components, perhaps.  However, does
anyone have the "itch" to do all this ATM?  If not,
this also recommends option (C) until someone does. 
:|

-Matt (B)

> 
> Niall
> 
> > >   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.
> > >
> > I hadn't really thought about that, but excellent
> point.  Maybe we could
> > make this another "additional note"
> > >   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.
> > This stuff was partly an experiment on my part.  I
> don't think it's very
> > useful and it doesn't work well anyway, so we
> could always deprecate it
> > and get rid of it alltogether.
> >
> > I don't want to introduce any new dependencies of
> Morph on anything
> > else.  The reason for this is that I am using
> Morph in Java Applets and
> > I don't want the applets to have to balloon out to
> include commons-lang,
> > commons-collection or who knows what else.  I
> don't think there's much
> > Apache code copy/pasted into Morph.  The few bits
> that are copied I
> > think are justifiable to copy if they save a us
> from a dependency.
> > >   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.
> > >
> > The one thing I don't like about those other APIs
> is that, forgive me if
> > I'm wrong, it takes like 5 lines to do anything. 
> I really like the
> > ability to just say
> Morph.getIntegerObject(domainObject,
> > "some.random[1].nested.path") without having to
> compile stuff, figure
> > out if the output is going to be of the type I
> want, etc.  If I am
> > mistaken and there is some other library that lets
> me do all this in one
> > line (or we can move this to some other project)
> I'd be perfectly happy
> > getting rid of the Language API.  You're right,
> this API is straying
> > someone from Morph's original purpose.
> >
> > I don't understand what you mean when you say
> languages should not be
> > customizable on the get/set process.  Are you
> saying that it shouldn't
> > be this high level where the customization takes
> place?  There is the
> > ExpressionParser interface as well as a possible
> entry point for
> > customization.  I'm not trying to defend this
> design, because a better
> > one probably could be crafted.  I guess the idea
> here was that you could
> > use Morph to implement whatever language you
> wanted and leverage the
> > Reflection API.  Is your argument that in some
> cases you do want the
> > facilities in these other packages, for example
> expression compilation?
> > > 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?
> > >
> > As I said before, I think we should just submit
> what you wrote up before
> > and just add an additional notes section that
> includes:
> > - Reflection mechanism is ripe for extraction,
> possibly to replace
> > commons-clazz.  Could be a powerful extension
> point for existing Jakarta
> > language libraries.
> > - Composite is a child project that we weren't
> sure if it should be
> > brought over or not because it's not as mature. 
> We're happy either way,
> > but our real focus is on Morph right now.
> >
> > Matt S
> >
> >
>
-------------------------------------------------------------------------
> > 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
> 




 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

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

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> why'd you have to break it
> out, Matt? ;)

LOL, perhaps in retrospect it wasn't the best idea.  I guess it had just 
grown in sophistication to the point where I felt it just really didn't 
belong embedded inside Morph anymore.  I knew it could cause problems if 
Morph were to try to move to Apache, but the focus of the context 
package really has nothing at all to do with the purpose of Morph, it's 
more of an implementation choice.

> .  I would say we could present the
> situation on general@jakarta, but my expectation is
> that the obvious reaction would "path of least effort"
> i.e. (C).
>   

That seems wise to me.  I don't think anyone really has interest in 
writing test cases and a reference manual for the package, and if we 
moved it to Apache we probably would have to do all that.

> >From what I can tell, Composite's completeness level
> might be pretty close to "the right level" for
> incubation, which is too say not _too_ complete.  You
> can't attract developers to, and thereby develop a
> community for, code for which there is nothing to do,
> after all.  Composite seems to specify a development
> direction and just need completion of what has already
> been specified, plus maybe one or two more niceties,
> e.g. a delegating proxy that will recursively forward
> method calls to components, perhaps.  However, does
> anyone have the "itch" to do all this ATM?  If not,
> this also recommends option (C) until someone does. 
> :|
>   

Although I use Morph all the time in my day to day coding, I've never 
used Composite for anything other than to help me implement Morph.  So I 
personally don't have this itch and I really don't know who might.  As 
you say, this seems to be another factor pointing to option C.

One thing I don't think anyone has explicitly mentioned is that there is 
the Chain package in Commons which also aims to help provide an 
implementation of a design pattern.  That might mean there is interest 
in packages that help with design patterns, or it might just mean people 
are interested in the Chain pattern.  I have no idea.

Matt S

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

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

Sorry about the delay.  Anyway, it sounds like we're
back to [] 1.  :)  I will submit Morph-proposal-take-2
to general@jakarta and we can go from there.

br,
Matt

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Matt Benson wrote:
> > why'd you have to break it
> > out, Matt? ;)
> 
> LOL, perhaps in retrospect it wasn't the best idea. 
> I guess it had just 
> grown in sophistication to the point where I felt it
> just really didn't 
> belong embedded inside Morph anymore.  I knew it
> could cause problems if 
> Morph were to try to move to Apache, but the focus
> of the context 
> package really has nothing at all to do with the
> purpose of Morph, it's 
> more of an implementation choice.
> 
> > .  I would say we could present the
> > situation on general@jakarta, but my expectation
> is
> > that the obvious reaction would "path of least
> effort"
> > i.e. (C).
> >   
> 
> That seems wise to me.  I don't think anyone really
> has interest in 
> writing test cases and a reference manual for the
> package, and if we 
> moved it to Apache we probably would have to do all
> that.
> 
> > >From what I can tell, Composite's completeness
> level
> > might be pretty close to "the right level" for
> > incubation, which is too say not _too_ complete. 
> You
> > can't attract developers to, and thereby develop a
> > community for, code for which there is nothing to
> do,
> > after all.  Composite seems to specify a
> development
> > direction and just need completion of what has
> already
> > been specified, plus maybe one or two more
> niceties,
> > e.g. a delegating proxy that will recursively
> forward
> > method calls to components, perhaps.  However,
> does
> > anyone have the "itch" to do all this ATM?  If
> not,
> > this also recommends option (C) until someone
> does. 
> > :|
> >   
> 
> Although I use Morph all the time in my day to day
> coding, I've never 
> used Composite for anything other than to help me
> implement Morph.  So I 
> personally don't have this itch and I really don't
> know who might.  As 
> you say, this seems to be another factor pointing to
> option C.
> 
> One thing I don't think anyone has explicitly
> mentioned is that there is 
> the Chain package in Commons which also aims to help
> provide an 
> implementation of a design pattern.  That might mean
> there is interest 
> in packages that help with design patterns, or it
> might just mean people 
> are interested in the Chain pattern.  I have no
> idea.
> 
> Matt S
> 
>
-------------------------------------------------------------------------
> 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
> 



 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097