Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 362023

Summary: [console] console tests fail now that built-in console is disabled
Product: [Eclipse Project] Equinox Reporter: Thomas Watson <tjwatson>
Component: FrameworkAssignee: Lazar Kirchev <l.kirchev>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: l.kirchev
Version: 3.7.1   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:

Description Thomas Watson CLA 2011-10-25 23:34:31 EDT
Most of the console tests now fail with the built-in console disabled.  I am not sure that is expected or not.  The test org.eclipse.osgi.tests.console.TestFrameworkCommandInterpreter.testExecute() is also hanging now and I am not sure why.  I am going to disable the tests for now.  Lazar, could you look into this and let me know if any of these tests make sense with the built-in console disabled?
Comment 1 Lazar Kirchev CLA 2011-10-26 11:34:01 EDT
(In reply to comment #0)
> Most of the console tests now fail with the built-in console disabled.  I am
> not sure that is expected or not.  The test
> org.eclipse.osgi.tests.console.TestFrameworkCommandInterpreter.testExecute() is
> also hanging now and I am not sure why.  I am going to disable the tests for
> now.  Lazar, could you look into this and let me know if any of these tests
> make sense with the built-in console disabled?

Ok Tom, disable them for now, and I will check if they are still relevant, and if not - is it possible to modify them so that they become relevant. In any case, I suppose that some of them should pass even without modifications - for example the TestRestrictedTelnetHost. 
TestFrameworkCommandInterpreted expects CommandProviders to be registered, but they are registered by the console bundles now, not by the framework, so it could not pass if the console bundle is not started. But I would expect it to fail. Will check the code.
Comment 2 Thomas Watson CLA 2011-10-26 13:40:10 EDT
I disabled the tests for the next build.  Moving to M4 to consider re-enabling them if relevant.
Comment 3 Thomas Watson CLA 2011-12-06 15:30:09 EST
reassigning to Lazar.  I am fine if we decide to permanently disable these for Juno.  Let me know Lazar.
Comment 4 Thomas Watson CLA 2012-01-18 16:07:47 EST
removing milestone, but would still like input from Lazar if we should just disable these tests indefinitely.
Comment 5 Thomas Watson CLA 2012-04-30 11:46:40 EDT
Lazar, could you provide some comment on this?  I was going to close as wontfix, but I still would like to understand why the disabled tests started failing.
Comment 6 Lazar Kirchev CLA 2012-05-04 02:49:21 EDT
(In reply to comment #5)
> Lazar, could you provide some comment on this?  I was going to close as
> wontfix, but I still would like to understand why the disabled tests started
> failing.

Assuming that the shell bundles are correctly started in the test framework environment, the causes for the problems should be as follows (I list each test class and the corresponding issues):

1. TestCommandExecution - it has 4 test methods, it seems that 3 of them should pass, but the last one should fail, because it tests help command output and now the format is different. 

2. TestEquinoxStartWithConsole - could not work, because the test starts a framework with EquinoxFactory and checks if its console is available, and I suppose the console bundles are not started, or the replacement of the in/out streams by the test fails.

3. TestEquinoxStartWithoutConsole - well, this should be working.

4. TestFrameworkCommandInterpreter - testNextArgument() should work, testExecute() could not work, because no CommandProviders are registered by the Equinox itself any more.

5. TestRestrictedTelnetHost - seems this should work.
Comment 7 Thomas Watson CLA 2013-04-24 09:06:53 EDT
I don't see any need to investigate this more.  For Luna the built-in console is going to be completely removed from the framework.