[BeanUtils] Plans for BeanUtils and BeanUtils2

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[BeanUtils] Plans for BeanUtils and BeanUtils2

Benedikt Ritter-4
Hi,

I'd like to discuss how the development of [BeanUtils] and [BeanUtils2] can
be continued.

The last release of BeanUtils (1.8.3) is now nearly 3 years ago and there
are 92 open issues in JIRA.
OTOH we've put quiet some effort into [BeanUtils2]. There are some issues
that have to be addressed* but the API is in a good shape.
But [BeanUtils2] is also a complete redesign of the API that is binary
incompatible with [BeanUtils].

Keeping this in mind I propose the following:
- promote [BeanUtils2] to proper; move it to a 2.0 branch in the beanutils
svn subtree.**
- fix all issues that can be fixed without breaking BC in [BeanUtils] to
push out a last bug fix release for users that don't want to swtich to a
new API.
- Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x line.

WDYT?

Benedikt

* Some JavaDoc is still missing and we have to take a look at the caching.
AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
discuss this in a separate thread.
** I don't know the exact formal process for this. What has to be done to
promote a component to proper? Does there have to be a formal vote by the
PMC?


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Benedikt Ritter-4
2013/2/17 Benedikt Ritter <[hidden email]>

> Hi,
>
> I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
> can be continued.
>
> The last release of BeanUtils (1.8.3) is now nearly 3 years ago and there
> are 92 open issues in JIRA.
> OTOH we've put quiet some effort into [BeanUtils2]. There are some issues
> that have to be addressed* but the API is in a good shape.
> But [BeanUtils2] is also a complete redesign of the API that is binary
> incompatible with [BeanUtils].
>
> Keeping this in mind I propose the following:
> - promote [BeanUtils2] to proper; move it to a 2.0 branch in the beanutils
> svn subtree.**
> - fix all issues that can be fixed without breaking BC in [BeanUtils] to
> push out a last bug fix release for users that don't want to swtich to a
> new API.
> - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
> line.
>
> WDYT?
>
> Benedikt
>
> * Some JavaDoc is still missing and we have to take a look at the caching.
> AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
> discuss this in a separate thread.
> ** I don't know the exact formal process for this. What has to be done to
> promote a component to proper? Does there have to be a formal vote by the
> PMC?
>
>
More than 72 hours have passed with no reply. Nobody interested in
BeanUtils anymore?


>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Jörg Schaible-3
In reply to this post by Benedikt Ritter-4
Hi Benedikt,

Benedikt Ritter wrote:

> Hi,
>
> I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
> can be continued.
>
> The last release of BeanUtils (1.8.3) is now nearly 3 years ago and there
> are 92 open issues in JIRA.
> OTOH we've put quiet some effort into [BeanUtils2]. There are some issues
> that have to be addressed* but the API is in a good shape.
> But [BeanUtils2] is also a complete redesign of the API that is binary
> incompatible with [BeanUtils].
>
> Keeping this in mind I propose the following:
> - promote [BeanUtils2] to proper; move it to a 2.0 branch in the beanutils
> svn subtree.**
> - fix all issues that can be fixed without breaking BC in [BeanUtils] to
> push out a last bug fix release for users that don't want to swtich to a
> new API.
> - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
> line.
>
> WDYT?

Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
fine. If you intent to add new features for the 1.x line, you might better
call it 1.9.0 after all this years.

>
> Benedikt
>
> * Some JavaDoc is still missing and we have to take a look at the caching.
> AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
> discuss this in a separate thread.
> ** I don't know the exact formal process for this. What has to be done to
> promote a component to proper? Does there have to be a formal vote by the
> PMC?

Not sure for this special case either. Actually you're not promoting a new
component. However, you may look into the archives, IIRC Simo had the same
case for the last major release of digester.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Benedikt Ritter-4
Hi Jörg


2013/2/20 Jörg Schaible <[hidden email]>

