Issue 6967 in pharo: TestRunnerCommandLineHandler should be in own package

Status: Accepted
Owner: [hidden email]
Labels: Type-Bug

New issue 6967 by [hidden email]: TestRunnerCommandLineHandler  
should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

The class TestRunnerCommandLineHandler is dependent on SUnit and RPackage  
and thus doesn't work in Pharo Kernel and makes several Undeclared there.  
This class should be moved to separate package named  
TestRunnerCommandLineHandler


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: HumanReviewNeeded

Comment #1 on issue 6967 by [hidden email]:  
TestRunnerCommandLineHandler should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

SLICE-Issue-6967-TestRunnerCommandLineHandler-should-be-in-own-package-PavelKrivanek.1

new package named TestRunnerCommandLineHandler must be registered


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Labels: Milestone-2.0

Comment #2 on issue 6967 by [hidden email]:  
TestRunnerCommandLineHandler should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #3 on issue 6967 by [hidden email]:  
TestRunnerCommandLineHandler should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

Hmm... I hate to add all these tiny packages... why have package at all, we  
could just have every class in its own pacakge.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 6967 by [hidden email]:  
TestRunnerCommandLineHandler should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

Well, I understand but in this case it makes sense. For example if you want  
to create an image for production you will not want  
TestRunnerCommandLineHandler in it.  The same for  
LoadUpdatesCommandLineHandler etc. And for Pharo Kernel development you may  
want TestRunnerCommandLineHandler but not LoadUpdatesCommandLineHandler.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 6967 by [hidden email]:  
TestRunnerCommandLineHandler should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

Shouldn't they be close to what they drive? TestRunnerCommandLineHandler  
should be in SUnit,

LoadUpdatesCommandLineHandler close to the UpdateStreamer....


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 6967 by [hidden email]:  
TestRunnerCommandLineHandler should be in own package
http://code.google.com/p/pharo/issues/detail?id=6967

Good point. I agree, but better place for TestRunnerCommandLineHandler  
would be HudsonBuildTools20. What about the tests?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker