| Avoiding logging of CoreExceptions? [message #287056] |
Thu, 23 June 2005 14:55  |
Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Hey Everyone,
Well, I have finally figured out most of my woes with running my builder
in headless mode. I have one problem left to solve and I was hoping
someone could offer some advice.
I have implemented my own application entry point to Eclipse that
essentially is a headless wrapper around the build engine. This allows
me to use Eclipse from the command line to build projects, similar to
the way MSDEV works. So, basically, I can pass a list of project names
on the command line, and they will be each built using a call to
IProject.build(int Kind, IProgressMonitor monitor). What I would like
to happen is for the application to exit with a non-zero exit code when
a build failure occurs. No problem, I can catch a CoreException from
the #build() method, and return a non-zero exit code.
The problem is, Eclipse logs a big ole' stack trace to the log. I don't
want a huge stack trace in my log file if I am running a command line
build, and I am intentionally catching the CoreException and swallowing
it. But, because the Platform.run() method is actually doing the build,
I seemingly have no choice in the matter. If I catch it at a higher
level (in my builder for instance) I can avoid the log message, but
there is simply no way to notify my application entry point that the
build failed, and it just chugs merrily along and exits with no errors.
Is there any way around this? Here is an example stack trace in my log:
!ENTRY org.eclipse.core.resources 4 2 2005-06-23 10:54:07.504
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.core.resources".
!STACK 1
org.eclipse.core.runtime.CoreException: C:\Documents and
Settings\mmelvin.DSPFACTORY\Desktop\runtime-workspace\Gump\b uild.xml:34:
mccc failed with return code 1
at
com.amis.skt.build.ui.model.SignaKlaraAntBasedBuilder.handle Exception(SignaKlaraAntBasedBuilder.java:525)
at
com.amis.skt.build.ui.model.SignaKlaraAntBasedBuilder.invoke Ant(SignaKlaraAntBasedBuilder.java:390)
at
com.amis.skt.build.ui.model.SignaKlaraAntBasedBuilder$1.run( SignaKlaraAntBasedBuilder.java:237)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1719)
at
com.amis.skt.build.ui.model.SignaKlaraAntBasedBuilder.increm entalBuild(SignaKlaraAntBasedBuilder.java:241)
at
com.amis.skt.build.ui.model.SignaKlaraAntBasedBuilder.fullBu ild(SignaKlaraAntBasedBuilder.java:204)
at
com.amis.skt.build.ui.model.SignaKlaraAntBasedBuilder.build( SignaKlaraAntBasedBuilder.java:148)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:593)
at
org.eclipse.core.internal.runtime.InternalPlatform.run(Inter nalPlatform.java:1044)
at org.eclipse.core.runtime.Platform.run(Platform.java:783)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:168)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:202)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:231)
at
org.eclipse.core.internal.runtime.InternalPlatform.run(Inter nalPlatform.java:1044)
at org.eclipse.core.runtime.Platform.run(Platform.java:783)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:234)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:303)
at org.eclipse.core.internal.resources.Project.build(Project.ja va:106)
at
com.amis.skt.build.application.SKTCommandLineBuilder.buildBu ildable(SKTCommandLineBuilder.java:192)
at
com.amis.skt.build.application.SKTCommandLineBuilder.execute Build(SKTCommandLineBuilder.java:173)
at
com.amis.skt.build.application.SKTCommandLineBuilder.run(SKT CommandLineBuilder.java:135)
at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:226)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:376)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334 )
at org.eclipse.core.launcher.Main.basicRun(Main.java:278)
at org.eclipse.core.launcher.Main.run(Main.java:973)
at org.eclipse.core.launcher.Main.main(Main.java:948)
Thanks,
Mark.
|
|
|
| Re: Avoiding logging of CoreExceptions? [message #287061 is a reply to message #287056] |
Thu, 23 June 2005 15:53  |
| Eclipse User |
|
|
|
Originally posted by: chaves-do-not-spam.inf.ufsc.br
Afaik, there is no supported way for turning the log off. You can choose a
non-existing location, and then it will only be output to stderr.
java -jar startup.jar -Dosgi.logfile=/bogus-location -application
com.example.product.myapp
Or you can set the log file to the null device (nul on Windows, /dev/null
on Unixes) and then the output should just disappear. Something like:
java -jar startup.jar -Dosgi.logfile=nul -application
com.example.product.myapp
|
|
|
| Re: Avoiding logging of CoreExceptions? [message #287067 is a reply to message #287061] |
Thu, 23 June 2005 17:10 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Rafael Chaves wrote:
> Afaik, there is no supported way for turning the log off. You can choose
> a non-existing location, and then it will only be output to stderr.
> java -jar startup.jar -Dosgi.logfile=/bogus-location -application
> com.example.product.myapp
>
> Or you can set the log file to the null device (nul on Windows,
> /dev/null on Unixes) and then the output should just disappear.
> Something like:
>
> java -jar startup.jar -Dosgi.logfile=nul -application
> com.example.product.myapp
>
OK. Thanks for the reply, Rafael.
Mark.
|
|
|
Powered by
FUDForum. Page generated in 0.03258 seconds
] 
Search
Help
Register
Login
Home
