Bug 336266

Comment 1 Thomas Hallgren 2011-02-03 16:07:23 EST

This occurs when the URL passed to subversion has no scheme.The NPE is still wrong of course, but perhaps that information will help you find a workaround.

Comment 2 Chris Eagan 2011-02-07 10:58:18 EST

I was able to use Buckminster and Jenkins to rebuild my Target Platform properly. The builds that fail seem to be those that involve Buckminster materializing content from an svn repository. The svn repository we use is set up with the svn+shh protocol.

With the Buckminster DEBUG setting on, I see the following prior to the error:

Provider svn(svn+ssh://svn-server/svn/trunk/path/to/plugin): materializing to /var/lib/jenkins/jobs/product/workspace/plugins/plugin/

This looks right to me, unless the "/var/lib..." is supposed to be a URI? The svn path is correct and differs from project to project.

Comment 3 Chris Eagan 2011-02-09 12:50:16 EST

I set up a remote debugging session to determine the cause and the value of location on line #316 is:

/var/lib/jenkins/jobs/Product/workspace/source/plugins

This explains why the NPE occurs. The "Known Repositories" list contains a path to a locally checked out copy which doesn't use a Scheme.

Does this help narrow down the problem? I'm going to keep digging for more information using the remote debugger.

Comment 4 Chris Eagan 2011-02-09 15:46:12 EST

This issue occurs while Buckminster is attempting to bind a local object, checked out by Jenkins.

It seems that the local resource is recognized by Buckminster as an svn project because the objects contains a .svn folder. The share project method uses the Resolution to determine the original svn location of the project. The issue with this is that Jenkins did the check out and Buckminster used a local file source when resolving the dependencies.

It would be cool if this were happening in my workspace and a project that I had locally was automatically shared because it was recognized as an SVN project, but I think that the code should change to read the source URL from the .svn subfolder's metadata to ensure that the url it is using is accurate.

Relevant code from WorkspaceMaterializer:474 as I see it in my installation:

IReaderType readerType = getMaterializationReaderType(cr);
if (readerType instanceof LocalReaderType) {
   // This might not be the one that we want to use when sharing
   // the project. Look for known SCM metadata. This should of
   // course be done in a nicer way using extension points.
   //
   if (project.getFolder(".git").exists()) { //$NON-NLS-1$
      try {
         readerType = CorePlugin.getDefault().getReaderType("git"); //$NON-NLS-1$
      } catch (CoreException e) {
      }
   } else if (project.getFolder(".svn").exists()) { //$NON-NLS-1$
      try {
         readerType = CorePlugin.getDefault().getReaderType("svn"); //$NON-NLS-1$
      } catch (CoreException e) {
      }
   } else if (project.getFolder("CVS").exists()) { //$NON-NLS-1$
      try {
         readerType = CorePlugin.getDefault().getReaderType("cvs"); //$NON-NLS-1$
      } catch (CoreException e) {
      }
   }
}
readerType.shareProject(project, cr, context, MonitorUtils.subMonitor(monitor, 50));



As a side note, the source in my workspace matches the binary version I have installed in Jenkins, but the SVN trunk for Buckminster at Eclipse doesn't match this.

http://dev.eclipse.org/viewcvs/viewvc.cgi/trunk/org.eclipse.buckminster.core/src/java/org/eclipse/buckminster/core/materializer/WorkspaceMaterializer.java?view=markup&root=TOOLS_BUCKMINSTER

Comment 5 Thomas Hallgren 2011-02-09 16:05:50 EST

(In reply to comment #4)
> ... I think that the code should change to read the source URL from
> the .svn subfolder's metadata to ensure that the url it is using is accurate.
> 
I agree. This is a regression introduced by a fairly recent addition. I'll look into this.

Comment 6 Thomas Hallgren 2011-02-10 02:18:41 EST

Fix checked in to helios-maintenance branch, rev 11669.