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