Home » Eclipse Projects » Buckminster dev » Buckminster and p2
| Buckminster and p2 [message #526777] |
Mon, 12 April 2010 20:51  |
 Achim Demelt
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Buckminster and p2 [message #526838 is a reply to message #526777] |
Tue, 13 April 2010 08:12  |
|
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
|
|
|
| Re: Buckminster and p2 [message #526895 is a reply to message #526838] |
Tue, 13 April 2010 12:45 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
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
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 15:37:05 GMT 2024
Powered by FUDForum. Page generated in 0.02980 seconds |
] 
Search
Help
Register
Login
Home
