[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] SAP Contribution
- From: "Todorova, Katya" <katya.todorova@xxxxxxx>
- Date: Wed, 10 Nov 2010 17:15:53 +0100
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: firstname.lastname@example.org
- Thread-index: Act/wKokJhfv6pmDRVe5loOk8rrwdwBME+OA
- Thread-topic: [p2-dev] SAP Contribution
Hi Igor, Daniel, all
The answers to your questions are inlined.
>>Are you able to share any specific size targets in K or M bytes and more
>>interestingly why you need to get p2 that small?
On one hand we need it small, because we are going to use it for installation of a relatively small product. And it's not reasonable to have an
installer comparable in size to the product we are going to install.
On the other hand, we want to bring to our target system only the functionality we actually use, nothing more. And since the installer would be
transferred over the Internet, its size affects the network traffic, download speed and last but not least the disk space on the target virtual image.
Our initial target was 1Mb for the whole installer. It should include only p2 and the infrastructure p2 requires - OSGi framework, ds, etc.
Since we use Equinox, which itself is around 1Mb, we thought our target size over and decided to make it more achievable in the current circumstances.
So we minimized p2 and left as a next step to think about p2 usage on top of a smaller runtime or even without OSGi. Still, we didn't reduce
p2 size by all means. It's important for us to use the standard p2, so the reduced version should work in our scenario as well as in Eclipse.
>> Could you provide us some hints about the way you achieved that reduction?
>> Which parts of p2 did you remove?
The reduction was made in two directions:
- decoupling p2 from other components it uses in order to be able to plug simple implementations instead of existing rich ones. For example, in dark install
mode we do not need monitoring and cancelation, therefore we don't need jobs
- modeling Eclipse specific logic with abstractions, provided by OSGi core specification. For example, extension points could be replaced with services.
We removed preferences, current transport implementation, extension points usage and jobs usage.
For more technical details, please find a link to the sources of our proof of concept:
At Eclipse Summit Pascal mentioned that replacing extension points with services for example could lead to unexpected side effects.
So before contributing back changes like this one, I would like to discuss them in the mailing list - is there a better solution, do they fit into p2 architecture, etc.
I will need your help and support in that.
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Igor Fedorenko
Sent: Tuesday, November 09, 2010 5:26 AM
Subject: Re: [p2-dev] SAP Contribution
Are you able to share any specific size targets in K or M bytes and more
interestingly why you need to get p2 that small?
On 10-11-08 03:08 PM, Todorova, Katya wrote:
> SAP is currently exploring new spaces, tightly coupled with OSGi Core and Enterprise specifications. In the course of that we are looking for a suitable provisioning
> technology to manage the lifecycle of a number of OSGi-based components. Naturally, p2 looks like a good candidate for that.
> The current size of p2 does not meet our constraints and requirements for installing our products on all server nodes in large landscapes.
> The provisioning with the product definition should be downloaded fast, with minimal network traffic, requiring minimal disk space. We are looking for a solution
> where the installer is relatively small compared to the actual product.
> So we started looking for ways to use only parts of the already existing functionality, while keeping p2 stable and reliable.
> We managed to reach close to our desired target and currently p2 is widely used internally by SAP Java Server team.
> We are committed to use standard technologies and not fork already existing and proven open source projects. Therefore, we are looking forward to contributing
> all changes back to the p2 project and evolve it even further.
> Our engagement with p2 is increasing and we will definitely need your help and guidance in this journey.
> Kind regards,
> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
> Sent: Sunday, November 07, 2010 5:53 AM
> To: P2 developer discussions
> Subject: [p2-dev] SAP Contribution
> As you may remember, during the summer, members of the SAP Java Server team expressed their desire of using p2 under tight size constraints .
> Despite their patches, we have not been really welcoming. This week spent at Eclipse Summit, I have had the opportunity to address that by meeting with several members of their team and hear them re-express their desire to become contributors to p2.
> Though their needs and constraints are slightly different than those we have in Eclipse and Equinox, meeting these will help us reach the wider audience we had always foreseen for p2.
> All that to say that they will be more active and will need our help and guidance.
>  http://dev.eclipse.org/mhonarc/lists/p2-dev/msg03271.html
> p2-dev mailing list
> p2-dev mailing list
p2-dev mailing list