Re: [buckminster-dev] component materialization

[Knut Wannheden <knut.wannheden@xxxxxxxxx>]

Hi Thomas,

On 12/15/05, Thomas Hallgren <thomas@xxxxxxx> wrote:
> Hi Knut,
> Interesting ideas.
>
<snip/>

> > The reason I'm asking is that I'd like to implement other forms of
> > materialization. Here's two usecases I had in mind.
> >
> > 1. Materializing by creating new Eclipse projects -- I have a Java
> > project which I develop in Eclipse as a set of Eclipse plugins. Some
> > of these plugins depend on 3rd party components. E.g. Apache log4j. I
> > have currently created dedicated Eclipse plugin projects for these
> > components. They don't have any extensions or extension points, just a
> > runtime part. I don't know whether this is good practice or not, but
> > it does allow me to maintain finer grained dependencies. So I was
> > wondering if I could get Buckminster to materialize these 3rd party
> > components as Eclipse plugin projects for me. This would save me from
> > defining these dependencies in a separate buckminster.cspex file and
> > perform copy operations in the initial assembly build as in the
> > dogfood example.
> >
> Interesting thought. To create a specific component reader that would auto-generate a
> plugin-project from a jar-file would not be hard to do. Especially if the jar file is
> equipped with version info etc. Sounds like a great idea.
>
> One way to implement it would be to extend the Maven provider. Another, more flexible
> approach would be to introduce a "binders" extension point. Today, the process of binding a
> materialized artifact to the workspace is fairly simplistic. A specific "jar-as-plugin"
> binder could for instance create the .classpath, .project, and manifest files needed to wrap
> the jar.
>
Since a component type just knows what to read and how to map it to a
CSpec I think a binder concept sounds very interesting. Although I
don't quite understand where they'd come in. Would a provider become a
triplet like (component-type, reader, binder)?

> Could you please add a feature request for this in our bugzilla?
>
Sure.

> If you'd like to have a go at an actual implementation, I'd be more then happy to assist you.
>
Today is my last day at work before I go on holiday. But I'd love to
give it a try next year :-)

> > 2. Materializing by importing existing Eclipse projects -- In our
> > development environment we have an integration area in a shared file
> > system location where we have "prebuilt" read-only copies of all our
> > components. This means that a developer only has to fetch those
> > components from CVS which he intends to make changes to. Required
> > components will be used from the integration area. So I'd like to get
> > Buckminster to materialize these required components by importing the
> > existing projects from the integration area. Buckminster would thus
> > just create some workspace metadata.
> >
> This sounds like something that Buckminster can do out of the box. In a naive setup you
> would need a provider that use a reader of type "url.zipped" (reades multiple files from a
> zip-archive), or "url.catalog" (reads multiple files from a folder) and a component-type of
> "eclipse-project". Your URL's will use the file protocol. I say naive because the "url"
> family readers will not understand versioning. They will act as a reader that only sees the
> latest version of the main branch.
>
Excellent! I'll give that a try then.

> If you store different artifact versions of your shared area, perhaps by adding version
> numbers to the filenames, and you want to benefit from Buckminsters version resolvement
> logic, then you'll need a reader that understands your particular hierarchy and naming. At
> BEA we resolve that by using the well-known maven repository layout and a maven provider.
> The maven reader is not limited to http. It can also be used with the ftp or file protocol.
>
I think we'd have to implement our own reader. But that doesn't seem
like it should be too difficult.

Regards,

--knut