[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[buckminster-dev] Re: Problems getting started with Headless Buckminster

Hi Mark,

After looking at BaseStorage.java, it seems that:

public class BaseResourceStorage extends PlatformObject implements IStorage ,IEncodedStreamContentAccessor, IEncodedStorage {

can be replaced by:

public class BaseResourceStorage extends PlatformObject implements IEncodedStorage {

collapsing IStorage into its subtype, IEncodedStorage, and removing the plugin dependency on org.eclipse.compare from subclipse.core.

IEncodedStorage has both the getContents() and getCharset() methods of IEncodedStreamContentAccessor.

There doesn't seem to be any obvious reference in Subclipse UI to the storage implementing IEncodedStreamContentAccessor, but maybe there's a subtle one. :)

If this change is possible, it would be a great help to Buckminster headless SVN using Subclipse.

Kind Regards,
John Fallows
Brane Corporation.

Mark Phippard wrote:
Thomas Hallgren wrote:

Hi John,
OK, I can reproduce this too now. And I found the cause of the
problem. I've bumped the reason of
org.tigris.subversion.subclipse.core and that plugin depend on the
org.eclipse.compare plugin which in turn brings in a whole slew of UI
specific plugins. I'm copying this to the svn newsgroup too since I'd
like to get their opinion on this.

The only workaround I can find for you right now is to copy most of
the plugins from an Eclipse IDE installation into your headless
installation. The org.eclipse.compare plugin brings in the
org.eclipse.ui.ide and the org.eclipse.ui.workbench.texteditor which
in turn brings most other UI specific plugins in with them.

Subclipse has a org.tigris.subversion.subclipse.ui component too.
Perhaps it would be better if they moved the dependency to
org.eclipse.compare into that plugin. Right now there's no way to use
Subclipse efficiently in a headless environment.

It looks like the dependency exists so that our BaseResourceStorage class can implement the org.eclipse.compare.IEncodedStreamContentAccessor interface. The annotation for this change says it was so that we could properly set the encoding on files when doing compares from the Synch view.


Author:  Pro JSF and Ajax: Building Rich Internet Components