incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: [PROPOSAL] Apache Ace
Date Sat, 04 Apr 2009 23:09:39 GMT

On 4-Apr-09, at 12:30 PM, Marcel Offermans wrote:

> Hello Martin,
> On Apr 4, 2009, at 20:39 , Martin Cooper wrote:
>> On Thu, Apr 2, 2009 at 12:52 PM, Marcel Offermans <
>>> wrote:
>>> Hello all,
>>> I would like to formally present the incubator proposal for Apache  
>>> Ace, a
>>> software distribution framework based on OSGi that allows you to  
>>> manage and
>>> distribute artifacts, like e.g. software components.
>>> The full proposal can be found on the wiki at:
>>> I'm looking forward to all questions and feedback, positive or  
>>> negative.
>> Could you comment on how this compares to Equinox p2? It'd be  
>> interesting to
>> understand the similarities and differences.
> Let's start with the similarities. Both systems are designed to  
> distribute software components, and both are based on OSGi.
> Equinox p2 was designed to replace the aging Update Manager in  
> Eclipse. It focusses on installing Eclipse-based applications from  
> scratch and updating them and can be extended to manage other types  
> of artifacts. If you look at the "agent" part, it is geared towards  
> desktop environments

Not true.

Jeff McAffer's demo at EclipseCon is a case in point. He provisioned  
an EC2 node using p2. Jeff's goal from the start with p2 was  
provisioning server's. Anyone looking at the mailing lists would know  
this. Much of what he showed was the dynamic discovery of nodes for  
provisioning from the server side. Now Pascal may have focused on  
desktop and SDK provisioning but Pascal was not the only one involved.  
Jeff is very much focused on server side provisioning as am I.

> (their agent download is about 12 MB) and focusses on having a user  
> on the target system selecting the components or plugins that need  
> to be installed or updated. Looking at the server side, they manage  
> update sites that contain the files the agent can download. As far  
> as I know they don't yet have tooling to show an overview of all  
> targets, nor ways to directly monitor or manage them.
> Apache Ace was designed to be a framework for provisioning based on  
> OSGi standards (whenever available). The "agent" is small (<100kB)  
> and is based on OSGi's DeploymentAdmin which also allows you to  
> install any type of artifact in an extensible way. Being that small,  
> it can also run on small targets like embedded systems and mobile  
> phones. We also don't assume a user on the target system. On the  
> server side, we support OSGi's Bundle Repository (OBR) and we can  
> actively manage targets and "push" software onto them without user  
> interaction. Also, you can have a central overview of these targets  
> and their complete life cycle. There are even mechanisms for doing  
> updates when the target systems are never in direct contact with the  
> provisioning server (because they're in environments where internet  
> access is not allowed). Finally we have complety separated the meta- 
> data necessary for provisioning from the actual components, which  
> means it's possible to host the provisioning server on an internet  
> server whilst keeping the actual components on local networks. This  
> means you can set it up in such a way that you never expose any IP  
> on the internet (assuming you don't consider meta-data about  
> software components to be IP).
> There's probably lots more I can explain, so feel free to keep  
> asking questions, I hope this gives a high level comparison of both  
> systems. Note though, I'm no Equinox p2 expert. :)

Then why are you proposing this when you don't even know what p2 is  
capable of?

OBR has also gone back to RFC so there is no OBR really. There's Hal's  
initial specification and that's it.

As far as I could tell at EclipseCon a bunch of peopled seemed jilted  
to me that IBM went and made p2. I don't know what politics played out  
but OBR is just going to replicate most of what p2 does. For me I  
don't care insofar as Nexus because OBR (when it's actually finished  
being specified and implemented) is just as easy to support on the  
server side as p2. So I honestly don't care and I don't have any  
business relationship with IBM or EclipseSource. I just used what  
worked. p2 worked for our desktop uses cases -- which is incredibly  
important -- and our server side use cases. Maven is now using the  
same solver that p2 is using but that's just general artifact  

Just a note though that the combination and constraining of different  
targets on the desktop is way bigger problem then the server side. At  
least there is a modicum of sanity on the server side, but it's  
complete chaos on the desktop. The node discovery and monitoring is  
relatively easy in comparison to managing consistent environments for  
thousands of developers.

But seriously just come out and be honest if you just want to  
reimplement it. You clearly admit to not knowing what p2 does. And  
yes, it sounds like the p2 people just forged ahead and made something  
they needed because it seems to me like a lot of people talked about  
OBR but didn't really implement anything. I don't think the p2 folks  
wanted to get into a 6 month discussion about the XML format of  
repository metadata and so they might have been a little brisk but  
what's done is done.

If you want to compete just be clear about it because from where I'm  
sitting you haven't talked about anything I haven't seen done with p2  
-- I'm talking about building on p2 here.

It's just my opinion but anyone doing provisioning with OSGi has had  
their asses handed to them on a plate by the p2 guys.

Oleg and I were trying to make something and after looking around at  
everything -- and we did look at OBR -- we decided that p2 was good  
enough and we would help improve that. p2 is going to have hundreds of  
millions of users via Eclipse pretty shortly and server side  
management systems are already cropping up and p2 can be built upon to  
handle these requirements. People can point at the horrible things  
that have happened with p2 lately but it's fixed quickly and that's  
life when serving out that much content to that many people.

There's nothing wrong with competition but I think anyone doing OSGi  
provisioning is just going to look around in a year and find p2 has  
95% of the market. It's a complicated problem and I think p2 is a  
solid base and be improved and adapted to support  things like OBR or  
anything else including non-OSGi systems.

> Greetings, Marcel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

  -- Buddha

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message