Home » Archived » Buckminster » Cannot resolve with Eclipse 3.7 any more
|
Re: Cannot resolve with Eclipse 3.7 any more [message #765858 is a reply to message #765812] |
Wed, 14 December 2011 19:41 |
|
Hi Thorsten,
Did you try with a new emtpy workspace and a new empty TP?
- thomas
On 2011-12-14 18:59, Thorsten Meinl wrote:
> Just switched to Eclipse 3.7 (well, I tried at least), but Buckminster
> stopped working. Cqueries that used to work before (in Eclipse 3.6), are
> now complaining about several bundles that cannot be found, because (e.g.)
>
> Resolution attempt ended with exception: CSpec org.knime.webanalytics
> has no action, group, or local artifact named bin.includes
>
> There are dozens of bundles with similar error messages. Of course they
> are proper bundles and if I check them out manually from SVN, everything
> works fine. Any ideas what is wrong here? There is not further
> information in the log file and logging level INFO also does not show
> anything useful.
>
> I'm using Eclipse 3.7.1 with BM
>
> org.eclipse.buckminster.core.feature_1.4.0.v20111129-1531
> org.eclipse.buckminster.pde.feature_1.4.0.v20111129-1352
> org.eclipse.buckminster.subclipse.feature_1.4.0.v20110910-0906
>
> Cheers,
>
> Thorsten
|
|
|
Re: Cannot resolve with Eclipse 3.7 any more [message #765892 is a reply to message #765858] |
Wed, 14 December 2011 21:07 |
Thorsten Meinl Messages: 85 Registered: July 2009 |
Member |
|
|
Yes, it was a completely new workspace. And I don't use an explicit TP,
I let Buckminster handle everything.
Am 14.12.2011 20:41, schrieb Thomas Hallgren:
> Hi Thorsten,
>
> Did you try with a new emtpy workspace and a new empty TP?
>
> - thomas
>
> On 2011-12-14 18:59, Thorsten Meinl wrote:
>> Just switched to Eclipse 3.7 (well, I tried at least), but Buckminster
>> stopped working. Cqueries that used to work before (in Eclipse 3.6), are
>> now complaining about several bundles that cannot be found, because
>> (e.g.)
>>
>> Resolution attempt ended with exception: CSpec org.knime.webanalytics
>> has no action, group, or local artifact named bin.includes
>>
>> There are dozens of bundles with similar error messages. Of course they
>> are proper bundles and if I check them out manually from SVN, everything
>> works fine. Any ideas what is wrong here? There is not further
>> information in the log file and logging level INFO also does not show
>> anything useful.
>>
>> I'm using Eclipse 3.7.1 with BM
>>
>> org.eclipse.buckminster.core.feature_1.4.0.v20111129-1531
>> org.eclipse.buckminster.pde.feature_1.4.0.v20111129-1352
>> org.eclipse.buckminster.subclipse.feature_1.4.0.v20110910-0906
>>
>> Cheers,
>>
>> Thorsten
>
|
|
|
Re: Cannot resolve with Eclipse 3.7 any more [message #765904 is a reply to message #765892] |
Wed, 14 December 2011 21:37 |
|
On 2011-12-14 22:07, Thorsten Meinl wrote:
>>> There are dozens of bundles with similar error messages. Of course they
>>> are proper bundles and if I check them out manually from SVN, everything
>>> works fine. Any ideas what is wrong here? There is not further
>>> information in the log file and logging level INFO also does not show
>>> anything useful.
>>>
Did you try logging level DEBUG?
- thomas
|
|
| | |
Re: Cannot resolve with Eclipse 3.7 any more [message #766317 is a reply to message #766220] |
Thu, 15 December 2011 14:48 |
Thorsten Meinl Messages: 85 Registered: July 2009 |
Member |
|
|
Hi Thomas,
I did some debugging and I believe I found the problem: all plug-ins
that cannot be resolved have cspec extension that alter the bin.includes
artifact (not all of our plug-ins do this so some worked, some others
didn't). These plug-ins do have bin.includes if they are materialized
but they do not have this attribute during resolution. The reason is
likely a change in CSpecFromSource#generate. The Eclipse 3.6 version of
BM gets the bin.includes entry from the build.properties in any case,
see line 292:
IBuildEntry binIncludesEntry = build.getEntry(IBuildEntry.BIN_INCLUDES);
The 3.7 version however, does *not* get the value if read from a
non-filesystem reader (see lines 292ff):
if (getReader().isFileSystemReader()) {
File baseDir = getReader().getLocation();
binIncludes = expandBinFiles(baseDir, build);
srcIncludes = expandSrcFiles(baseDir, build);
} else {
binIncludes = Collections.emptyList();
srcIncludes = Collections.emptyList();
}
And now the behaviour makes sense, because during resolution the plug-in
are read from SVN and thus the bin.includes attribute is not added to
the CSpec (and thus cannot be altered by the cspex). Once materialized,
they are read from file system and everything works fine.
To me, this looks like a regression on the 3.7 version.
(This also explains why everything worked in our Jenkins build, because
there the components are already present in the file system when the
import starts).
Shall I open a bug for this one?
Cheers,
Thorsten
Am 15.12.2011 12:47, schrieb Thomas Hallgren:
> My guess would be that the one of the following files aren't parsable by
> a 3.7 Bucky:
>
> META-INF/MANIFEST.MF
> buckminster.cspex
> build.properties
>
> I.e. buckminster is not able to create a correct cspec from them. This
> should be easy enough to detect if you have Bucky installed in an IDE
> where you checkout the project. Just right click on the project and
> select "Buckmisnter" -> "View CSpec..."
>
> Given that it is parsable using 3.6, this seems like some kind of
> regression so I'd be interested to know what it is that fails.
>
> - thomas
>
>
> On 2011-12-15 10:01, Thorsten Meinl wrote:
>> Am 14.12.2011 22:37, schrieb Thomas Hallgren:
>>> Did you try logging level DEBUG?
>> Yes, this is what I get (among other similar errors):
>>
>> Reading remote file
>> https://bimsvn.inf.uni-konstanz.de/repository/bioml/trunk/KNIME/org.knime.ext.sun/META-
>>
>> INF/MANIFEST.MF#HEAD
>> Reading remote file
>> https://bimsvn.inf.uni-konstanz.de/repository/bioml/trunk/KNIME/org.knime.ext.sun
>>
>> /buckminster.cspex#HEAD
>> org.knime.ext.sun:osgi.bundle: Found match 2.6.0.qualifier:#31828
>> org.knime.ext.sun:osgi.bundle: Using provider
>> svn(https://{0}:{1}@bimsvn.inf.uni-konstanz.de/repository/bioml/trunk
>>
>> /KNIME/{2}?moduleAfterBranch&moduleAfterTag[https://null:null@bimsvn.inf.uni-konstanz.de/repository/bioml/trunk
>>
>> /KNIME/org.knime.ext.sun?moduleAfterBranch&moduleAfterTag])
>> Reading remote file
>> https://bimsvn.inf.uni-konstanz.de/repository/bioml/trunk/KNIME/org.knime.ext.sun/plugin.xml#31828
>>
>> Reading remote file
>> https://bimsvn.inf.uni-konstanz.de/repository/bioml/trunk/KNIME/org.knime.ext.sun
>>
>> /build.properties#31828
>> Reading remote file
>> https://bimsvn.inf.uni-konstanz.de/repository/bioml/trunk/KNIME/org.knime.ext.sun/.classpath#31828
>>
>> org.knime.ext.sun:osgi.bundle: Resolution attempt ended with
>> exception: CSpec org.knime.ext.sun has no action, group,
>> or local artifact named bin.includes
>> org.knime.ext.sun:osgi.bundle: No provider was found that could
>> resolve the request
>> org.knime.ext.sun:osgi.bundle: Using search path knime-trunk-binaries
>> org.knime.ext.sun:osgi.bundle: Trying provider
>> p2(http://merkur02.inf.uni-konstanz.de/knime/trunk/org.knime.update.org
>>
>> /[http://merkur02.inf.uni-konstanz.de/knime/trunk/org.knime.update.org/])
>> org.knime.ext.sun:osgi.bundle: Rejecting provider
>> p2(http://merkur02.inf.uni-konstanz.de/knime/trunk
>>
>> /org.knime.update.org/[http://merkur02.inf.uni-konstanz.de/knime/trunk/org.knime.update.org/]):
>> Score is below
>> threshold
>> org.knime.ext.sun:osgi.bundle: No provider was found that could
>> resolve the request
>>
>>
>> What can I do to track down the problem?
>>
>> Cheers,
>>
>> Thorsten
>
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 23:54:51 GMT 2024
Powered by FUDForum. Page generated in 0.03682 seconds
|