On Mon, May 13, 2013 at 4:30 PM, Emmanuel Bourg wrote:
>
> The advantage is an API that is cleaner and easier to understand.
>
I changed the methods to be package private.
> As for the name, what about "SmartBeanProcessor" or
> "ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
>
2013/5/13 Emmanuel Bourg
> Le 13/05/2013 21:24, William Speirs a écrit :
> >
> > Yes, I did mean QueryExecutor... sorry. I make my methods protected
> rather
> > than private because I'm not sure how someone (maybe myself) will need to
> > change functionality in the future. If I make them privat
On 13 May 2013 21:30, Emmanuel Bourg wrote:
> Le 13/05/2013 21:24, William Speirs a écrit :
>>
>> Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
>> than private because I'm not sure how someone (maybe myself) will need to
>> change functionality in the future. If I make
Le 13/05/2013 21:24, William Speirs a écrit :
>
> Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
> than private because I'm not sure how someone (maybe myself) will need to
> change functionality in the future. If I make them private, then there's
> not going back. If I
> You mean QueryExecutor, right? Now it's in line with UpdateExecutor and
> InsertExecutor, but I feel a bit uncomfortable with theses classes as
> they mostly expose protected methods and don't look like they are meant
> to be extended.
>
Yes, I did mean QueryExecutor... sorry. I make my methods
Hi Bill,
Le 10/05/2013 22:23, William Speirs a écrit :
> - Changed QueryRunner to be public
You mean QueryExecutor, right? Now it's in line with UpdateExecutor and
InsertExecutor, but I feel a bit uncomfortable with theses classes as
they mostly expose protected methods and don't look like they
On 11 May 2013 15:09, William Speirs wrote:
> Obviously up for debate, but are my updated thoughts:
>
> - release 2.0 from its own branch (starting with a new changes.xml file)
> - release 1.6 from trunk with the changes.xml file only including 1.x stuff
> - migrate 1.x into its own branch, and 2.
Obviously up for debate, but are my updated thoughts:
- release 2.0 from its own branch (starting with a new changes.xml file)
- release 1.6 from trunk with the changes.xml file only including 1.x stuff
- migrate 1.x into its own branch, and 2.0 into trunk
- only release 1.x fixes if absolutely ne
On 11 May 2013 13:21, Gary Gregory wrote:
> OK, then you need to keep 1.6 so we do not loose the history.
>
> 2.0 should also include all fixes from 1.6.
>
> Do you plan on working on 2.0 and 1.6 in parallel? If not, I'd just finish
> 1.6, then do the big changes for 2.0, all from trunk.
>
> Other
OK, then you need to keep 1.6 so we do not loose the history.
2.0 should also include all fixes from 1.6.
Do you plan on working on 2.0 and 1.6 in parallel? If not, I'd just finish
1.6, then do the big changes for 2.0, all from trunk.
Otherwise, you'll need a 1.6 branch and do 2.0 in trunk, or t
It is and isn't up to date. There will be a 1.6 which will include big
fixes. However 2.0 is a major rewrite. So I think the proper course of
action is to remove the 1.6 lines from the changes file in the 2.0 branch,
but leave them in the 1.x branch (trunk). Then when I get around to pushing
1.6 it
On Sat, May 11, 2013 at 7:34 AM, William Speirs wrote:
> OK, so then for the 2.0 release I'd just remove the 1.6 lines?
>
No. Based on changes.xml, It sounds like we were going to have a 1.6, but
now we are calling it 2.0. So you'd change the 1.6 to 2.0.
But... right now I see the line's descri
OK, so then for the 2.0 release I'd just remove the 1.6 lines?
Bill-
On May 10, 2013 5:37 PM, "Gary Gregory" wrote:
> The date can be the date you cut the RC.
>
> Gary
>
> On May 10, 2013, at 16:23, William Speirs wrote:
>
> > Consider this a pre release candidate for DBUTILS-2.0. I fixed the
>
The date can be the date you cut the RC.
Gary
On May 10, 2013, at 16:23, William Speirs wrote:
> Consider this a pre release candidate for DBUTILS-2.0. I fixed the
> following things from RC1:
>
> - Removed @author tags
> - Changed QueryRunner to be public
> - Made ArrayHandler generic (but it'
Consider this a pre release candidate for DBUTILS-2.0. I fixed the
following things from RC1:
- Removed @author tags
- Changed QueryRunner to be public
- Made ArrayHandler generic (but it's ugly because I just cast to T[], does
anyone have a better idea here?)
If folks (*cough* Benedikt Ritter, *
15 matches
Mail list logo
