Re: [buckminster-dev] some buckminster questions

[Knut Wannheden <knut.wannheden@xxxxxxxxx>]

Hi Thomas,

On 12/7/05, Thomas Hallgren <thomas@xxxxxxx> wrote:
> 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.
>

OK. Was afraid I'd missed something.

> > - 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.
>

I can only say that the CVS checkout from the CVS Repository Exploring
perspective seems to handle this somehow. Building doesn't kick in
until all projects have been checked out.

> > - 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?
>

I'm not sure in what ways I'll be able to help out, but I can try. A
wiki is IMHO always a good collaboration tool.

> > - 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.
>

I don't think I understand all the details of this just yet. But I
think it all sounds very good.

So the 'dspec' file would be used for components not using any other
project meta-data (e.g. a Eclipse plugin manifest)?

> > - 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.
>

OK. Then this seems to be similar to the 'configuration' construct in
Ivy (http://www.jayasoft.fr/org/modules/ivy/). I was thinking that the
usages of a component would not only be there to reflect /how/ the
component should be used, but also to some extent /what/ part of that
component should be used. But I assume that should also be possible.

> > - 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.
>

Sounds promising!

Regards,

--knut