commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: [sandbox] Component ideas
Date Fri, 07 Mar 2008 21:30:46 GMT
On Wed, Mar 5, 2008 at 2:26 PM, Matt Benson <> wrote:
> My component ideas:
>  * I am still interested in incubating Morph as another
>  shot at Commons-convert, though I'm not sure how it
>  will be received given its overlap with BeanUtils, to
>  which Niall has been giving quite some attention
>  lately.

It'd be interesting to know if Niall still thinks BeanUtils has lots
of life. I was pondering MethodUtils the other day and how it 'should'
be in Lang [I was looking for invokeStaticMethod in Lang and after a
while realized it was in Beanutils].

+1 to the idea of Morph. It's gone further than Convert did.

>  * I am for all intents and purposes clear to release a
>  flat file processing library I have developed for my
>  employer.  I'll follow up with a code dump soon, but
>  the basic idea is that many Java developers still have
>  to deal with flat file I/O for integration with legacy
>  systems, and until the recent release of the Spring
>  batch stuff I had never seen the problem addressed
>  with any great amount of thought.  My package includes
>  a DSL declaration language for flat files that is
>  superficially akin to COBOL copybooks, that being my
>  language of origin, so to speak.  It also implements
>  Morph's *Reflector interfaces for easy transformation
>  to/from Java object graphs.

Probably replaces a tiny bit I had then :)

again, +1.

>  * Finally, I'd like to create a component whose
>  principal component is a DSL interpreter for tersely
>  represented Java object mappings.  I haven't finished
>  planning the entire model, but my intent is to tie an
>  object parsing context to an arbitrary Map instance.
>  This would be a from-scratch reimplementation of
>  another $work project, whose source code I will also
>  be free to release, but it is my belief that only
>  certain small pieces of that existing code (probably <
>  5 classes) would be necessary for the rewrite.
>  Because of this I'm not sure if this is more a sandbox
>  with a grant of some code that -might- be used, or an
>  incubating project with a beginning "scratch"
>  codebase.  IF we get something along the lines of
>  Incubator Commons as discussed the distinction might
>  not be very significant.

Grant and Sandbox I think.

With an Incubator Commons, I think an expectation would be that there
was not lots of development to do for a 1.0.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message