Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <366ADA5E-50CD-4AD4-95A1-06DDB2950DF7@sonatype.com>
From: Jason van Zyl <jvanzyl@sonatype.com>
To: general@incubator.apache.org
In-Reply-To: <49D81BB3.1050003@ungoverned.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [PROPOSAL] Apache Ace
Date: Sun, 5 Apr 2009 07:50:33 -0700
References: <91363FE9-DA18-4FDB-B80F-1299A75DE2AF@luminis.nl>
 <16d6c6200904041139x29ea84a8i34f959c448acdaac@mail.gmail.com>
 <69BF31D9-5176-4480-AA5D-E30BCE75132E@luminis.nl>
 <80A4D320-A9CB-46A0-9341-E495CDF77DCE@sonatype.com>
 <49D81BB3.1050003@ungoverned.org>

I know the OBR specification was written years ago, and I'm aware  
Felix shipped with an implementation of it. As I said Oleg and I  
looked at it.  I honestly just found p2 more useful and couldn't find  
any real examples of anyone using OBR.

I don't know what happened in OSGi land and I honestly don't care  
about the politics. Something went awry if none of you can work  
together on this stuff. There is the OSGi Alliance which everyone  
appears to belong to yet there is a massive dichotomy in the  
provisioning space.

For the record in technology land I'm also trying to cull things I  
started for which others have made something better. I'll give up the  
DI bits that I made for Maven and use Guice, and I'll give up the OSGi  
like runtime model I was working on and just use Equinox. Both  
projects I started some 5 years ago but someone made something better.  
I got leap frogged, such is life.

OBR may have started first but there's something to be said for IBM,  
EclipseSource, Yoxos, and Genuitec using this stuff in day-to-day  
production. Much of it is not pretty but that's what happens when you  
have to ship software for living.

I just hope that someone in the mix tries to reconcile the different  
camps. I think there is a good opportunity to use the massive amount  
of information that the p2 community has gained trying to make a  
system that services such a gigantic community like Eclipse users  
along with the server side work that's been done. I think p2 embodies  
my favorite quote about developing software:

<<<
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more  
examples
you look at, the more general your framework will be.

   -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
 >>>

I think the incomplete work of OBR which has good ideas and the  
massive amount of practical work in p2 can be combined to make a  
better system.

On 4-Apr-09, at 7:47 PM, Richard S. Hall wrote:

> 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 <
>>>> marcel.offermans@luminis.nl> 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:
>>>>> http://wiki.apache.org/incubator/AceProposal
>>>>>
>>>>> 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: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>> 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: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

   -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org