| Confusing log levels [message #726461] |
Sun, 18 September 2011 01:45  |
Eclipse User |
|
|
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body alink="#EE0000" bgcolor="#ffffff" link="#0000EE" text="#000000"
vlink="#551A8B">
<font size="-1">Hi,<br>
<br>
I have a minor problem with the error output of the resolver that
is IMHO a little confusing and many of my comitters/contributors
seem to have the same problem. Let me explain our situation:<br>
<br>
Checkouts from SVN are usually pretty slow. Especially when I'm
working on the build scripts themselves locally I prefer not to
commit all changes to SVN just to have my local Hudson check them
out and Buckminster check them out a second time. Hence I've
optimized our RMAP so that it first watches out for an existing
checkout (more exactly a copy of it) and only falls back to the
remote SVN repository if that fails. The relevant parts of the
RMAP look like:<br>
<br>
<rm:locator pattern="^org\.eclipse\.emf\.cdo(?:\..+)?$"
searchPathRef="local" <font color="#cc0000"><b>failOnError="false"</b></font>/><br>
<rm:locator pattern="^org\.eclipse\.emf\.cdo(?:\..+)?$"
searchPathRef="svn"/><br>
<br>
<rm:searchPath name="local"><br>
<rm:provider componentTypes="osgi.bundle"
readerType="local"><br>
<rm:uri format=<a class="moz-txt-link-rfc2396E" href="file://{0}/plugins/{1}">"file://{0}/plugins/{1}"</a>><br>
<bc:propertyRef key="checkout"/><br>
<bc:propertyRef
key="buckminster.component"/><br>
</rm:uri><br>
</rm:provider><br>
<rm:provider componentTypes="eclipse.feature"
readerType="local"><br>
<rm:uri
format=<a class="moz-txt-link-rfc2396E" href="file://{0}/features/{1}-feature">"file://{0}/features/{1}-feature"</a>><br>
<bc:propertyRef key="checkout"/><br>
<bc:propertyRef
key="buckminster.component"/><br>
</rm:uri><br>
</rm:provider><br>
</rm:searchPath><br>
<br>
<rm:searchPath name="svn"><br>
<rm:provider componentTypes="osgi.bundle"
readerType="svn"><br>
<rm:uri
format="{0}/trunk/plugins/{1}?moduleAfterTag&amp;moduleAfterBranch"><br>
<bc:propertyRef key="svn.repository"/><br>
<bc:propertyRef
key="buckminster.component"/><br>
</rm:uri><br>
</rm:provider><br>
<rm:provider componentTypes="eclipse.feature"
readerType="svn"><br>
<rm:uri
format="{0}/trunk/features/{1}-feature?moduleAfterTag&amp;moduleAfterBranch"><br>
<bc:propertyRef key="svn.repository"/><br>
<bc:propertyRef
key="buckminster.component"/><br>
</rm:uri><br>
</rm:provider><br>
</rm:searchPath><br>
<br>
You've noticed the </font><font size="-1"><font color="#cc0000"><b>failOnError="false"</b></font></font><font
size="-1"> that indicates that I expect to fail this line in many
cases and that the rest of the RMAP is prepared to hnandle
eventual failures. Now it often happens that the Subversive
provider fails for various strange reasons like network problems
and just repeating the import operation is almost always
successful.<br>
<br>
The annoying thing is that in the case of an SVN problem we're
seeing this in the console:<br>
<br>
ERROR [0546] : No suitable provider for component
org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn:osgi.bundle
was found in resourceMap
<a class="moz-txt-link-freetext"
href="file:/home/mtaal/mydata/dev/workspaces/cdo4.1/org.eclipse.emf.cdo.releng/build.rmap">file:/home/mtaal/mydata/dev/workspaces/cdo4.1/org.eclipse.emf.cdo.releng/build.rmap</a><br>
ERROR [0546] : No suitable provider for component
org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn:osgi.bundle
was found in searchPath local<br>
<font color="#cc0000"><b> ERROR [0546] : Resolution attempt
ended with exception: Provider local(<a
class="moz-txt-link-freetext"
href="file:///replaced/by/hudson/builds/plugins/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn">file:///replaced/by/hudson/builds/plugins/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn</a>):
Missing CSpec source required by component type osgi.bundle<br>
ERROR Provider local(<a class="moz-txt-link-freetext"
href="file:///replaced/by/hudson/builds/plugins/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn">file:///replaced/by/hudson/builds/plugins/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn</a>):
Missing CSpec source required by component type osgi.bundle<br>
ERROR [0546] : Rejecting provider local(<a
class="moz-txt-link-freetext" href="file://">file://</a>{0}/features/{1}-feature[<a
class="moz-txt-link-freetext"
href="file:///replaced/by/hudson/builds/features/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn-feature">file:///replaced/by/hudson/builds/features/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn-feature</a>]):
Components of type osgi.bundle are not supported<br>
</b></font> ERROR [0546] : No suitable provider for component
org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn:osgi.bundle
was found in searchPath svn<br>
ERROR [0546] : Rejecting provider
svn({0}/trunk/features/{1}-feature?moduleAfterTag&moduleAfterBranch[<a
class="moz-txt-link-freetext"
href="https://dev.eclipse.org/svnroot/modeling/org.eclipse.emf.cdo/trunk/features/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn-feature?moduleAfterTag&moduleAfterBranch">https://dev.eclipse.org/svnroot/modeling/org.eclipse.emf.cdo/trunk/features/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn-feature?moduleAfterTag&moduleAfterBranch</a>]):
Components of type osgi.bundle are not supported<br>
ERROR [0546] : Resolution attempt ended with exception:
org.tigris.subversion.svnclientadapter.SVNClientException:
org.tigris.subversion.javahl.ClientException: svn: Connection
reset<br>
svn: OPTIONS request failed on
'/svnroot/modeling/org.eclipse.emf.cdo/trunk/plugins/org.eclipse.emf.cdo.dawn.examples.acore.diagram.dawn'<br>
ERROR
org.tigris.subversion.svnclientadapter.SVNClientException:
org.tigris.subversion.javahl.ClientException: svn: Connection
reset<br>
<br>
As developers, I suppose, we're so used to always look for the
first problem in a log, possibly assuming the problems further
down are likely follow-up problems. This often leads me (and
others) to the wrong conclusion that the local provider has caused
the import failure.<br>
<br>
I think the complete information about the resolution attempts can
be interesting in some situations, but it would be great if the
log level could be degraded to INFO (WARN at most) because with
the </font><font size="-1"><font color="#cc0000"><b>failOnError="false"</b></font></font><font
size="-1"> I've explicitely told that I do not consider this an
error. <br>
<br>
Would it be much work to change the logging in a way such that
the log level is more adaptive?<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
</font>
</body>
</html>
|
|
|
|
| Re: Confusing log levels [message #729227 is a reply to message #726555] |
Sun, 25 September 2011 09:23  |
| Eclipse User |
|
|
|
Am 18.09.2011 18:12, schrieb Thomas Hallgren:
> On 2011-09-18 07:45, Eike Stepper wrote:
>>
>> I think the complete information about the resolution attempts can be interesting in some situations, but it would be
>> great if the log level could be degraded to INFO (WARN at most) because with the *failOnError="false"*I've explicitely
>> told that I do not consider this an error.
>>
> No, you've explicitly said that this error should not be cause the build to fail ;-)
>
>> Would it be much work to change the logging in a way such that the log level is more adaptive?
>>
> Please enter an enhancement request. I agree that the output could be improved here.
Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=358820
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.26256 seconds
Home