Re: [buckminster-dev] some buckminster questions

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Knut,
Some answers inlined.

> - Why is this following entry duplicated in the rmap? <rm:locator
> searchPathRef="org.eclipse.buckminster"
> pattern="^org\.eclipse\.buckminster(\..+)?" />
Oops. That's an error. Probably caused by a merge. It's been removed now.

> - It would be cool if the materialization could be run in the background :-)
Yes, I agree. There's a problem with that however. I haven't managed to figure out how to 
turn off the Eclipse builder during that time and it's essential that it doesn't kick in 
since it will create classpath containers etc. automatically and prematurely (i.e. before 
everything has reached the final location). It kicks in automatically every now and then as 
soon as something has changed in the workspace, even if I explicitly tell it not to. I 
traced the reason to a timer that, regardless of how locking is performed, will remove the 
lock and send change events. I brought this issue up on the Eclipse platform mailing list a 
while back:

news://news.eclipse.org:119/df1o5s$sm0$1@xxxxxxxxxxxxxxxx
news://news.eclipse.org:119/df2qej$9er$1@xxxxxxxxxxxxxxxx

Any input is of course greatly appreciated.

> - It would be nice if the reference guide pages (linked to from user
> guide) were included in the help index.
They will be eventually. The plan right now is to first put the documentation up on the 
Eclipse Wiki and then work with it there until we are happy with the content and structure. 
That way it will be very easy to collaborate and involve others. Perhaps you'd like to help out?

> - Is it correct that the CSpec for the Buckminster components is
> generated based on the OSGi bundle (the META-INF/MANIFEST.MF file)?

Yes. When Buckminster encounter a plugin or feature component, it will derive the cspec from 
the manifest files.

> And what role do the buckminster.cspex files (the CSpecExtension)
> play?
The cspex allows you to add things that are not present in the manifest (such as the need 
for external jars that has to be present inside of the component at build time). Take a look 
at the buckminster.cspex in the core component and you'll see what I mean.

> I found the aspec and cspec documents to be an interesting read. Seems
> like it might demand a goal-oriented implementation (a la Werkz in
> Maven). Anyway, here are some questions and comments to the
> aspec/cspec documents:
>
> - I don't quite understand how these two documents relate to each
> other. The aspec documents seems to be a copy of cspec with some parts
> ripped out and some parts replaced. Is the idea that a CSpec
> eventually will contain an ASpec plus dependencies?
The cspec will be the logical view that will comprise all info although there never will be 
such an artifact. The current cspec will be replaced by a file that only contains the 
dependencies. We haven't decided on the final name yet but perhaps 'dspec' will be it. The 
thesis is that while it's often easy to derive all dependencies from existing project 
meta-data (such as the plugin manifest or a maven pom file), there's almost never 
information present that would allow you to do the same for actions. Especially if those 
actions in turn are what triggers the dependencies. We also feel that the aspec can be 
optional. If all you want is a dependency graph without respect to actions or purpose, then 
you should be allowed to do that.

> - How are the usages of one component going to be lined up with the
> purposes of external requirements in other components?
It's a one to one mapping.

> - Do you already know when the new work on actions, requirements, and
> usages is going to be available? I couldn't find a project plan or
> requirements list online.
Not at present no. We are working on a more detailed plan. A rough guess would be that we 
will have M3 ready sometime end of Q1 or beginning of Q2 next year. M3 will contain more 
elaborated docs and the aspec stuff.

Regards,
Thomas Hallgren