> Hi Benedikt,
>
> Benedikt Ritter wrote:
>
> > Hi,
> >
> > I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
> > can be continued.
> >
> > The last release of BeanUtils (1.8.3) is now nearly 3 years ago and there
> > are 92 open issues in JIRA.
> > OTOH we've put quiet some effort into [BeanUtils2]. There are some issues
> > that have to be addressed* but the API is in a good shape.
> > But [BeanUtils2] is also a complete redesign of the API that is binary
> > incompatible with [BeanUtils].
> >
> > Keeping this in mind I propose the following:
> > - promote [BeanUtils2] to proper; move it to a 2.0 branch in the
> beanutils
> > svn subtree.**
> > - fix all issues that can be fixed without breaking BC in [BeanUtils] to
> > push out a last bug fix release for users that don't want to swtich to a
> > new API.
> > - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
> > line.
> >
> > WDYT?
>
> Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
> fine. If you intent to add new features for the 1.x line, you might better
> call it 1.9.0 after all this years.
>

Okay, I'll try to review the open issues this weekend.


>
> >
> > Benedikt
> >
> > * Some JavaDoc is still missing and we have to take a look at the
> caching.
> > AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
> > discuss this in a separate thread.
> > ** I don't know the exact formal process for this. What has to be done to
> > promote a component to proper? Does there have to be a formal vote by the
> > PMC?
>
> Not sure for this special case either. Actually you're not promoting a new
> component. However, you may look into the archives, IIRC Simo had the same
> case for the last major release of digester.
>

I'll ask Simo what he has done for digister.

Thanks a lot!
Benedikt


>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Oliver Heger-3
Am 20.02.2013 16:25, schrieb Benedikt Ritter:

> Hi Jörg
>
>
> 2013/2/20 Jörg Schaible <[hidden email]>
>
>> Hi Benedikt,
>>
>> Benedikt Ritter wrote:
>>
>>> Hi,
>>>
>>> I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
>>> can be continued.
>>>
>>> The last release of BeanUtils (1.8.3) is now nearly 3 years ago and there
>>> are 92 open issues in JIRA.
>>> OTOH we've put quiet some effort into [BeanUtils2]. There are some issues
>>> that have to be addressed* but the API is in a good shape.
>>> But [BeanUtils2] is also a complete redesign of the API that is binary
>>> incompatible with [BeanUtils].
>>>
>>> Keeping this in mind I propose the following:
>>> - promote [BeanUtils2] to proper; move it to a 2.0 branch in the
>> beanutils
>>> svn subtree.**
>>> - fix all issues that can be fixed without breaking BC in [BeanUtils] to
>>> push out a last bug fix release for users that don't want to swtich to a
>>> new API.
>>> - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
>>> line.
>>>
>>> WDYT?
>>
>> Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
>> fine. If you intent to add new features for the 1.x line, you might better
>> call it 1.9.0 after all this years.
>>
>
> Okay, I'll try to review the open issues this weekend.
>

I am also interested in a new BeanUtils release and would like to
contribute some new features. Unfortunately, I am not sure when I get
the cycles to work on this.

Oliver

>
>>
>>>
>>> Benedikt
>>>
>>> * Some JavaDoc is still missing and we have to take a look at the
>> caching.
>>> AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
>>> discuss this in a separate thread.
>>> ** I don't know the exact formal process for this. What has to be done to
>>> promote a component to proper? Does there have to be a formal vote by the
>>> PMC?
>>
>> Not sure for this special case either. Actually you're not promoting a new
>> component. However, you may look into the archives, IIRC Simo had the same
>> case for the last major release of digester.
>>
>
> I'll ask Simo what he has done for digister.
>
> Thanks a lot!
> Benedikt
>
>
>>
>> Cheers,
>> Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Benedikt Ritter-4
Hi,


2013/2/20 Oliver Heger <[hidden email]>

