Community
Participate
Working Groups
Build Identifier: I20100608-0911 Starting any action leads to the exception stated below. My target platform contains launchers from the Eclipse update site as Helios do not contain them all. org.eclipse.core.runtime.CoreException: Basedir C:\Users\...\workspace\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.swt.motif.solaris.sparc_3.6.0.v3650b.jar is not a directory at org.eclipse.buckminster.ant.AntRunner.handleInvocationTargetException(AntRunner.java:167) at org.eclipse.buckminster.ant.AntRunner.run(AntRunner.java:322) at org.eclipse.buckminster.ant.actor.AntActor.internalPerform(AntActor.java:254) at org.eclipse.buckminster.core.actor.AbstractActor.perform(AbstractActor.java:186) at org.eclipse.buckminster.core.internal.actor.PerformManager$DirectActionInvocation.execute(PerformManager.java:143) at org.eclipse.buckminster.core.internal.actor.PerformManager.internalPerform(PerformManager.java:454) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:293) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:305) at org.eclipse.buckminster.ui.InvokeAction$ActionJob.runInWorkspace(InvokeAction.java:81) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: Basedir C:\Users\...\workspace\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.swt.motif.solaris.sparc_3.6.0.v3650b.jar is not a directory at org.apache.tools.ant.Project.setBaseDir(Project.java:823) at org.apache.tools.ant.Project.setBasedir(Project.java:804) at org.apache.tools.ant.helper.ProjectHelper2$ProjectHandler.onStartElement(ProjectHelper2.java:712) at org.apache.tools.ant.helper.ProjectHelper2$RootHandler.startElement(ProjectHelper2.java:501) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:209) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.eclipse.ant.internal.core.ant.InternalAntRunner.parseBuildFile(InternalAntRunner.java:347) at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:633) at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:495) at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.buckminster.ant.AntRunner.run(AntRunner.java:318) ... 9 more Reproducible: Always
I don't understand why an ant-script would make an attempt to set the sparc plugin as its basedir. Can you provide an example that reproduces this error?
Trying to investigate this problem in detail. First I went to org.apache.tools.ant.helper.ProjectHelper2$AntHandler. There it says starting in line 711: if (project.getProperty("basedir") != null) { project.setBasedir(project.getProperty("basedir")); After I did not cope with continueing this path I then rethought the whole problem. I wonder about why this plugin is affected by the Buckminster actions at all. For example if I use "buckminster.clean" it processes all my own bundles in the workspace, and afterwards it starts with this o.e.swt.motif.solaris.sparc plugin. Like this: [start org.eclipse.swt.motif.solaris.sparc:osgi.bundle$3.6.0.v3650b#buckminster.clean] [ant] Buildfile: C:\Users\GuiteMedia\Desktop\eclipse\configuration\org.eclipse.osgi\bundles\788\1\.cp\org\eclipse\buckminster\pde\antscripts\build.xml org.eclipse.core.runtime.CoreException: Basedir C:\Users\GuiteMedia\Desktop\MOST-workspace\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.swt.motif.solaris.sparc_3.6.0.v3650b.jar is not a directory Basedir C:\Users\GuiteMedia\Desktop\MOST-workspace\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.swt.motif.solaris.sparc_3.6.0.v3650b.jar is not a directory Shouldn't those actions only be applied on bundles in the workspace? Regards Axel
(In reply to comment #2) > Shouldn't those actions only be applied on bundles in the workspace? > Yes, but there is one exception. Some bundles in the TP are unpacked into directories. P2 does this as part of the provisioning in order to "install" the bundle into a runnable form. Consequently, when Buckminster is tasked with delivering this bundle, it needs to create a jar from that directory. This leaves some debris that needs to be cleaned up. Is the bundle present in your TP? If it is, is it in the form of a jar or a directory?
(In reply to comment #3) > This leaves some debris that needs to be cleaned up. > > Is the bundle present in your TP? If it is, is it in the form of a jar or a > directory? In the directory C:\Users\...\workspace\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\ the following two files exist: org.eclipse.swt.motif.solaris.sparc.source_3.6.0.v3650b.jar org.eclipse.swt.motif.solaris.sparc_3.6.0.v3650b.jar Looks like all the other platforms, too. There are no equally named directories (only for equinox launchers, not for swt).
Funny then, that Buckminster should consider it to be unpacked. It could be explained by a bogus entry in the feature that requires it (missing unpack="false" or a present unpack="true")? What feature is that? The org.eclipse.rcp feature looks correct.
If I open my site feature in a dependency visualization, uncheck the "Filter Target Platform" checkbox then the o.e.swt.motif.solaris.sparc plugin is only referenced by org.eclipse.swt (yellow connection) and org.eclipse.rcp (green connection). The only bundle which is red (not resolved) is org.eclipse.equinox.p2.user.ui, but that seems to be another problem (feature is contained in TP as binary as well as source).
FIXED! As usually the solution was completely independent of the error message. I renamed my build feature a few weeks ago and somehow there were still some old references in the pde meta data or something. Found it while playing with the cquery wizard. During materialisation there occured a warning about that the project had not the same name as the .project file. After I searched for the wrong name it appeared (within the old project) in the package explorer. I removed the whole project and everything worked :-)
