Agreed. Please don't mis-interpret my replies - I'm not trying to "own"
the sandbox, I just want everyone to have a chance to play in it.
The recent interest in Convert is great - I hope its popularity and
usefulness grows. I'm truly looking forward to more people getting involved.
The current code base started out as a work I authored for the Apache
Open For Business Project (OFBiz). The converter framework was used for
OFBiz's scripting language. My initial work was built out and improved
upon by an excellent team of developers. When the converter framework
was fairly complete, someone suggested that OFBiz "spin off" the
converter framework to a separate library - so I brought it here to Commons.
The code you see today is currently being used in an enterprise-class
open source ERP application. It is scalable and thread-safe.
Commons Convert has not been "fed back" to the OFBiz project yet because
it is still in the sandbox. Until a decent sized community grows around
it, the OFBiz community will not be willing to switch over to it. I hope
to see that switch happen someday.
-Adrian
On 11/4/2011 11:33 AM, James Carman wrote:
A branch would work just fine for that situation. Also, let's keep in mind
that this component is in the sandbox
On Nov 4, 2011 7:28 AM, "Adrian Crum"<adrian.c...@sandglass-software.com>
wrote:
Not so that someone else can commit them, so that others can review them
and comment on them.
-Adrian
On 11/4/2011 11:25 AM, James Carman wrote:
If need be, I would just create a branch for my work. It would be silly
for me to submit patches so that someone else would commit them
On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
software.com<adrian.c...@sandglass-software.com>>
wrote:
From my perspective, it would be preferable to keep the community
involved
in the design decisions.
-Adrian
On 11/4/2011 11:15 AM, James Carman wrote:
I don't have to submit a patch. I am a commons committer
On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
software.com<adrian.crum@**sandglass-software.com<adrian.c...@sandglass-software.com>
wrote:
The source and target classes are used by the Converter.canConvert
method.
The Converter.canConvert method is used by the Converter factory to
find
the correct converter. The reason parameterized types are not used in
this
scenario is so you can create converters that handle entire class
hierarchies. If you can think of a way to replace the Class references
with
parameters, that would be great. Submit a patch and I will look it
over.
You could submit a patch for your partially-completed ConverterChain
class
and maybe someone else will complete it.
-Adrian
On 11/4/2011 2:19 AM, James Carman wrote:
I was taking a look at the [convert] component because I have done
some work lately on some handy conversion classes. I'm struggling to
understand why you'd need the getSourceClass() and getTargetClass()
methods if you're using generics.
Also, I've got a class that looks like this:
public class ConverterChain<S,T> implements Converter<S,T>
{
public static<S> ConverterChain<S,S> from(Class<S>
sourceType);
public<N> ConverterChain<S,N> append(Converter<T,N>
converter);
...
}
I'd like to contribute it, but in my library, I don't have all of
those references to the class objects (source/target). I might check
it in without the source/target stuff implemented.
------------------------------******--------------------------**--**
--**---------
To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
http://apache.org**>
<dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
------------------------------******--------------------------**--**
--**---------
To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
http://apache.org**>
<dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
------------------------------****----------------------------**
--**---------
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apac**he.org<http://apache.org>
<dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
