Community
Participate
Working Groups
With a dynamic environment as equinox some classes of problems (unexpected wiring between bundles, missing service dependencies, etc) are not reproducible in all the cases. On the other hand reproducing test failure may take relatively long time (especially when trying to reproduce/debug the problem in a different environment than it initially occurs). Instead of reproducing the problem, an offline analysis of the logs could easily help in troubleshooting issues like the mentioned above. Currently tycho log contains some of the required information for such offline analysis: - list of the binaries that are installed (and their locations); - the command line for launching the java process; but lack equinox runtime pieces like: - the actual wiring and state of the istalled bundles ( e.g "ss" and "b <id>" command output) - the list of service components registered in the service registry; - the effective set of parameter equinox framework uses; - etc.
Do you think the new information should go in a separate file in order not to pollute the main log? I'm new to tycho so if you can point me to guidelines or docs on how logs are currently organized, it would be very helpful. Also if you have any expectations or requirements how this should be implemented, please share. Thank you in advance.
In general, see wiki.eclipse.org/Developing_Tycho first. IMHO this should only be switched on if in debug mode (maven CLI option -X) or even with a special parameter -DequinoxTracing=true. If it's a special parameter, it could go in the main log I think as the user was explicitly asking for the information.
We already use -Dtycho.debug.resolver to enable more detailed dependency resolution log, so we can use something like -Dtycho.debug.equinox-launching (or similar) to request additional equinox launching logging. As far as I can tell, the additional information will be generated by the external JVM, so I am not sure if it will be practical to funnel these messages back to Maven log, but I agree this would be desired/expected behaviour.
I went through "developing tycho" wiki- everything worked as described (I had build errors at first but the workaround helped). Some minor comments on "building tycho" section: - bootstrap.cmd is located in org.eclipse.tycho (instead of sonatype-tycho) - not sure whether I should use exactly 3.7 or I can use higher version (my current dev env is 4.2 and everything seems to work fine) I played a bit with standard debug options provided by equinox - I think the output is too technical and too unreadable for someone not prepared to debug equinox itself. So combining the two ideas so far would look like having two levels of debuging: - basic one providing high level overview of the runtime (see attached more_user_friendly_output.txt for example) - advanced one, based on existing Eclipse tracing (see otput_from_standard_options.txt) I was thinking that basic one could be enabled on test failure instead when a specific prop is set. Thus user wouldn't need to re-run the tests in order to get the debug info. What do you think? I tried debugging an integration test in order to get an idea of the execution flow and thus to know where to put the new logic. But I struggled with this and I would appreciate some help here: When I run bootstrap.cmd (or mvn clean install), all the tests pass successfully. I saw they are run with the following command line: cmd.exe /X /C ""C:\Program Files (x86)\Java\jdk1.6.0_04\jre\bin\java.exe" -Dosgi.noShutdown=false -Dosgi.os=win32 -Dosgi.ws=win32 -Dosgi.arch=x86 -jar C:\.m2\repository\p2\osgi\bundle\org.eclipse.equinox.launcher\1.2.0.v20110725-1610\org.eclipse.equinox.launcher-1.2.0.v20110725-1610.jar -data C:\eclipse.git.repositories\org.eclipse.tycho\tycho-bundles\org.eclipse.tycho.p2.resolver.impl.test\target\work\data -dev file:/C:/eclipse.git.repositories/org.eclipse.tycho/tycho-bundles/org.eclipse.tycho.p2.resolver.impl.test/target/dev.properties -install C:\eclipse.git.repositories\org.eclipse.tycho\tycho-bundles\org.eclipse.tycho.p2.resolver.impl.test\target\work -configuration C:\eclipse.git.repositories\org.eclipse.tycho\tycho-bundles\org.eclipse.tycho.p2.resolver.impl.test\target\work\configuration -application org.eclipse.tycho.surefire.osgibooter.headlesstest -testproperties C:\eclipse.git.repositories\org.eclipse.tycho\tycho-bundles\org.eclipse.tycho.p2.resolver.impl.test\target\surefire.properties However when I tried to execute this as a standalone process, some of the tests fail. They fail as well when I try to execute tycho integration tests as Eclipse app (org.eclipse.tycho.surefire.osgibooter.headlesstest ) and pass corresponding app arguments. Could you please help me to setup execution of just one integration test (either in Eclipse or command line)? I checked tycho FAQ but couldn't build the whole picture from there. Thank you very much.
Created attachment 207889 [details] Proposed debug infomation on test failure
Created attachment 207890 [details] standard equinox tracing with resolver/debug=true, resolver/wiring=true and debug/services=true
I certainly like the idea of providing more information on test failure and I think listing all bundles and their respective state and location would be generally useful. The rest of the information, i.e. detailed bundle wiring and certainly equinox tracing, I think should be provided at user request. You need to use Maven to execute individuate tests. Try the following from the test project folder "mvn clean integration-test -Dtest=<test-class-name>"
(In reply to comment #4) > I went through "developing tycho" wiki- everything worked as described (I had > build errors at first but the workaround helped). Some minor comments on > "building tycho" section: > - bootstrap.cmd is located in org.eclipse.tycho (instead of sonatype-tycho) fixed. > - not sure whether I should use exactly 3.7 or I can use higher version (my > current dev env is 4.2 and everything seems to work fine) we develop against one of the Juno milestones. Currently this is Juno M1, see http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-bundles/tycho-bundles-target/tycho.target Of course you can use a newer IDE, just make sure the target platform is correct. The test target platform can be 3.6 or 3.7; should not matter much -- the important thing here is to add the corresponding delta pack.
(In reply to comment #8) > we develop against one of the Juno milestones. Currently this is Juno M1, see > http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-bundles/tycho-bundles-target/tycho.target > Of course you can use a newer IDE, just make sure the target platform is > correct. This information was missing on http://wiki.eclipse.org/Developing_Tycho
(In reply to comment #4) > I tried debugging an integration test in order to get an idea of the execution > flow and thus to know where to put the new logic. But I struggled with this and > I would appreciate some help here: Do you want to execute the tests from the Tycho sources or tests executed in a Tycho build? The latter makes more sense, but then you shouldn't use the test in the Tycho sources as example because they are (forcibly) executed with an older Tycho version. If you want to debug the OSGi runtime forked by tycho-surefire-plugin, set the system property -DdebugPort=8000.
With the content of config.ini and the Maven logs, it's relatively easy to reproduce the test environment and tweak it for deeper analysis. I don't think Tycho should offer more.
