Re: [buckminster-dev] component binding

[Knut Wannheden <knut.wannheden@xxxxxxxxx>]

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.

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.

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

Cheers,

--knut