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
>