incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <>
Subject Re: [PROPOSAL] Apache Ace
Date Sun, 05 Apr 2009 02:47:15 GMT
On 4/4/09 7:09 PM, Jason van Zyl wrote:
> 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 resolution.

I usually try to stay out of this shit, but...

I have no idea what you are talking about Jason. To set the record 
straight, p2 replicated what OBR had started years ago. Certainly, p2 
has gone further in some areas than OBR now, but OBR was never intended 
to go into those areas, which were always planned as layers to be built 
on top of OBR.

When Hal started to push the OBR RFC again (which was actually spec'ed 
by Peter and I four years ago or so), there was no mention or discussion 
of p2 at all. It is not like Oracle doesn't work with IBM and use 
Equinox extensively already. The fact of the matter is Hal started to 
push for the completion of OBR because Oracle is using it and wants to 
see it finished. No politics involved within the OSGi Alliance that I am 
aware of, I cannot speak for inside of Oracle.

Luminis' provisioning server has likewise existed for quite some time 
and was using OBR before p2 existed. Additionally, it is based on 
Deployment Admin which has been around for longer than p2 as well. It is 
fine if you don't like the technologies, but don't act like they are 
just copying something p2 has done when the reality is the reverse.

> 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.

Dude, you do realize there has been an implementation of OBR shipping 
with Felix since day one, right?

> 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.

Excellent, then use it.

> 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.

Great, then I guess you've tied your wagon to the winning team.

-> richard

>> Greetings, Marcel
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Thanks,
> Jason
> ----------------------------------------------------------
> 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:

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

View raw message