morph-developer — For developers of the Morph framework. NOT for questions.

Re: [morph-developer] Help with build / Should we start a wiki?

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

> We definitely need to break down and work on Morph's
> docs, so a wiki could be useful.  Apache uses MoinMoin
> and Confluence, FWIW...
>   

Here is a script for importing into MoinMoin so if we ever move to 
Apache we won't be totally screwed if we use some other wiki solution.

http://moinmoin.wikiwikiweb.de/ScriptMarket/HTMLImportScript?highlight=%28import%29

On the other hand, I would really hate for us to have to do that ;)  I 
saw there as a nibble today on the Jakarta list, but it looks like that 
avenue is dead.  I'm sorry if you already mentioned this, but is there a 
chance we could get in through the Incubator and find a real sponsor later?

Matt S

Re: [morph-developer] Help with build / Should we start a wiki?

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

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

> Hi Matt B-
> 
> I just downloaded the latest from Morph and all the
> changes you've 
> implemented look awesome.  It's good to see someone
> go through and fix 
> some of my blundering attempts at proper
> synchronization ;)  I noticed 
> the try/finally blocks you added to the
> SimpleDelegatingTransformer as 
> well -- I wish I had thought about that!

:)

> 
> One thing I'm having trouble with is getting the new
> build to work.  I 
> can keep blundering away with it, but if you have
> any pointers or things 
> you would recommend I read to understand Ivy, etc. I
> would greatly 
> appreciate it.
>

Yeah, I thought about that only after the fact--sorry.
 I decoupled the Ivy build from the Morph build,
making both old builds work as legacy-build as you
requested.  All you need to do is:

1) Get Ivy 1.4.1 and add to $ANT_HOME/lib (there are
other ways but that's the easiest).
2) Synch Composite, and run 'ant publish' against it
3) Synch Morph, and run e.g. 'ant rebuild-all' or some
such against it

Running Composite's publish target puts an
"integration version" of Composite into your local
repository for Morph to build against... the idea
being that we should release Composite 1.0.1 and
publish somewhere like iBiblio, then Morph could/would
build against that in the wild, see?
 
> This brings me to the other subject of the email,
> which is: should we 
> start a wiki?  I'm thinking it could be more
> effective to have our 
> documentation in a wiki so that anyone can modify it
> rather than 
> basically restricting documentation modification to
> developers of 
> Morph.  I know in theory a non-developer could
> download the source, 
> submit a patch, and hope it gets excepted, but I
> think most users would 
> be much more likely to contribute to a wiki than try
> to sync with SVN to 
> make sure you're working with the latest, figure out
> where the reference 
> document source is, figure out how to prepare a
> patch for it, submit the 
> patch and watch it sit for 6 months.  Off the top of
> my head, wikia 
> (for-profit wikipedia knockoff) has free wiki
> hosting that we could 
> leverage.  Another possibility is to investigate
> what wiki software 
> Apache is using in case we ever make the move over
> there (it would suck 
> if there wasn't an automatic way to transfer the
> wiki information).  
> Spider Strategies also recently started using wiki
> software so I might 
> be able to get us our own wiki hosted on Spider
> servers using that software.
> 

We definitely need to break down and work on Morph's
docs, so a wiki could be useful.  Apache uses MoinMoin
and Confluence, FWIW...

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



 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

[morph-developer] Help with build / Should we start a wiki?

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

Hi Matt B-

I just downloaded the latest from Morph and all the changes you've 
implemented look awesome.  It's good to see someone go through and fix 
some of my blundering attempts at proper synchronization ;)  I noticed 
the try/finally blocks you added to the SimpleDelegatingTransformer as 
well -- I wish I had thought about that!

One thing I'm having trouble with is getting the new build to work.  I 
can keep blundering away with it, but if you have any pointers or things 
you would recommend I read to understand Ivy, etc. I would greatly 
appreciate it.

