[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Buckminster and p2
|
As Thomas said,
we have discussed this several times in the past, and there are several
difficulties regarding SCM based components and we never managed to
overcome (even if we partially solved some of them) - but perhaps some
additional discussion and some new bright ideas can improve things...
Anyway - when it comes to provisioning source, it would be possible to
have a workspace touchpoint that is capable of installing projects. That
would be the (relatively) easy part.
Our discussion regarding provisioning of SCM based components went
something like: To make it work, it is required to view the IU as some
sort of handle to the component - i.e. the handle is immutable, but what
it refers to is not. This however means that p2 alone can not be used to
resolve - the handle IU would need to list all versions of the
underlying component as provided capabilities. When materializing - one
of these capabilities is what is installed into the workspace. This
could probably work because the handle is separate from the actual
component.
Since p2 has immutable IUs the handleIU needs to be given a new version
each time there are more versions in the SCM of the component it
represents. But this could possibly be modeled some other way (a base
connector, and fragments?).
An alternative would be to index a SCM and then view the SCM + index as
a p2 repo. (An index is required since p2 requires the meta data locally
to be able to resolve, and it is not possible to scan the entire repo to
build the index on each resolution = too slow). This open a different
can of worms - where is this index stored? In the SCM? On some server on
Internet? It can take a long time to index a large SCM. Old stuff seldom
change - could indexes be created collaboratively?
Using Git opens new possibilities - with Git, repositories are made
available locally before they are used - so this may offer a way to make
this work (indexing on the fly would perhaps not be prohibitivie) - but
how are then other SCM's handled? And how do you know which Git
repositories to get?
Maybe this triggers some ideas...
Regards
- henrik
On 4/13/10 10:12 AM, Thomas Hallgren wrote:
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
