Mikhail,
You are right - I think I asked not proper question. The base issue is: how
we are going to test serialization and what support from testing framework
is required? So far we have two serialization frameworks. Roughly, the first
framework provides utility class with set of static methods
On 5/2/06, Stepan Mishura [EMAIL PROTECTED] wrote:
Mikhail,
You are right - I think I asked not proper question. The base issue is: how
we are going to test serialization and what support from testing framework
is required? So far we have two serialization frameworks. Roughly, the first
On 5/2/06, Anton Avtamonov wrote:
On 5/2/06, Stepan Mishura wrote:
Mikhail,
You are right - I think I asked not proper question. The base issue is:
how
we are going to test serialization and what support from testing
framework
is required? So far we have two serialization frameworks.
Geir Magnusson Jr wrote:
We have 9 votes in favor, none against, and one reasonable question
about destination.
I think that we should let Archie bring it into SVN. :) It was
suggested as
enhanced/gnuclasspathadapter/trunk/
but I'd suggest
Geir Magnusson Jr wrote:
Ok - so this is an aspect of modularization, rather than some deranged
bending of package implementation? :D
Yes.
So if a module has public packages A, B and C would it be :
.. and therein lies the problem, there is no such thing as a 'public
package' and a
Stepan.
Let me answer you shortly: yes, my main concern is about an assetion step.
Just because I saw too many classes without specified serialization
form, without equals() and so on. Actually, I suppose that is the
entire graphical framework (awt + Swing) which is definitely more then
5% :-). I
Anton, thank you for pointing out to awt/swing classes - I've looked through
a number of randomly selected classes and I've realized that many of them
haven't specified serial form.
I'll try to estimate percentage of such classes.
Thanks,
Stepan.
On 5/2/06, Anton Avtamonov wrote:
Stepan.
Let
Tim Ellison wrote:
Geir Magnusson Jr wrote:
We have 9 votes in favor, none against, and one reasonable question
about destination.
I think that we should let Archie bring it into SVN. :) It was
suggested as
enhanced/gnuclasspathadapter/trunk/
but I'd suggest
Tim Ellison wrote:
I'm confused, we voted on HARMONY-114 and committed HARMONY-318? If
nothing else that is not very traceable.
Does the BCC that applies to HARMONY-114 also apply to -318?
Excellent catch. (Many eyes...) Also, the JIRA status were not changed
either.
I guess there's
Geir Magnusson Jr wrote:
Tim Ellison wrote:
I'm confused, we voted on HARMONY-114 and committed HARMONY-318? If
nothing else that is not very traceable.
Does the BCC that applies to HARMONY-114 also apply to -318?
Excellent catch. (Many eyes...) Also, the JIRA status were not
Sorry. Its all my fault. I was distracted by the JIRA user interface
and entered a new bug report (318) when I should have updated my old
bug report (114). All my updates are posted to 318.
Would it help if I closed 114? Or put a note that follow-on is
actually posted to 318?
On 5/2/06, Tim
11 matches
Mail list logo
