[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] component materialization
|
Hi Knut,
Interesting ideas.
Knut Wannheden wrote:
Hi there,
In the dogfood example most components are pulled from CVS or SVN,
where they're stored as Eclipse projects. Buckminster materializes
them as-is. There are however also a few 3rd party components (e.g.
Apache log4j) being downloaded from the ibiblio Maven repository.
There the components are defined by a Maven POM and exist in binary
form as jars. Buckminster materializes them as jars inside the hidden
.buckminster Eclipse project.
I don't quite understand how Buckminster determines how a component
should be materialized. But I suspect it's the component provider's
role. Is that correct?
Yes. Each provider is equipped with a reader and a component type. The reader knows _how_ to
read and the component type knows _what_ to read and how it should be interpreted. Our
dogfood resource map utilizes providers that have CVS, SVN, or Maven readers and component
types like "eclipse-project" or "maven". The latter understands how to create a CSpec from a
POM.
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.
Could you please add a feature request for this in our bugzilla?
If you'd like to have a go at an actual implementation, I'd be more then happy to assist you.
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.
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.
Regards,
Thomas Hallgren
