Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] Buckminster and p2

Hi Achim,
Your ideas are very interesting and I have been discussing this in some depth with Henrik. There are things that can be done, such as creating aggregations of repositories that in fact are defined using a CQUERY/RMAP, and there are things that are very difficult, such as bringing in SCM's and moving source into the mix.

The basic problem is that p2 is about immutable things only. Something is identified with an id and a version and once it is used, it can never change. That doesn't play well with SCM's and versions using qualifiers yet to be expanded. My conclusion is therefor that p2 is less ideal when it comes to managing source.

Other things where you can identify an immutable thing with id+version, are of course ideal for p2. Our approach with b3 is to have two main materializers. One for SCM's, and then p2 for everything else. We assume that other types of repositories (or whatever you find out there) can be viewed as p2 repositories one way or another. As you also mention, materializing is just a matter of providing touchpoints.

Let's continue our discussion. "Aggregation by query" is certainly interesting.

Regards,
Thomas Hallgren


On 04/12/2010 10:51 PM, Achim Demelt wrote:
Hi guys,

Maybe this was discussed in the past, but I'm not aware of any such
discussion, so I just bring up this idea that came into my mind while
driving too fast on the German Autobahn this weekend ;-)

What if we made the BOM available as a p2 repository?

I see two main advantages. First, it would enable us to use the p2
materializer no matter where the bundles come from. Right now, that's only
possible if the bundles reside in http:// or file:// based p2 repos. If your
(binary) bundles are checked into SVN or reside in a Maven or Ivy repository
(like the Springsource bundle repository), the p2 materializer cannot be
used. If our resolution result could present itself as a p2 repo, this would
be no problem.

The second advantage is that whenever anyone expects a p2 repo, he can use a
CQUERY/RMAP and resolve the stuff from there. The most obvious use case is
the PDE target platform. Using the current PDE UI, it should be possible to
supply a CQUERY/RMAP (or BOM) instead of a p2 site.

I imagine this to work very similar to p2's mechanism of reading old-style
site.xml files. If such a file is given, p2 computes the meta-information
on-the-fly. The same should be possible when providing a CSPEC or BOM. With
all the meta-information we have available in Buckminster, it shouldn't be
too hard to adapt this to p2 metadata.

If we continue this line of thought, it leads us the next question:

What if we used the p2 materializer exclusively and implement our current
materializers as touchpoints for p2?

Now I admit that this last proposition does not provide any added value in
itself, but it would have probably been the straightforward implementation
if p2 had been around a couple of years earlier. Provided, of course, p2 is
capable of using multiple touchpoints at the same time, like we do when
putting source stuff in the workspace and binary stuff in the target
platform.

What do you think of this? I'm not sure if the cost/benefit ratio is
reasonable for Buckminster, but maybe it's worth considering for b3?

Cheers,
  Achim



Back to the top