it was a result of the MultiLabelDecorator.decorateImage change there a null
check should be done:
public Image decorateImage(Image image, Object element) {
// return null;
if (element instanceof ISynchronizeModelElement) {
IResource resource = ((ISynchronizeModelElement)
element).getResource();
if (resource == null) return null;
i added the last line and the null pointers are gone.
On Wed, Feb 25, 2009 at 12:51, Johan Compagner <jcompagner_at_gmail.com> wrote:
> working sets in the synchronized view are not workin any more
>
> i get the nullpointer now but i think that null pointer is not the cause
> but a result of
> Because the working set label is completely empty i just see the > of the
> tree and nothing more
> if i collapse that i do see stuff
>
>
> !STACK 0
> java.lang.NullPointerException
> at
> org.tigris.subversion.subclipse.core.resources.SVNWorkspaceRoot.getSVNResourceFor(SVNWorkspaceRoot.java:245)
> at
> org.tigris.subversion.subclipse.ui.subscriber.SVNSynchronizeParticipant$SVNParticipantLabelDecorator.decorateImage(SVNSynchronizeParticipant.java:89)
> at
> org.eclipse.team.internal.ui.synchronize.MultiLabelDecorator.decorateImage(MultiLabelDecorator.java:29)
> at
> org.eclipse.jface.viewers.DecoratingLabelProvider.getImage(DecoratingLabelProvider.java:94)
> at
> org.eclipse.jface.viewers.DecoratingLabelProvider.updateLabel(DecoratingLabelProvider.java:356)
> at
> org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:183)
> at
> org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:145)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:932)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:102)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:888)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1012)
> at
> org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:475)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:888)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
> at
> org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2096)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:827)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2680)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1862)
> at
> org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:716)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1837)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1793)
> at
> org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1779)
> at
> org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1446)
> at
> org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1381)
> at
> org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:402)
> at
> org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1340)
> at
> org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1444)
> at
> org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:537)
> at
> org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1403)
> at
> org.eclipse.team.internal.ui.synchronize.SynchronizeModelUpdateHandler$10.run(SynchronizeModelUpdateHandler.java:684)
> at
> org.eclipse.team.internal.ui.synchronize.SynchronizeModelUpdateHandler.internalRunViewUpdate(SynchronizeModelUpdateHandler.java:575)
> at
> org.eclipse.team.internal.ui.synchronize.SynchronizeModelUpdateHandler.access$1(SynchronizeModelUpdateHandler.java:561)
> at
> org.eclipse.team.internal.ui.synchronize.SynchronizeModelUpdateHandler$5.run(SynchronizeModelUpdateHandler.java:540)
> at
> org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
>
>
>
> On Tue, Feb 24, 2009 at 19:31, Mark Phippard <markphip_at_gmail.com> wrote:
>
>> Subversion 1.6.0 RC2 was released on Friday. One of the big features
>> in this release is something called "tree conflicts". Basically,
>> think of what happens if you have made local edits to a file and you
>> do an update and someone else has renamed this file. There are a lot
>> of variations on this scenario, but that gives the gist. In SVN 1.5
>> and earlier, Subversion is very silent when this happens. It pulls in
>> the new changes, and often just unversions your local edits. Starting
>> with 1.6, this now raises a new kind of conflict called a tree
>> conflict.
>>
>> Subclipse 1.6.0 contains a lot of new work to first show you these
>> conflicts in the UI and second to help you work with them and resolve
>> them. A new Tree Conflicts view has been created to see them, of
>> course you can also see them in the decorators. But since tree
>> conflicts can occur on deleted items, we could not rely on decorators
>> alone. Also the view shows a little summary of what type of tree
>> conflict it is.
>>
>> There is also a resolve option that will launch a wizard specific to
>> the scenario you are facing to help you resolve the conflict.
>>
>> Subclipse 1.6.0 requires Subversion 1.6.0 JavaHL. SVNKit is not
>> currently supported as it does not yet support the 1.6 API's. We are
>> shipping a "dummy" SVNKit plugin to satisfy version requirements and
>> allow you to install.
>>
>> As always, we include the binaries for Windows. CollabNet has an RPM
>> for Linux that includes JavaHL and an OSX binary will be posted soon.
>>
>> http://www.open.collab.net/downloads/subversion/rc/
>>
>> You can follow the instructions in this FAQ to see how to enable JavaHL:
>>
>> http://subclipse.tigris.org/wiki/JavaHL
>>
>> Subversion 1.6.0 will upgrade the format of your WC. Once this is
>> done, you will not be able to use it with a SVN 1.5 or earlier client.
>>
>> NONE of the features in SVN 1.6 require your server to be running SVN
>> 1.6 to use them. There were, of course, features added in SVN 1.5
>> that require a 1.5 server and still do, but the new 1.6 features like
>> tree conflicts do not.
>>
>> The Subversion 1.6 release notes are a Work In Progress but can be seen
>> here:
>>
>> http://subversion.tigris.org/svn_1.6_releasenotes.html
>>
>> OK, enough already how do you get it?
>>
>> Update Site URL: http://subclipse.tigris.org/update_1.6.x
>> Changelog: http://subclipse.tigris.org/subclipse_1.6.x/changes.html
>>
>> Eclipse 3.2 and higher are supported.
>>
>> I will continue to backport fixes to the 1.4.x releases for a while,
>> and the 1.4.x release will stay on Subversion 1.5 support. A
>> Subversion 1.5.6 release is coming soon, and I plan to do a new 1.4.x
>> release at that time.
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>> ------------------------------------------------------
>>
>> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1221836
>>
>> To unsubscribe from this discussion, e-mail: [
>> dev-unsubscribe_at_subclipse.tigris.org].
>>
>
>
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1226319
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-02-25 13:06:10 CET