This brings me to the other subject of the email, which is: should we 
start a wiki?  I'm thinking it could be more effective to have our 
documentation in a wiki so that anyone can modify it rather than 
basically restricting documentation modification to developers of 
Morph.  I know in theory a non-developer could download the source, 
submit a patch, and hope it gets excepted, but I think most users would 
be much more likely to contribute to a wiki than try to sync with SVN to 
make sure you're working with the latest, figure out where the reference 
document source is, figure out how to prepare a patch for it, submit the 
patch and watch it sit for 6 months.  Off the top of my head, wikia 
(for-profit wikipedia knockoff) has free wiki hosting that we could 
leverage.  Another possibility is to investigate what wiki software 
Apache is using in case we ever make the move over there (it would suck 
if there wasn't an automatic way to transfer the wiki information).  
Spider Strategies also recently started using wiki software so I might 
be able to get us our own wiki hosted on Spider servers using that software.

Matt S

Re: [morph-developer] Damn Verizon

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

Pow!  I couldn't even be troubled to do an inline
post.  The "projection" thing you mention is inherent
to JXPATH--hadn't noticed it when I've played with
OGNL.  One thing about OGNL is its almost utter lack
of support.  I know JXPATH is supported because I'm
its "curator."  ;)  And I'm pretty sure JXPATH could
support Morph reflectors _now_.  I'll try it sometime.

-MB

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

> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> Comments inline....
> >>     
> >>> :)  I think making expressions perfectly safe
> for
> >>>       
> >> this
> >>     
> >>> copier will require more knowledge of how the
> >>> expression is parsed, along the lines of my
> >>> earlier-voiced thoughts about expressions in
> >>>       
> >> Morph. 
> >>     
> >>> Maybe I'll try to cook up a BC implementation of
> >>>       
> >> this.
> >>     
> >>>   
> >>>       
> >> One of my original frustrations with BeanUtils is
> >> when it encountered 
> >> something unexpected it would blowup at you and
> ruin
> >> your day.  With 
> >> Morph I strove to just silently fail where
> possible
> >> and only throw 
> >> exceptions when something really boneheaded
> happened
> >> (like trying to 
> >> convert "hello world!" to an Integer).
> >>
> >> I'm pretty sure what will happen if you enter a
> >> totally bogus expression 
> >> is you'll get a blowup.  If you enter an
> expression
> >> for an object path 
> >> and a null is encountered part way through, I'm
> >> pretty sure a null will 
> >> just be returned.
> >>
> >> Don't be intimidated by the expression parsing
> >> stuff, it's really very 
> >> trivial (in fact SimpleExpressionParser has less
> >> than a dozen lines of 
> >> code).  Basically the expression parser is just a
> >> StringTokenizer that 
> >> looks for symbols usually found in languages like
> .
> >> [ ] ( ) and then 
> >> just treats them all as word breaks.  So
> >> something.funky]like[this in 
> >> Morph is equivalent to something.funky.like.this
> in
> >> a more strict 
> >> language like JSTL.  Why be so strict with your
> >> syntax when the whole 
> >> point of this new syntax (as opposed to strongly
> >> typed Java calls) is to 
> >> ignore types and make things easier on yourself?
> ;)
> >>
> >>     
> >
> > I'm not sure... I understand what you're saying,
> but
> > somehow I can't rid myself of this feeling that
> _some_
> > structure might be a good thing.  I'll let you
> know if
> > I come up with anything concrete.  In the meantime
> I
> > still can't see the harm in refactoring some
> things
> > while retaining the SL functionality... :)
> >   
> This was actually a design choice.  Why make a
> distinction between a 
> collection and a bean?  The only real difference
> between the two is that 
> a collection happens to have property names that are
> numbers instead of 
> words.  IMO the distinction made in other languages
> is an implementation 
> crutch rather than a useful feature.  If someone
> wants to write 
>
my[[[[[[[[[[really[[[[[[[[[[[[[[[[[[obnoxious.[][][][][path
> then they 
> are being obnoxious on purpose.  I expect most
> people are going to go 
> for a.not.obnoxious.path.  And you also have the
> option of being strict 
> if you want with object.listProperty[myIndex].  The
> nice thing about 
> SimpleLanguage is it implements JSTL EL, Velocity
> and many other untyped 
> languages so that you can take existing expressions
> and just plug it 
> into Morph and it will work.  You can also write new
> expressions with 
> whatever syntax are comfortable with.
> 
> The one big thing this functionality is missing is
> the stuff you can do 
> with OGNL like projections.  I haven't looked into
> that library too 
> much, but here's one feature I find really
> appealing.  Say we have a 
> list of People called employeeDirectory.  Then you
> can do 
> "employeeDirectory.address.street" and get a List of
> street address.  I 
> believe this is called projection and is a feature
> in OGNL.  Again here 
> it doesn't seem like you would need to have any
> syntax difference 
> between a projection and a regular query on an
> object graph.  Just use 
> reflectors to figure out, oh, employeeDirectory is a
> collection and its 
> members all have an address property, so I'll go get
> the addresses for 
> each of these people.  Perhaps in this case where
> you are doing a 
> different type of operation than normal I could
> justify a syntax 
> difference.  Retrieving a property from an object
> vs. retrieving an 
> object at specific index in a collection is not a
> significant enough 
> difference to justify different syntax, IMO.
> 
> If we could get OGNL to base some of their stuff off
> Morph I would be 
> very happy to deprecate the Language code in Morph. 
> OGNL is much more 
> capable, but some of its interfaces are kind of
> ugly.  I know its 
> Transformer interface has a half dozen parameters.
> 
> 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
> 



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: [morph-developer] Damn Verizon

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

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> Comments inline....
>>     
>>> :)  I think making expressions perfectly safe for
>>>       
>> this
>>     
>>> copier will require more knowledge of how the
>>> expression is parsed, along the lines of my
>>> earlier-voiced thoughts about expressions in
>>>       
>> Morph. 
>>     
>>> Maybe I'll try to cook up a BC implementation of
>>>       
>> this.
>>     
>>>   
>>>       
>> One of my original frustrations with BeanUtils is
>> when it encountered 
>> something unexpected it would blowup at you and ruin
>> your day.  With 
>> Morph I strove to just silently fail where possible
>> and only throw 
>> exceptions when something really boneheaded happened
>> (like trying to 
>> convert "hello world!" to an Integer).
>>
>> I'm pretty sure what will happen if you enter a
>> totally bogus expression 
>> is you'll get a blowup.  If you enter an expression
>> for an object path 
>> and a null is encountered part way through, I'm
>> pretty sure a null will 
>> just be returned.
>>
>> Don't be intimidated by the expression parsing
>> stuff, it's really very 
>> trivial (in fact SimpleExpressionParser has less
>> than a dozen lines of 
>> code).  Basically the expression parser is just a
>> StringTokenizer that 
>> looks for symbols usually found in languages like .
>> [ ] ( ) and then 
>> just treats them all as word breaks.  So
>> something.funky]like[this in 
>> Morph is equivalent to something.funky.like.this in
>> a more strict 
>> language like JSTL.  Why be so strict with your
>> syntax when the whole 
>> point of this new syntax (as opposed to strongly
>> typed Java calls) is to 
>> ignore types and make things easier on yourself? ;)
>>
>>     
>
> I'm not sure... I understand what you're saying, but
> somehow I can't rid myself of this feeling that _some_
> structure might be a good thing.  I'll let you know if
> I come up with anything concrete.  In the meantime I
> still can't see the harm in refactoring some things
> while retaining the SL functionality... :)
>   
This was actually a design choice.  Why make a distinction between a 
collection and a bean?  The only real difference between the two is that 
a collection happens to have property names that are numbers instead of 
words.  IMO the distinction made in other languages is an implementation 
crutch rather than a useful feature.  If someone wants to write 
my[[[[[[[[[[really[[[[[[[[[[[[[[[[[[obnoxious.[][][][][path then they 
are being obnoxious on purpose.  I expect most people are going to go 
for a.not.obnoxious.path.  And you also have the option of being strict 
if you want with object.listProperty[myIndex].  The nice thing about 
SimpleLanguage is it implements JSTL EL, Velocity and many other untyped 
languages so that you can take existing expressions and just plug it 
into Morph and it will work.  You can also write new expressions with 
whatever syntax are comfortable with.

The one big thing this functionality is missing is the stuff you can do 
with OGNL like projections.  I haven't looked into that library too 
much, but here's one feature I find really appealing.  Say we have a 
list of People called employeeDirectory.  Then you can do 
"employeeDirectory.address.street" and get a List of street address.  I 
believe this is called projection and is a feature in OGNL.  Again here 
it doesn't seem like you would need to have any syntax difference 
between a projection and a regular query on an object graph.  Just use 
reflectors to figure out, oh, employeeDirectory is a collection and its 
members all have an address property, so I'll go get the addresses for 
each of these people.  Perhaps in this case where you are doing a 
different type of operation than normal I could justify a syntax 
difference.  Retrieving a property from an object vs. retrieving an 
object at specific index in a collection is not a significant enough 
difference to justify different syntax, IMO.

If we could get OGNL to base some of their stuff off Morph I would be 
very happy to deprecate the Language code in Morph.  OGNL is much more 
capable, but some of its interfaces are kind of ugly.  I know its 
Transformer interface has a half dozen parameters.

Matt S

Re: [morph-developer] Damn Verizon

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

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

> Comments inline....
> > :)  I think making expressions perfectly safe for
> this
> > copier will require more knowledge of how the
> > expression is parsed, along the lines of my
> > earlier-voiced thoughts about expressions in
> Morph. 
> > Maybe I'll try to cook up a BC implementation of
> this.
> >   
> One of my original frustrations with BeanUtils is
> when it encountered 
> something unexpected it would blowup at you and ruin
> your day.  With 
> Morph I strove to just silently fail where possible
> and only throw 
> exceptions when something really boneheaded happened
> (like trying to 
> convert "hello world!" to an Integer).
> 
> I'm pretty sure what will happen if you enter a
> totally bogus expression 
> is you'll get a blowup.  If you enter an expression
> for an object path 
> and a null is encountered part way through, I'm
> pretty sure a null will 
> just be returned.
> 
> Don't be intimidated by the expression parsing
> stuff, it's really very 
> trivial (in fact SimpleExpressionParser has less
> than a dozen lines of 
> code).  Basically the expression parser is just a
> StringTokenizer that 
> looks for symbols usually found in languages like .
> [ ] ( ) and then 
> just treats them all as word breaks.  So
> something.funky]like[this in 
> Morph is equivalent to something.funky.like.this in
> a more strict 
> language like JSTL.  Why be so strict with your
> syntax when the whole 
> point of this new syntax (as opposed to strongly
> typed Java calls) is to 
> ignore types and make things easier on yourself? ;)
> 

I'm not sure... I understand what you're saying, but
somehow I can't rid myself of this feeling that _some_
structure might be a good thing.  I'll let you know if
I come up with anything concrete.  In the meantime I
still can't see the harm in refactoring some things
while retaining the SL functionality... :)

> Then for the Language implementation we just
> traverse the object graph 
> in a loop and try our best to get what was
> requested:
> 
> public Object getImpl(Object target, String
> expression) throws Exception {
>     if (ObjectUtils.isEmpty(expression)) {
>         return target;
>     }
> 
>     Object value = target;
>    
>     String[] tokens =
> expressionParser.parse(expression); // { 
> "something", "funky", "like", "this" }
>     for (int i=0; i<tokens.length; i++) {
>         String token = tokens[i];
>         if (value == null) { // just return null, no
> blowup
>             return null;
>         }
>         value = getReflector().get(value, token); //
> yay found 
> something!  go get it
>     }
>    
>     return value;
> }
> 
> > Oh, and I forgot to say before that yes, I will
> > probably be grateful for help with jots and
> tittles
> > wrt the release.  And just to be sure we're on the
> > same page, we're talking 1.0.1, correct?
> >   
> Actually I released 1.0.1 last year but never
> updated the homepage since 
> it's such a huge PITA.  Next could be 1.0.2 but even
> if it's still in 
> the sandbox your new stuff might merit a 1.1
> designation ;)  Up to you...

Ah, didn't even see that.  Maybe 1.0.2 until DSL
leaves sandbox, meaning that if we determine it's
already ready for prime time we can go 1.1?

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



 
____________________________________________________________________________________
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] Damn Verizon

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

Comments inline....
> :)  I think making expressions perfectly safe for this
> copier will require more knowledge of how the
> expression is parsed, along the lines of my
> earlier-voiced thoughts about expressions in Morph. 
> Maybe I'll try to cook up a BC implementation of this.
>   
One of my original frustrations with BeanUtils is when it encountered 
something unexpected it would blowup at you and ruin your day.  With 
Morph I strove to just silently fail where possible and only throw 
exceptions when something really boneheaded happened (like trying to 
convert "hello world!" to an Integer).

I'm pretty sure what will happen if you enter a totally bogus expression 
is you'll get a blowup.  If you enter an expression for an object path 
and a null is encountered part way through, I'm pretty sure a null will 
just be returned.

Don't be intimidated by the expression parsing stuff, it's really very 
trivial (in fact SimpleExpressionParser has less than a dozen lines of 
code).  Basically the expression parser is just a StringTokenizer that 
looks for symbols usually found in languages like . [ ] ( ) and then 
just treats them all as word breaks.  So something.funky]like[this in 
Morph is equivalent to something.funky.like.this in a more strict 
language like JSTL.  Why be so strict with your syntax when the whole 
point of this new syntax (as opposed to strongly typed Java calls) is to 
ignore types and make things easier on yourself? ;)

Then for the Language implementation we just traverse the object graph 
in a loop and try our best to get what was requested:

public Object getImpl(Object target, String expression) throws Exception {
    if (ObjectUtils.isEmpty(expression)) {
        return target;
    }

    Object value = target;
   
    String[] tokens = expressionParser.parse(expression); // { 
"something", "funky", "like", "this" }
    for (int i=0; i<tokens.length; i++) {
        String token = tokens[i];
        if (value == null) { // just return null, no blowup
            return null;
        }
        value = getReflector().get(value, token); // yay found 
something!  go get it
    }
   
    return value;
}

> Oh, and I forgot to say before that yes, I will
> probably be grateful for help with jots and tittles
> wrt the release.  And just to be sure we're on the
> same page, we're talking 1.0.1, correct?
>   
Actually I released 1.0.1 last year but never updated the homepage since 
it's such a huge PITA.  Next could be 1.0.2 but even if it's still in 
the sandbox your new stuff might merit a 1.1 designation ;)  Up to you...

Matt S

Re: [morph-developer] Damn Verizon

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

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

> Matt Benson wrote:
> > I have a
> > vague ambition to accomplish the site generation
> > without having to use Maven, but I haven't
> > investigated what is needed for this.
> >   
> I hate Maven, so I'm all for this change.

Whew!  Me, too... since I'm on the Ant PMC I would say
that anyway, but I really do!

>  I'm sure
> my hatred is 
> irrational and I just need a bit more kool-aid to
> see things straight 
> but personally I'd rather tell my tools how I want
> to organize my 
> project, not the other way around.  Anyway, that
> would seem worthwhile.  

Exactly, I guess I don't much care for black boxes.

> You may or may not have noticed but I actually
> generate the website by 
> having ant call Maven because I could never get
> Maven to behave.

Yeah, that's what I'm still doing with my reworked
build.

> > I was going to check it into the sandbox even
> though
> > I'm developing my current project against it. 
> After
> > you've had a look I think it might want to go to
> core,
> > but the main thing keeping me from doing that just
> yet
> > is this:  to be competitive, the DSL defined
> copier
> > really ought to be able to handle nested
> properties,
> > i.e. expressions.  I have cloned
> > PropertyNameMappingCopier to
> > PropertyExpressionMappingCopier which uses a
> Language,
> > but I think it will break if it hits intervening
> null
> > properties, for example (I haven't actually tested
> > that).  I'd like to address this eventually.  What
> we
> > could do is go ahead and add to core but accept a
> > Properties object of extra settings so that it can
> > recognize an experimental "useExpressions" setting
> > (without actually putting this in the API);
> default to
> > false and use PropertyNameMappingCopiers but if
> true,
> > use PropertyExpressionMappingCopiers.  This would
> > allow us to put the safe part (that will probably
> > cover more use cases than not) in core while
> making
> > the less stable territory a conscious choice on
> the
> > part of the user.
> >   
> IMO you might as well just introduce it in the
> sandbox.  This way you 
> get to have your cake and eat it to: you declare
> it's not ready for 
> prime (which takes a lot of pressure off you) while
> simultaneously 
> making it accessible so other people *can* use it
> (so we can get feedback).
> 

That's the way I've been using it, in a sandbox jar.

> I would just bake expressions directly into this
> with no config option.  
> No expressions would be like using a Spring
> application context but not 
> making use of dependency injection!
> 

:)  I think making expressions perfectly safe for this
copier will require more knowledge of how the
expression is parsed, along the lines of my
earlier-voiced thoughts about expressions in Morph. 
Maybe I'll try to cook up a BC implementation of this.

Oh, and I forgot to say before that yes, I will
probably be grateful for help with jots and tittles
wrt the release.  And just to be sure we're on the
same page, we're talking 1.0.1, correct?

-MB (meaningless J omitted)

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



 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

Re: [morph-developer] Damn Verizon

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

Matt Benson wrote:
> I have a
> vague ambition to accomplish the site generation
> without having to use Maven, but I haven't
> investigated what is needed for this.
>   
I hate Maven, so I'm all for this change.  I'm sure my hatred is 
irrational and I just need a bit more kool-aid to see things straight 
but personally I'd rather tell my tools how I want to organize my 
project, not the other way around.  Anyway, that would seem worthwhile.  
You may or may not have noticed but I actually generate the website by 
having ant call Maven because I could never get Maven to behave.
> I was going to check it into the sandbox even though
> I'm developing my current project against it.  After
> you've had a look I think it might want to go to core,
> but the main thing keeping me from doing that just yet
> is this:  to be competitive, the DSL defined copier
> really ought to be able to handle nested properties,
> i.e. expressions.  I have cloned
> PropertyNameMappingCopier to
> PropertyExpressionMappingCopier which uses a Language,
> but I think it will break if it hits intervening null
> properties, for example (I haven't actually tested
> that).  I'd like to address this eventually.  What we
> could do is go ahead and add to core but accept a
> Properties object of extra settings so that it can
> recognize an experimental "useExpressions" setting
> (without actually putting this in the API); default to
> false and use PropertyNameMappingCopiers but if true,
> use PropertyExpressionMappingCopiers.  This would
> allow us to put the safe part (that will probably
> cover more use cases than not) in core while making
> the less stable territory a conscious choice on the
> part of the user.
>   
IMO you might as well just introduce it in the sandbox.  This way you 
get to have your cake and eat it to: you declare it's not ready for 
prime (which takes a lot of pressure off you) while simultaneously 
making it accessible so other people *can* use it (so we can get feedback).

I would just bake expressions directly into this with no config option.  
No expressions would be like using a Spring application context but not 
making use of dependency injection!

Matt S

Re: [morph-developer] Damn Verizon

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

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

> Hi Matt B - I just caught up with your posts to the
> morph-developers 
> list of the last week.  To make a long story short,
> Verizon deleted all 
> my email for the last week so I had to head on over
> to the SF site to 
> find your emails.

Well!  I was starting to wonder what happened to you,
so I'll echo your damnation of Verizon completely on
your behalf.

> 
> I just granted you full rights on SF (it looks like
> you may have even 
> more than me!  lol).  If you are lacking any needed
> privileges, let me 
> know.  I don't know if I mentioned this before, but
> the only reason I 
> hadn't already done this was because I went in to
> try to do it but 
> didn't know your UNIX name.

Don't recall that.  Thanks!

> 
> Regarding build process, no objections here. 
> Perhaps we can keep the 
> old build around as legacy-build.xml, if only for my
> benefit?
> 

Will do.  One thing is that the ivy build retrieves
dependencies for the various build types, so on one
hand it's similar to the structure in which you
currently have jars stored under /lib.  On the other
hand, it differs because the libs aren't stored in
RCS.  I will use a different directory for now on the
ivy build, and that way you'll be able to try it out
before we completely switch (or we could continue
indefinitely supporting both approaches).  I have a
vague ambition to accomplish the site generation
without having to use Maven, but I haven't
investigated what is needed for this.

> When are you gearing up for release?  Before you do
> I will try to catch 
> up with the changes you made to the core.  If you
> have never done a SF 
> release before I can assist with this.

Maybe in the next 2 months at latest?

> 
> Question - is the DSL stuff you're working on
> targeted for release as 
> part of the sandbox or as part of the main source? 
> Just curious, I'm 
> sure whatever you decide is fine :)
> 

I was going to check it into the sandbox even though
I'm developing my current project against it.  After
you've had a look I think it might want to go to core,
but the main thing keeping me from doing that just yet
is this:  to be competitive, the DSL defined copier
really ought to be able to handle nested properties,
i.e. expressions.  I have cloned
PropertyNameMappingCopier to
PropertyExpressionMappingCopier which uses a Language,
but I think it will break if it hits intervening null
properties, for example (I haven't actually tested
that).  I'd like to address this eventually.  What we
could do is go ahead and add to core but accept a
Properties object of extra settings so that it can
recognize an experimental "useExpressions" setting
(without actually putting this in the API); default to
false and use PropertyNameMappingCopiers but if true,
use PropertyExpressionMappingCopiers.  This would
allow us to put the safe part (that will probably
cover more use cases than not) in core while making
the less stable territory a conscious choice on the
part of the user.

WDYT?
-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
> 



 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

[morph-developer] Damn Verizon

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

Hi Matt B - I just caught up with your posts to the morph-developers 
list of the last week.  To make a long story short, Verizon deleted all 
my email for the last week so I had to head on over to the SF site to 
find your emails.

I just granted you full rights on SF (it looks like you may have even 
more than me!  lol).  If you are lacking any needed privileges, let me 
know.  I don't know if I mentioned this before, but the only reason I 
hadn't already done this was because I went in to try to do it but 
didn't know your UNIX name.

Regarding build process, no objections here.  Perhaps we can keep the 
old build around as legacy-build.xml, if only for my benefit?

When are you gearing up for release?  Before you do I will try to catch 
up with the changes you made to the core.  If you have never done a SF 
release before I can assist with this.

Question - is the DSL stuff you're working on targeted for release as 
part of the sandbox or as part of the main source?  Just curious, I'm 
sure whatever you decide is fine :)

Matt S

[morph-developer] onward

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

This follows up my "build process" email, which has
generated no response.  :|  As of now incubation @ ASF
isn't looking too good.  Jakarta proposal was met with
no opposition, but no interest either.  I doubt
escalating to the Incubator PMC will be any more
fruitful as a large proportion of the folks there are
present on general@jakarta, so the time is drawing
near to press on.  We need to work on releases!  I'd
like to commit my (drastic) changes to the build
process; I believe I have the process of building a
release pretty close to complete.  I'd also like to be
added to the sf project as a project admin (user
orangeherbert), to be in a position to make a release
in the near future.  Finally, I'd like to commit my
sandbox DSL-based code for discussion.

In short, now that we are reasonably sure we won't
have any support from the ASF in maturing Morph, we
need to take charge and do it ourselves.  With admin
rights on sf I would like to drive this since I know
you, Matt S, currently lack the time.

-Matt B


 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097

[morph-developer] build process

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

With Morph hopefully moving to the ASF, it needs IMO
to have its build decoupled from Composite.  One
interesting thing I had seen several months back was
the way the Spring guys handle some of their projects
(e.g. webflow, beans, etc.).  They were using Ivy (I
believe Colin Samplaneau got a lot of this going) to
manage their project dependencies and one thing they
got from this was a fairly simple way to pick up
current local development builds of other projects. 
With this in mind I have used my Ant-fu to rework
Morph (and Composite)'s buildfile(s) to use Ivy to
manage dependencies, along with other (IMHO)
improvements, but I have not checked any of this work
in.  Does this sound like a direction worth exploring?

-Matt B


 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

[morph-developer] Morph proposal

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

Morph's incubation proposal follows, sent here first
in an effort to gain the sponsorship of Jakarta, and
possibly to attract mentors as well.  :)  Thanks!

Morph defines a comprehensive API for performing
object-to-object conversions in
Java.

PROPOSAL


BACKGROUND/RATIONALE

  As information flows through an application, it
undergoes multiple transformations.  While the most
prevalent examples of this in the J2EE space are
well-known (e.g. HTTP request parameters to
domain/data transfer objects, DTOs to domain objects)
the overall problem space is characterized by the lack
of a simple, well-known, conveniently extensible
solution.  At least one JSR (295) describes such a
facility as a dependency.  Having identified the basic
commonalities among the best known application
operations requiring object conversion, Morph
consolidates these into a single API which, along with
various bundled implementation classes, seeks to
achieve the oft-repeated software development goal of
making "the simple things easy, and the hard things
possible" with regard to its problem domain.


CURRENT STATUS

Meritocracy:
  The Morph team is eager to invest more fully in the
meritocracy approach taken by the ASF.  To date,
however, Morph's development team has been accumulated
by a sort of "meritocracy-on-spec" approach:  Matt
Benson was originally given
commit rights solely on the basis of his ideas; only
later did his work vindicate that decision.  [If
sponsored by Jakarta:  This is a similar approach
to that taken in the Jakarta community:  a community
member simply announces his desire to work on a
component, then proceeds with the community's
blessing.]

Community:
  It is somewhat difficult to gauge the size of
Morph's community.  There have been modest but
consistent downloads of the project since its initial
prerelease:  these average 21/month over 28 months. 
The traffic on its user and developer lists is
similarly light, but several bug fixes and
enhancements have resulted from the input of Morph's
users.  An additional possible benefit of
Morph's joining the Apache community is that increased
cooperation with and buy-in from other ASF projects
may increase its user and/or developer communities.

Core Developers:
  Matt Sgarlata is Morph's founding architect and
developer.  He has been a member of the Jakarta and
Struts user communities for some years.  Matt Benson
is a member of the Apache Ant PMC and a Jakarta
committer, so is familiar with (and fond of) the
consensus and transparency encouraged in ASF
development.

Alignment:
  Morph currently contains interoperability code for
commons-beanutils, commons-chain, and Velocity. 
Because it is Morph's secondary purpose to provide
implementations of common conversions, code that
facilitates Morph's use with well-known libraries in
easily anticipated ways is considered in-scope.  As
has already been implied, it is expected that
citizenship at the ASF would facilitate cooperation
with existing projects to mutal benefit.  Finally,
precedent demonstrating the desirability of such a
project at Apache exists in the form of Jakarta
commons-convert (this component ultimately failed to
achieve maturity).  Morph's original design
specifications are actually the generic
subset of those drafted on the commons-dev mailing
list as a next-generation implementation of this
project.


KNOWN RISKS

Orphaned Products:
  The Morph developers are part of its user base. 
Object conversion may be relevant to any of various
components of a basic Java application.  The risk of
"itch cessation" is therefore minimized; Morph should
continue to be an applicable technology at low risk
for being abandoned by its developers.

Inexperience with Open Source:
  As previously indicated, one of the initial
committers has some years of experience as a committer
and PMC member at the ASF.  Additionally, Morph has
always been open-source software, with its evolution
being directly guided by user input and developer
consensus in similar fashion to other Apache projects.

Homogenous Developers:
  On the plus side, the initial committers are united
only by their common interest in Morph (and their
coincidental first names and middle initials).
However, both hail from the United States, and
acknowledge this as a less-than-optimal level of
diversity.  As Java Locale support is a key strength
of Morph's transformation API, wider geographical
dispersal would be a boon.  The inevitable input of
the ASF's diverse community could only be of positive
influence in this regard.

Reliance on Salaried Developers:
  The core developers use Morph in their own paid
development jobs, but are not paid to develop Morph
per se.  Withdrawal of support is not an issue from
this perspective.

No Ties to Other Apache Products:
  As described in the Alignment section, this library
already has ties to many Apache products. 
Additionally, Morph's codebase is already licensed
under the Apache Software License v2.0.

A Fascination with the Apache Brand:
  While "Apache" undeniably marks a project as a force
to be reckoned with, the Morph team is more impressed
by the ASF's organization, procedure, community,
transparency, and camaraderie than anything else. 
Morph's developers share a
high opinion of Apache software in general, and
believe that Morph is of sufficient quality and purity
that it simply "belongs" at the ASF.


DOCUMENTATION

  More information about Morph is available at
http://morph.sourceforge.net .


INITIAL SOURCE

  The initial code base is at
svn://development.spiderstrategies.com/morph .


EXTERNAL DEPENDENCIES

  Mandatory runtime dependencies are:

  - Apache Jakarta commons-logging
  - Composite @ http://composite.sourceforge.net
(ASL2)

  Additionally Morph has the following compile-time
dependencies:

  - Apache Jakarta commons-beanutils
  - Apache Jakarta commons-chain
  - Apache Velocity
  - J2EE Servlet API
  - Spring Framework (ASL2)

  Finally, Morph's test bed currently relies on Apache
Jakarta commons-lang, and will soon include code that
depends on the public domain ANTLR 2 parser library.


REQUIRED RESOURCES

Mailing Lists:
  (Return to this subject after a sponsor is found)

Subversion Directory:
  (Return to this subject after a sponsor is found)

Issue Tracking:
  (Return to this subject after a sponsor is found)


INITIAL COMMITTERS

  - Matt Sgarlata (matthew DOT sgarlata DOT wh02 AT
wharton DOT upenn DOT edu)
  - Matt Benson (mbenson AT apache DOT org)


AFFILIATIONS

  Morph has no corporate affiliations.  Matt Sgarlata
is employed by Spider Strategies, who have graciously
agreed to host Morph's Subversion repository (due to
ongoing problems experienced with Sourceforge.net
infrastructure); this is the extent of the claim
Spider Strategies makes on the Morph project (i.e.
none).  The current source code correctly lists the
copyright holder as "the original author or authors." 
In case the intellectual property provenance is still
unclear (due to Spider Strategies' physical possession
of the code
repository), the company has indicated its willingness
to sign any required documentation indicating that it
holds no claims whatsoever over Morph, its source
code, or any related electronic information.


SPONSORS

Champion:  Niall Pemberton

Nominated Mentors:  TBD

Sponsoring Entity:  TBD


March 28, 2007



 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

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

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

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

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

[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:
>   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...>]

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

[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 S. <Mat...@wh...>]

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

Matt S

[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