> Am 20.02.2013 16:25, schrieb Benedikt Ritter:
>
>  Hi Jörg
>>
>>
>> 2013/2/20 Jörg Schaible <[hidden email]>
>>
>>  Hi Benedikt,
>>>
>>> Benedikt Ritter wrote:
>>>
>>>  Hi,
>>>>
>>>> I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
>>>> can be continued.
>>>>
>>>> The last release of BeanUtils (1.8.3) is now nearly 3 years ago and
>>>> there
>>>> are 92 open issues in JIRA.
>>>> OTOH we've put quiet some effort into [BeanUtils2]. There are some
>>>> issues
>>>> that have to be addressed* but the API is in a good shape.
>>>> But [BeanUtils2] is also a complete redesign of the API that is binary
>>>> incompatible with [BeanUtils].
>>>>
>>>> Keeping this in mind I propose the following:
>>>> - promote [BeanUtils2] to proper; move it to a 2.0 branch in the
>>>>
>>> beanutils
>>>
>>>> svn subtree.**
>>>> - fix all issues that can be fixed without breaking BC in [BeanUtils] to
>>>> push out a last bug fix release for users that don't want to swtich to a
>>>> new API.
>>>> - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
>>>> line.
>>>>
>>>> WDYT?
>>>>
>>>
>>> Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
>>> fine. If you intent to add new features for the 1.x line, you might
>>> better
>>> call it 1.9.0 after all this years.
>>>
>>>
>> Okay, I'll try to review the open issues this weekend.
>>
>>
> I am also interested in a new BeanUtils release and would like to
> contribute some new features. Unfortunately, I am not sure when I get the
> cycles to work on this.


Nice to hear this. I'm starting tonight by sorting the open issues into can
"be fixed in 1.8.4" and "has to be fixed later".
IIRC you need new features for [configuration], right? Can you create
issues for this, if you don't already have?

TIA!
Benedikt


>
>
> Oliver
>
>
>
>>
>>>
>>>> Benedikt
>>>>
>>>> * Some JavaDoc is still missing and we have to take a look at the
>>>>
>>> caching.
>>>
>>>> AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
>>>> discuss this in a separate thread.
>>>> ** I don't know the exact formal process for this. What has to be done
>>>> to
>>>> promote a component to proper? Does there have to be a formal vote by
>>>> the
>>>> PMC?
>>>>
>>>
>>> Not sure for this special case either. Actually you're not promoting a
>>> new
>>> component. However, you may look into the archives, IIRC Simo had the
>>> same
>>> case for the last major release of digester.
>>>
>>>
>> I'll ask Simo what he has done for digister.
>>
>> Thanks a lot!
>> Benedikt
>>
>>
>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Simone Tripodi-2
In reply to this post by Jörg Schaible-3
Hallo Jörg und Bene! :)

> Not sure for this special case either. Actually you're not promoting a new
> component. However, you may look into the archives, IIRC Simo had the same
> case for the last major release of digester.

What I strongly recommend indeed, before starting the rock'n'roll on
/trunk and /branches, is filling in BU2 almost all the features
provided by the old BU (what I would keep out in BU2 is the JDBC
stuff, that today are better handled by whatever ORM/SQL Mapper);
while we are interested on developing new charming technologies, we
have to genuinely take care about our users, that have to feel
motivated on upgrading the library version.

What ATM BU2 offers is a fluent version of set/get properties APIs;
converters are missing, Dyna class/beans are missing, we are still too
far to let our users play with it.

My proposal is, if Bene wants/has time/... provide a new BU release,
if users need it, while working on BU2 in the background.

HTH, have a nice day,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Benedikt Ritter-4
Hi again,

2013/2/22 Simone Tripodi <[hidden email]>

> Hallo Jörg und Bene! :)
>
> > Not sure for this special case either. Actually you're not promoting a
> new
> > component. However, you may look into the archives, IIRC Simo had the
> same
> > case for the last major release of digester.
>
> What I strongly recommend indeed, before starting the rock'n'roll on
> /trunk and /branches, is filling in BU2 almost all the features
> provided by the old BU (what I would keep out in BU2 is the JDBC
> stuff, that today are better handled by whatever ORM/SQL Mapper);
> while we are interested on developing new charming technologies, we
> have to genuinely take care about our users, that have to feel
> motivated on upgrading the library version.
>

I agree, let's postpone promotion of BU2.


> What ATM BU2 offers is a fluent version of set/get properties APIs;
> converters are missing, Dyna class/beans are missing, we are still too
> far to let our users play with it.
>

