[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] CSPEC Resolution and other issues
|
Matt Hollingsworth wrote:
Hello,
Ok, so I’ve gotten to the point to where I want to make a simple RMAP,
CSPEC, and CQUERY that will essentially just check out a project from
CVS. This has led to a number of questions that I couldn’t find
discussed in the docs, as well as a few potential bugs.
How are CSPEC’s resolved? The documentation describes how to create
CSPECS, but not how CQUERY’s or RMAP’s figure out where said CSPECS are.
I inferred that it looks at the root of whatever the location is for a
buckminster.cspec; is that correct?
Yes, this is correct. Worth mentioning is perhaps that use of handcrafted CSPEC's is not the common
case. The CSPEC is often automatically derived from other artifacts (maven POM's, OSGi manifests, etc.).
If so, unless I’m thinking about
this wrong, I have a request. Shouldn’t we be able to explicitly map
CSPECS to project names in the RMAPS, as in specify search paths for
CSPECS that can map project names to CSPEC’s? I say this because it
makes developing complex CSPECS difficult to say the least. Every time
one makes a change, one would have to commit it to CVS, right? If this
isn’t how it works, then how does it?
You don't need to commit to CVS in order for the change to be seen. The resolver will (unless you
explicitly tell it not too, more on that below) always look into your workspace first, the target
platform second, and then use the RMAP. The following will work:
You have a cquery that appoints component A.
Component A lives as a project in your workspace.
In A/buckminster.cspec you add a dependency to B.
Rerun the CQUERY.
The resolver will now try to find B.
No check-ins. Everything is in the filesystem.
To change the resolver default behavior:
There are cases when you don't want the resolver to see the workspace/target platform. You can
control the behavior of the resolver with the CQUERY. Add an advisor node with a pattern that
matches the component name(s) in question, select "Resolution Scope" in the middle pane of the
"Advisor Nodes" tab and uncheck everything but "Resolution Service". This will ensure that no matter
what is found locally, the resolver will always attempt to find things remotely.
Also, has anyone tried making CQUERY’s, RMAPS, and CSPECS that only live
on the filesystem? I’m theorizing that the file:// url is possibly
broken, as I tried downloading the demo.cquery and the demo.rmap and
changing them both to file:// urls (made the demo cquery, which was on
the file system, point to the demo rmap, which was also on the
filesystem), which resulted in the GUI getting stuck on “Resolving
query” indefinitely (well, indefinitely as far as I was concerned, but
it was 10 minutes and then I cancelled it).
That doesn't sound right. Such a resolution should be immediate. Please attach the files and I'll
try to figure out what it is that goes wrong.
The http:// link worked
fine however, both for the demo and for the buckminster-dev cquery. It
would be nice to be able to use the file url for development purposes,
right? I got around that by running an XAMPP server that I already had
sitting around to remount my workspace to http, and it didn’t get stuck
that time (although it didn’t work, but I’m pretty sure that’s my
fault… I haven’t really looked into that part yet).
By the way, the getting started guide worked great, so I’ll be moving it
into my little latex project pretty much word for word (and keep credits
in the comments of course :) ). If someone could confirm the bug that I
mentioned yesterday on the newsgroup (a problem that I had that was also
discussed here:
http://dev.eclipse.org/newslists/news.eclipse.tools.buckminster/msg00018.html
and here:
http://www.nabble.com/Error-Resolving-Buckminster-p15675986.html ), I’ll
add that in as a warning somewhere in the docs as well.
Yes, I think you indeed did find the cause of this problem. Good catch!
I'll prepare an update and post that to the Subclipse JIRA.
Regards,
Thomas Hallgren
