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