I'm not to sure about DynaBeans. I don't know how they can fit into the new
API. Besides I think that libraries that force users to extend library
classes are dated. But we should discuss this at a later point.


>
> My proposal is, if Bene wants/has time/... provide a new BU release,
> if users need it, while working on BU2 in the background.
>

I have some time and I'd like to push out a new release of BU. I had a look
at jira and the project itself yesterday. There is plenty of work to do! :)
I'll comment on this on a separate thread. Your comments are very much
appreciated!

Thanks!
Benedikt


>
> HTH, have a nice day,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Oliver Heger-3
In reply to this post by Benedikt Ritter-4
Hi Benedikt,

Am 21.02.2013 20:14, schrieb Benedikt Ritter:

> Hi,
>
>
> 2013/2/20 Oliver Heger <[hidden email]>
>
>> Am 20.02.2013 16:25, schrieb Benedikt Ritter:
>>
>>   Hi Jörg
>>>
>>>
>>> 2013/2/20 Jörg Schaible <[hidden email]>
>>>
>>>   Hi Benedikt,
>>>>
>>>> Benedikt Ritter wrote:
>>>>
>>>>   Hi,
>>>>>
>>>>> I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
>>>>> can be continued.
>>>>>
>>>>> The last release of BeanUtils (1.8.3) is now nearly 3 years ago and
>>>>> there
>>>>> are 92 open issues in JIRA.
>>>>> OTOH we've put quiet some effort into [BeanUtils2]. There are some
>>>>> issues
>>>>> that have to be addressed* but the API is in a good shape.
>>>>> But [BeanUtils2] is also a complete redesign of the API that is binary
>>>>> incompatible with [BeanUtils].
>>>>>
>>>>> Keeping this in mind I propose the following:
>>>>> - promote [BeanUtils2] to proper; move it to a 2.0 branch in the
>>>>>
>>>> beanutils
>>>>
>>>>> svn subtree.**
>>>>> - fix all issues that can be fixed without breaking BC in [BeanUtils] to
>>>>> push out a last bug fix release for users that don't want to swtich to a
>>>>> new API.
>>>>> - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
>>>>> line.
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
>>>> fine. If you intent to add new features for the 1.x line, you might
>>>> better
>>>> call it 1.9.0 after all this years.
>>>>
>>>>
>>> Okay, I'll try to review the open issues this weekend.
>>>
>>>
>> I am also interested in a new BeanUtils release and would like to
>> contribute some new features. Unfortunately, I am not sure when I get the
>> cycles to work on this.
>
>
> Nice to hear this. I'm starting tonight by sorting the open issues into can
> "be fixed in 1.8.4" and "has to be fixed later".
> IIRC you need new features for [configuration], right? Can you create
> issues for this, if you don't already have?

two issues were created.

Oliver

>
> TIA!
> Benedikt
>
>
>>
>>
>> Oliver
>>
>>
>>
>>>
>>>>
>>>>> Benedikt
>>>>>
>>>>> * Some JavaDoc is still missing and we have to take a look at the
>>>>>
>>>> caching.
>>>>
>>>>> AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
>>>>> discuss this in a separate thread.
>>>>> ** I don't know the exact formal process for this. What has to be done
>>>>> to
>>>>> promote a component to proper? Does there have to be a formal vote by
>>>>> the
>>>>> PMC?
>>>>>
>>>>
>>>> Not sure for this special case either. Actually you're not promoting a
>>>> new
>>>> component. However, you may look into the archives, IIRC Simo had the
>>>> same
>>>> case for the last major release of digester.
>>>>
>>>>
>>> I'll ask Simo what he has done for digister.
>>>
>>> Thanks a lot!
>>> Benedikt
>>>
>>>
>>>
>>>> Cheers,
>>>> Jörg
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BeanUtils] Plans for BeanUtils and BeanUtils2

Benedikt Ritter-4
Hi,

I have worked through a few issues. I'm concentrating on bugs right now and
try to sort them into 1.8.4 and later than 1.8.4. I've asked reporters to
create patches against trunk, although I don't now how much feedback we
will get with this, as some of the issues date back several years.

