Home » Eclipse Projects » Buckminster dev » RE: [buckminster-dev] CSPEC Resolution and other issues
|RE: [buckminster-dev] CSPEC Resolution and other issues [message #11665]
||Mon, 24 March 2008 12:01
Originally posted by: hollings.cern.ch|
Thanks for the help! I'll digest all of this and reassure myself that I'm
not doing something dumb with the problems that I ran into with the file
urls before I post the files.
By the way, I setup a svn repository for the docs that I'm writing. It's
fairly empty right now, since I only have the one .tex file that I'm working
on (which is also not up to date with what I've written so far right now and
also still very rough), but I'll just go ahead and give the link for it:
[mailto:email@example.com] On Behalf Of Thomas Hallgren
Sent: Monday, March 24, 2008 11:16 AM
To: Buckminster developer discussions
Subject: Re: [buckminster-dev] CSPEC Resolution and other issues
Matt Hollingsworth wrote:
> 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
> 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:
> 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.
buckminster-dev mailing list
Current Time: Sun Dec 08 19:11:19 EST 2013
Powered by FUDForum
. Page generated in 0.01481 seconds