Re: [buckminster-dev] component binding

[Thomas Hallgren <thomas@xxxxxxx>]

Knut Wannheden wrote:
> On 1/18/06, Thomas Hallgren <thomas@xxxxxxx> wrote:
>   
> > One thing is important to remeber. Buckminster does not stipulate that a
> > component needs to be a project, nor that it must become one when it is
> > materialized. Some artifacts are never bound at all. All artifacts are
> > however known to Buckminster (i.e. stored in meta-data) once they are
> > successfully materialized. The methods that you mention does not only
> > apply to projects. They can also be used on artifacts that are
> > materialized but not projects as such. Buckminster will normally put
> > such artifacts under the umbrella project ".buckminster" so that they
> > can be accessed using the Eclipse navigator. Perhaps what you are trying
> > to achieve here is simply a non-project construction?
> >
> >     
>
> In the latest updates to the documentation I read that you now also
> use the term artifact to refer to components. I assume that is the
> case above. Correct me if I'm wrong.
>   
You're not wrong :-) We have still to establish a "correct" glossary at 
some point. I'll try to differentiate between the terms component and 
artifact in the future. A separation that I find attractive (but didn't 
use above) is to say that a component consists of artifacts.
> I do want to materialize and bind these components as proper Eclipse
> projects as they represent the modules of the software I want to
> develop (edit) with Eclipse. So it's not a non-project construction.
>
>   
OK, I suspected that.
> Now I'd like to take a shot at adding this binder extension point. And
> I have a question for you.
>
> I am not quite clear what responsibilities the involved object should
> end up having if there were an additional binder object. This is how
> it currently works as I understand it:
>
>  - The reader type controls what directory the component will get
> materialized into (IReaderType#getMaterializationLocation()). This
> will either be a top-level directory in the workspace or a directory
> inside the .buckminster project.
>   
Yes, that's correct. I might add that this location is a default 
location that the user may override using the last page of the resolver 
wizard if the reader permits it to be overridden.
>  - The component reader will perform the materialization
> (IComponentReader#materialize()).
>  - The component type knows if the component has a .project file
> (IComponentType#hasProjectDescription()). If it does the
> BindSpecification will contain a ProjectBinding object for this
> component, if not it will contain an ExternalBinding object.
> - The IBinderService will bind the components according to the
> BindSpecification.
>
> So if I understand this correctly...
you do.
>  then in the case of a maven
> component materialized from CVS it is the CVS component reader
> (performing the materialization) which actually creates the "missing"
> .project file. I thought it would be the DefaultBinderService. Is this
> correct?
>   
No, that part is wrong. The DefaultBinderService is the one. A missing 
.project file can only be created when the binder discovers that the 
project for a ProjectBinding does not exist. The binder will always 
attempt to do a IWorkspace.loadProjectDescription() to obtain the 
description, i.e. parse the .project file into a ProjectDescription 
object. If it fails to do that, it will instead use 
IWorkspace.newProjectDescription() and then subsequently create the 
project (the code that I included in a previous mail). This is the one 
and only case when Buckminster, as it stands today, will create a 
.project file.

- thomas