Benedikt


2013/2/22 Oliver Heger <[hidden email]>

> Hi Benedikt,
>
> Am 21.02.2013 20:14, schrieb Benedikt Ritter:
>
>  Hi,
>>
>>
>> 2013/2/20 Oliver Heger <[hidden email]>
>>
>>  Am 20.02.2013 16:25, schrieb Benedikt Ritter:
>>>
>>>   Hi Jörg
>>>
>>>>
>>>>
>>>> 2013/2/20 Jörg Schaible <[hidden email]>
>>>>
>>>>   Hi Benedikt,
>>>>
>>>>>
>>>>> Benedikt Ritter wrote:
>>>>>
>>>>>   Hi,
>>>>>
>>>>>>
>>>>>> I'd like to discuss how the development of [BeanUtils] and
>>>>>> [BeanUtils2]
>>>>>> can be continued.
>>>>>>
>>>>>> The last release of BeanUtils (1.8.3) is now nearly 3 years ago and
>>>>>> there
>>>>>> are 92 open issues in JIRA.
>>>>>> OTOH we've put quiet some effort into [BeanUtils2]. There are some
>>>>>> issues
>>>>>> that have to be addressed* but the API is in a good shape.
>>>>>> But [BeanUtils2] is also a complete redesign of the API that is binary
>>>>>> incompatible with [BeanUtils].
>>>>>>
>>>>>> Keeping this in mind I propose the following:
>>>>>> - promote [BeanUtils2] to proper; move it to a 2.0 branch in the
>>>>>>
>>>>>>  beanutils
>>>>>
>>>>>  svn subtree.**
>>>>>> - fix all issues that can be fixed without breaking BC in [BeanUtils]
>>>>>> to
>>>>>> push out a last bug fix release for users that don't want to swtich
>>>>>> to a
>>>>>> new API.
>>>>>> - Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
>>>>>> line.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>>
>>>>> Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4
>>>>> is
>>>>> fine. If you intent to add new features for the 1.x line, you might
>>>>> better
>>>>> call it 1.9.0 after all this years.
>>>>>
>>>>>
>>>>>  Okay, I'll try to review the open issues this weekend.
>>>>
>>>>
>>>>  I am also interested in a new BeanUtils release and would like to
>>> contribute some new features. Unfortunately, I am not sure when I get the
>>> cycles to work on this.
>>>
>>
>>
>> Nice to hear this. I'm starting tonight by sorting the open issues into
>> can
>> "be fixed in 1.8.4" and "has to be fixed later".
>> IIRC you need new features for [configuration], right? Can you create
>> issues for this, if you don't already have?
>>
>
> two issues were created.
>
> Oliver
>
>
>> TIA!
>> Benedikt
>>
>>
>>
>>>
>>> Oliver
>>>
>>>
>>>
>>>
>>>>
>>>>>  Benedikt
>>>>>>
>>>>>> * Some JavaDoc is still missing and we have to take a look at the
>>>>>>
>>>>>>  caching.
>>>>>
>>>>>  AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
>>>>>> discuss this in a separate thread.
>>>>>> ** I don't know the exact formal process for this. What has to be done
>>>>>> to
>>>>>> promote a component to proper? Does there have to be a formal vote by
>>>>>> the
>>>>>> PMC?
>>>>>>
>>>>>>
>>>>> Not sure for this special case either. Actually you're not promoting a
>>>>> new
>>>>> component. However, you may look into the archives, IIRC Simo had the
>>>>> same
>>>>> case for the last major release of digester.
>>>>>
>>>>>
>>>>>  I'll ask Simo what he has done for digister.
>>>>
>>>> Thanks a lot!
>>>> Benedikt
>>>>
>>>>
>>>>
>>>>  Cheers,
>>>>> Jörg
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**--**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>> <dev-unsubscribe@**commons.apache.org<[hidden email]>
>>>>> >
>>>>>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <dev-unsubscribe@**commons.apache.org<[hidden email]>
>>> >
>>>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter