Skip to main content

Please review: fix for issue #79

7 replies [Last post]
Anonymous

Guys,

I've fixed the issue #79 (config.jti file was not exported in case user
specified default export directory $jarSourceDir).

Please review:
http://fisheye4.cenqua.com/changelog/cqme/?cs=769

Thanks,
Dmitri.

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Vladimir Sizikov

Dmitry,

Oh, I just updated the bug report... :)

Maybe we should not even suggest to use $jarSourceDir at all?

It's located in the "dangerous" place that can be deleted easily, by
"Clear Results" from JavaTest. "Clear Results" deletes everything in
the work dir, with no warnings about all the exported files and
possibly some modifications by users.

Not to mention that for casual user $jarSourceDir does not mean
anything, and just more confusing.

I'd really suggest to eliminate this option.

Thanks,
--Vladimir

On Fri, Apr 27, 2007 at 03:15:00PM +0400, Dmitri Trounine wrote:
> Guys,
>
> I've fixed the issue #79 (config.jti file was not exported in case user
> specified default export directory $jarSourceDir).
>
> Please review:
> http://fisheye4.cenqua.com/changelog/cqme/?cs=769
>
> Thanks,
> Dmitri.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Dmitri Trounine

I agree, the things will become simpler if there are no default value
for Export Directory question. If user does the test export, we can
think he really need it, and naturally he wants to take control over the
location of export directory. So, the default value is not very useful,
even if it isn't $jarSourceDir.

Should we drop this issue 79, and create new -- about usefulness of
default export directory?

Vladimir Sizikov wrote:
> Dmitry,
>
> Oh, I just updated the bug report... :)
>
> Maybe we should not even suggest to use $jarSourceDir at all?
>
> It's located in the "dangerous" place that can be deleted easily, by
> "Clear Results" from JavaTest. "Clear Results" deletes everything in
> the work dir, with no warnings about all the exported files and
> possibly some modifications by users.
>
> Not to mention that for casual user $jarSourceDir does not mean
> anything, and just more confusing.
>
> I'd really suggest to eliminate this option.
>
> Thanks,
> --Vladimir
>
> On Fri, Apr 27, 2007 at 03:15:00PM +0400, Dmitri Trounine wrote:
>
>> Guys,
>>
>> I've fixed the issue #79 (config.jti file was not exported in case user
>> specified default export directory $jarSourceDir).
>>
>> Please review:
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=769
>>
>> Thanks,
>> Dmitri.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Dmitri,

On Fri, Apr 27, 2007 at 03:32:48PM +0400, Dmitri Trounine wrote:
> I agree, the things will become simpler if there are no default value
> for Export Directory question. If user does the test export, we can
> think he really need it, and naturally he wants to take control over the
> location of export directory. So, the default value is not very useful,
> even if it isn't $jarSourceDir.

Yep.

> Should we drop this issue 79, and create new -- about usefulness of
> default export directory?

I wouldn't say that we should "drop" #79, but we probably should file
a new ISSUE too. Then the #79 fix would be by removing $jarSourcDir, and
QA can verify that it's indeed the case, and jti file is always created.

Thanks,
--Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Dmitri Trounine

Vova, guys,

as we decided I've filed a new issue #107 and fixed it. There are no
more default location of
export directory. This update should also fix the original issue #79.
Please see:

http://fisheye4.cenqua.com/changelog/cqme/?cs=772

Thanks,
Dmitri.

Vladimir Sizikov wrote:
> Dmitri,
>
> On Fri, Apr 27, 2007 at 03:32:48PM +0400, Dmitri Trounine wrote:
>
>> I agree, the things will become simpler if there are no default value
>> for Export Directory question. If user does the test export, we can
>> think he really need it, and naturally he wants to take control over the
>> location of export directory. So, the default value is not very useful,
>> even if it isn't $jarSourceDir.
>>
>
> Yep.
>
>
>> Should we drop this issue 79, and create new -- about usefulness of
>> default export directory?
>>
>
> I wouldn't say that we should "drop" #79, but we probably should file
> a new ISSUE too. Then the #79 fix would be by removing $jarSourcDir, and
> QA can verify that it's indeed the case, and jti file is always created.
>
> Thanks,
> --Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Dmitri,

The fix looks good, but please export encoded values when you export
file paths. Otherwise, we'll get into trouble with files with spaces
in their names.

The canonical way to export properly encoded vaule is:
data.put(key, StringEncoder.encode("YOUR STRING HERE"));

StringEncoder is in com.sun.tck.j2me.interview.util.

Please make sure that you've tested the changes in actual TCK before
commiting. I'm sure you fully test your changes, but we're so close to
the end of the iteration, so I figured it neveer hurts to remind
everyone that we should fully test our changes before commiting
them. :)

Thanks,
--Vladimir

On Fri, Apr 27, 2007 at 05:10:38PM +0400, Dmitri Trounine wrote:
> Vova, guys,
>
> as we decided I've filed a new issue #107 and fixed it. There are no
> more default location of
> export directory. This update should also fix the original issue #79.
> Please see:
>
> http://fisheye4.cenqua.com/changelog/cqme/?cs=772
>
> Thanks,
> Dmitri.
>
> Vladimir Sizikov wrote:
> >Dmitri,
> >
> >On Fri, Apr 27, 2007 at 03:32:48PM +0400, Dmitri Trounine wrote:
> >
> >>I agree, the things will become simpler if there are no default value
> >>for Export Directory question. If user does the test export, we can
> >>think he really need it, and naturally he wants to take control over the
> >>location of export directory. So, the default value is not very useful,
> >>even if it isn't $jarSourceDir.
> >>
> >
> >Yep.
> >
> >
> >>Should we drop this issue 79, and create new -- about usefulness of
> >>default export directory?
> >>
> >
> >I wouldn't say that we should "drop" #79, but we probably should file
> >a new ISSUE too. Then the #79 fix would be by removing $jarSourcDir, and
> >QA can verify that it's indeed the case, and jti file is always created.
> >
> >Thanks,
> > --Vladimir
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Dmitri Trounine

Vlasimir,

> The fix looks good, but please export encoded values when you export
> file paths. Otherwise, we'll get into trouble with files with spaces
> in their names.
>
I've fixed exporting pathnames. Indeed, with encoded strings the spaces
in file names work much better!

http://fisheye4.cenqua.com/changelog/cqme/branches/users/dtrounine/testE...

> Please make sure that you've tested the changes in actual TCK before
> commiting. I'm sure you fully test your changes, but we're so close to
>
Yes, I do test the updates. And I do all checks before committing to
trunk. By the way, the bad patterns check produces a lot of error.
Errors come not from files I am about to commit. And I always add "bad
patterns check: FAILED" in the comments to commit. Did anybody notice that?

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Dmitri,

On Fri, Apr 27, 2007 at 06:45:02PM +0400, Dmitri Trounine wrote:
> >The fix looks good, but please export encoded values when you export
> >file paths. Otherwise, we'll get into trouble with files with spaces
> >in their names.
> >
> I've fixed exporting pathnames. Indeed, with encoded strings the spaces
> in file names work much better!
>
> http://fisheye4.cenqua.com/changelog/cqme/branches/users/dtrounine/testE...

Looks good to me. Please, commit.

> >Please make sure that you've tested the changes in actual TCK before
> >commiting. I'm sure you fully test your changes, but we're so close to
> >
> Yes, I do test the updates. And I do all checks before committing to
> trunk. By the way, the bad patterns check produces a lot of error.
> Errors come not from files I am about to commit. And I always add "bad
> patterns check: FAILED" in the comments to commit. Did anybody notice that?

The problem with this check is that it's not 100% accurate and
requires some manual work to filter out false positives. We probably
should take a look there, once the sources sabilize, and clean all the
wrong things until the release. But I don't think it's critical.

What I think is much more important is to have javadoc output clean,
and recently there were quite a lot of warnings there, I see that
you've filed the bug against it. I'd much rather see a bugfix for
this! :)

Thanks,
--Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net