[PROPOSAL] Apache Ace

[Marcel Offermans <ma...@luminis.nl>]

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.

Greetings, Marcel


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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

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

Re: [PROPOSAL] Apache Ace

["Richard S. Hall" <he...@ungoverned.org>]

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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

There's nothing for me to be insincere about. Beyond providing some  
context for most people that don't know I am not going to expend any  
effort on implementation, but I would be happy to talk about the  
problem of provisioning which is why I gave a +1. So it's in the hands  
of those that care. If folks want to do the work then I do feel they  
should go for it.

I saw the proposal, someone mentioned p2, I use p2, I gave my opinion.

I would only ask that these proposals have a little more clarity,  
context, and honesty. Everyone seems to know exactly what I'm talking  
about with respect to p2 yet none of that is reflected in the  
proposal. It's a little like dealing with patent lawyers: "this system  
uses 4 bits, not 5 so it's completely different, lightweight and  
orthogonal."

A little background on OBR and p2 could only be helpful for people  
trying to understand the landscape while reading the proposal.

As for my agenda, there's nothing that isn't public. Sonatype has  
implemented a product that supports p2. We actually haven't done any  
work on p2 itself yet but we probably will in the next 6 months. We  
effectively created a product in a very short period of time and it  
was at the behest of our clients. So I would relay that to people: p2  
is a viable platform. That said insofar as Nexus goes it would take a  
week to implement support for a completely different system so we're  
not wedded to p2 as a business model. If p2 disappeared tomorrow it's  
not of any particular consequence to Sonatype so talking about p2 is  
nothing more then me being a very happy user. p2 just happens to be  
what our clients are asking for so we created support for it on the  
server side. I recommend p2 to folks looking at provisioning. All  
publicly stated. If that's an agenda then I guess I have one.

I think p2 is solid and pretty advanced and if I am genuinely in  
anything it's asking, for your sakes, not to make something that no  
one is going to use. That's my agenda if I have one. You've got IBM  
and Redhat and a slew of other companies (lots of small ones too)  
working on it, it's all there to look at and the code is not terribly  
hard to work with. You could make any provisioning system with it  
including anything you're talking about here.

If you guys want to work on something else, seriously, go for. I'd be  
happy to share use cases as we've dealt with 5 all the way up to 3k  
machines.

On 5-Apr-09, at 6:40 PM, Niclas Hedhman wrote:

> On Mon, Apr 6, 2009 at 2:11 AM, Jason van Zyl <jv...@sonatype.com>  
> wrote:
>
>> As I said in the previous email if you want to make a competing  
>> system
>> that's fine. But don't couch the proposal as something that's new  
>> and hasn't
>> been addressed elsewhere because it has.
>
> Jason,
> I don't know why you got so worked up over this proposal. You seldom
> raise your concerns here, and when you do it this "loudly", it sounds
> like you are on an agenda, and with your recent commitment to Eclipse
> Foundation, such suspicion is yet stronger. I will assume that is not
> the case. And in the end, you make a turn-around and say "You guys
> should go for it.". I hope that is sincere.
>
> It is barely the first time a project is overlapping or competing with
> a known large project. And whether or not P2 covers the same space or
> not is also fairly irrelevant.
>
> As for the argument; "95% will use Eclipse..." Even if that would be
> true, it is irrelevant and you if anyone should know that. Ant had
> close to 100% of users in Java-land and won "Best Software" kind of
> awards all over the place, by the time you started Maven. Should that
> argument have stopped you from trying? Do you regret that Maven
> started?
>
> I also find OBR vs P2 argumentation being a non-issue. Ace can in
> principle work with both, if the community choose to support P2. IMHO,
> P2 is fairly "heavy" and not suitable for many people. And I don't
> like to live in the world with 'single choice', where a faceless mob
> has made my choice out of numbers alone. I happen to choose the
> technology that best suits _my_ needs. Some years ago that was Maven
> over Ant, now it is IDEA over Eclipse, Jetty over Tomcat for tests,
> and so on...
>
>
> Cheers
> -- 
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> 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

Re: [PROPOSAL] Apache Ace

[Niclas Hedhman <ni...@hedhman.org>]

On Mon, Apr 6, 2009 at 2:11 AM, Jason van Zyl <jv...@sonatype.com> wrote:

> As I said in the previous email if you want to make a competing system
> that's fine. But don't couch the proposal as something that's new and hasn't
> been addressed elsewhere because it has.

Jason,
I don't know why you got so worked up over this proposal. You seldom
raise your concerns here, and when you do it this "loudly", it sounds
like you are on an agenda, and with your recent commitment to Eclipse
Foundation, such suspicion is yet stronger. I will assume that is not
the case. And in the end, you make a turn-around and say "You guys
should go for it.". I hope that is sincere.

It is barely the first time a project is overlapping or competing with
a known large project. And whether or not P2 covers the same space or
not is also fairly irrelevant.

As for the argument; "95% will use Eclipse..." Even if that would be
true, it is irrelevant and you if anyone should know that. Ant had
close to 100% of users in Java-land and won "Best Software" kind of
awards all over the place, by the time you started Maven. Should that
argument have stopped you from trying? Do you regret that Maven
started?

I also find OBR vs P2 argumentation being a non-issue. Ace can in
principle work with both, if the community choose to support P2. IMHO,
P2 is fairly "heavy" and not suitable for many people. And I don't
like to live in the world with 'single choice', where a faceless mob
has made my choice out of numbers alone. I happen to choose the
technology that best suits _my_ needs. Some years ago that was Maven
over Ant, now it is IDEA over Eclipse, Jetty over Tomcat for tests,
and so on...


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

I have no problem with it per se. You guys should go for it. It's your  
effort and I'm not trying stop you but only draw some attention to the  
surrounding environment. I think the proposal should attempt to be a  
little more clear about but that's was a request not something I was  
specifically asking for. You'll do what you do, if you guys figure  
stuff out with the p2 guys great. If not, that's fine too.

+1

On 5-Apr-09, at 12:50 PM, Karl Pauls wrote:

> I'm not sure I understand what your problem with this proposal is
> exactly but I sure would like to. Let me try to get some things clear
> in order to be able to get to the bottom of this. Don't let any
> previous comments side-track you and lets try to focus on the
> proposal:
>
> I don't see where the proposal is mentioning OBR in the first place.
> Let alone where it would say anything about it being a standard or
> anything. Its only listed as an external dependency.
>
> There is no pointer to OBR (other then that it is a dependency) nor is
> there a pointer to p2. That is not suspicious as the project is not
> about any of the two other then it should be able to use obr and p2
> repositories and infrastructure where it makes sense.
>
> I completely agree that it would be great if there would be an active
> and healthy collaboration between the projects but I'm not sure this
> has to be in the proposal. It certainly doesn't say anything to the
> opposite (unless I'm missing something?).
>
> Finally, the proposal already does say: "When assembling software out
> of reusable components, the task of deploying software onto an ever
> increasing number of targets is not trivial to solve. This becomes
> even harder when these targets require different components based on
> who's using them." What else do you think is necessary to make it
> clear that provisioning is a hard problem as you say?
>
> From this point, would you say that what you like to see is a
> paragraph that mentions that the current luminis implementation uses
> OBR and that the project will look into using p2 as well? I'm sure
> that this can be arranged.
>
> regards,
>
> Karl
>
>> I'm suggesting that  you two groups figure out how to work together  
>> on a
>> very hard problem.
>>
>> I'm also saying that you are unlikely to out do the 5 man years in p2
>> already.
>>
>> As I said in the previous email if you want to make a competing  
>> system
>> that's fine. But don't couch the proposal as something that's new  
>> and hasn't
>> been addressed elsewhere because it has.
>>
>> You might want to be more clear in the proposal about p2 being a  
>> competitor,
>> also make it clear that OBR has gone back to specification, and  
>> what it is
>> you're actually working from. So when a user or potential developer  
>> looks at
>> this and says what specification are you working from they can see  
>> "there
>> isn't one yet", and if they ask "what about p2?", then it's clear you
>> decided not to collaborate with them. I think you can even point  
>> out that
>> they didn't collaborate with you either. Give people all the  
>> information.
>>
>> When I walked into the OSGi BOF at Eclipse I was dumbfounded. The  
>> same dose
>> of sniping and grin fucking as other groups I've worked with which  
>> was
>> disappointing but I guess I'm not surprised. There were attacks  
>> abound at
>> EclipseCon. The way p2 came into existence probably could have been  
>> handled
>> better, no doubt. But I don't find guys like Hal very compelling  
>> with his
>> melodrama
>> (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html 
>> ).
>>
>> Make it clear to people looking at the proposal that provisioning  
>> is a hard
>> problem. These arguments about the "Eclipse way" of p2 and non- 
>> focus on
>> server side or other types of systems is nonsense. If you actually   
>> have a
>> pointer to p2 in your proposal -- which is conspicuously absent --  
>> siting
>> them as a direct competitor users will have a clear point of  
>> reference. If
>> people had the background story they will probably go WTF just like  
>> I did.
>
>> Both sides of the p2/OBR seem to be equally obstinate and non- 
>> collaborative.
>> I used p2 because from a technical level as an end user because it  
>> worked.
>> There are nightly builds, lots of documentation and at least 5 people
>> working on it full-time at any given point in time. If you look at  
>> the p2
>> code and the OBR spec they are 90% the same thing and any  
>> differences are
>> easily compensated for with a little effort.
>>
>> Competition is fine, I would just be more open about that aspect of  
>> it in
>> the proposal.
>>
>> On 5-Apr-09, at 8:47 AM, Karl Pauls wrote:
>>
>>> On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl <jv...@sonatype.com>
>>> wrote:
>>>>
>>>> On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:
>>>>
>>>>> Hello Jason,
>>>>>
>>>>> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>>>>>
>>>>>>> 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 is very much focused on server  
>>>>>> side
>>>>>> provisioning as am I.
>>>>>
>>>>> Let me rephrase that, it's geared more towards desktop and server
>>>>> environments, as compared to smaller (embedded, mobile)  
>>>>> environments.
>>>>> That
>>>>> was the point I was trying to make here.
>>>>>
>>>>>>> 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?
>>>>>
>>>>> We started working on this system when p2 did not even exist. I  
>>>>> even
>>>>> remember talking to Jeff in those days about our system, but they
>>>>> decided to
>>>>> make their own, so you could equally well make this argument the  
>>>>> other
>>>>> way
>>>>> round.
>>>>>
>>>>
>>>> I'll use the same story I used on Richard. I created a DI and  
>>>> runtime
>>>> system
>>>> 5 years ago. So what. Guice and Equinox have a massive user  
>>>> community,
>>>> professional support is available for both and so I will cull the
>>>> technologies I developed. I don't think it really matters so much  
>>>> who was
>>>> first but who got to a production system first that is known and  
>>>> support
>>>> by
>>>> thousands of users.
>>>
>>> Are you suggesting that we shouldn't incubate projects that overlap
>>> with an existing production system outside the ASF?
>>>
>>>>>> 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.
>>>>>
>>>>> In my opinion, p2 is fine if you are already doing everything "the
>>>>> Eclipse
>>>>> way" and are targetting desktops and servers. There are however  
>>>>> other
>>>>> types
>>>>> of systems that need provisioning, and Apache Ace tries to cater  
>>>>> for
>>>>> those
>>>>> too.
>>>>>
>>>>
>>>> Again you haven't really even looked at p2. What is the "Eclipse  
>>>> way" ?
>>>> You're going to make/keep another system entirely because it's the
>>>> "Eclipse
>>>> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so  
>>>> I'm not
>>>> sure what the "Eclipse way" means. I'll repeat again that p2 is not
>>>> targeting desktops whatever aspects may appear most visible right  
>>>> now. I
>>>> really don't think there is a system that couldn't be provisioned  
>>>> even
>>>> with
>>>> p2 in its current state. I have personally not found one yet.
>>>
>>> I don't think anyone is attacking p2. If people like and use it:
>>> great. I certainly think the proposed project should be able to
>>> interoperate with p2 repositories seamlessly. It sure would be great
>>> If you could suggest any improvements to the proposal in the area of
>>> interoperability with p2.
>>>
>>> With that out of the way, I do think there is room for another
>>> provisioning solution out there. Granted, it might be that it just
>>> doesn't have any added value over p2 and that people are going to
>>> ignore it but I'd say this risk exists for all projects, no?
>>>
>>> During the incubation, we will see whether the project is able to
>>> attract enough users and contributors. The initial interest looks  
>>> very
>>> promising IMO.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>>>> 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.
>>>>>
>>>>> OBR is a repository for components, augmented with metadata that
>>>>> describes
>>>>> dependencies. As such it's not a provisioning system, so in my  
>>>>> opinion
>>>>> you
>>>>> should not compare it to p2.
>>>>>
>>>>>> 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.
>>>>>
>>>>> Nobody can look into the future, and since both p2 and Ace are  
>>>>> indeed
>>>>> software provisioning solutions, there will definitely be  
>>>>> overlap in
>>>>> features. There are also differences though. In the end, the  
>>>>> users will
>>>>> decide what they like best.
>>>>>
>>>>
>>>> There's no doubt they will.
>>>>
>>>>> 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
>>>> ----------------------------------------------------------
>>>>
>>>> You are never dedicated to something you have complete confidence  
>>>> in.
>>>> No one is fanatically shouting that the sun is going to rise  
>>>> tomorrow.
>>>> They know it is going to rise tomorrow. When people are fanatically
>>>> dedicated to political or religious faiths or any other kind of
>>>> dogmas or goals, it's always because these dogmas or
>>>> goals are in doubt.
>>>>
>>>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> ----------------------------------------------------------
>>
>> To do two things at once is to do neither.
>>
>>  -—Publilius Syrus, Roman slave, first century B.C.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> -- 
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

  -- Eric Hoffer, Reflections on the Human Condition


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

Re: [PROPOSAL] Apache Ace

[Karl Pauls <ka...@gmail.com>]

I'm not sure I understand what your problem with this proposal is
exactly but I sure would like to. Let me try to get some things clear
in order to be able to get to the bottom of this. Don't let any
previous comments side-track you and lets try to focus on the
proposal:

I don't see where the proposal is mentioning OBR in the first place.
Let alone where it would say anything about it being a standard or
anything. Its only listed as an external dependency.

There is no pointer to OBR (other then that it is a dependency) nor is
there a pointer to p2. That is not suspicious as the project is not
about any of the two other then it should be able to use obr and p2
repositories and infrastructure where it makes sense.

I completely agree that it would be great if there would be an active
and healthy collaboration between the projects but I'm not sure this
has to be in the proposal. It certainly doesn't say anything to the
opposite (unless I'm missing something?).

Finally, the proposal already does say: "When assembling software out
of reusable components, the task of deploying software onto an ever
increasing number of targets is not trivial to solve. This becomes
even harder when these targets require different components based on
who's using them." What else do you think is necessary to make it
clear that provisioning is a hard problem as you say?

>From this point, would you say that what you like to see is a
paragraph that mentions that the current luminis implementation uses
OBR and that the project will look into using p2 as well? I'm sure
that this can be arranged.

regards,

Karl

> I'm suggesting that  you two groups figure out how to work together on a
> very hard problem.
>
> I'm also saying that you are unlikely to out do the 5 man years in p2
> already.
>
> As I said in the previous email if you want to make a competing system
> that's fine. But don't couch the proposal as something that's new and hasn't
> been addressed elsewhere because it has.
>
> You might want to be more clear in the proposal about p2 being a competitor,
> also make it clear that OBR has gone back to specification, and what it is
> you're actually working from. So when a user or potential developer looks at
> this and says what specification are you working from they can see "there
> isn't one yet", and if they ask "what about p2?", then it's clear you
> decided not to collaborate with them. I think you can even point out that
> they didn't collaborate with you either. Give people all the information.
>
> When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same dose
> of sniping and grin fucking as other groups I've worked with which was
> disappointing but I guess I'm not surprised. There were attacks abound at
> EclipseCon. The way p2 came into existence probably could have been handled
> better, no doubt. But I don't find guys like Hal very compelling with his
> melodrama
> (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html).
>
> Make it clear to people looking at the proposal that provisioning is a hard
> problem. These arguments about the "Eclipse way" of p2 and non-focus on
> server side or other types of systems is nonsense. If you actually  have a
> pointer to p2 in your proposal -- which is conspicuously absent -- siting
> them as a direct competitor users will have a clear point of reference. If
> people had the background story they will probably go WTF just like I did.

> Both sides of the p2/OBR seem to be equally obstinate and non-collaborative.
> I used p2 because from a technical level as an end user because it worked.
> There are nightly builds, lots of documentation and at least 5 people
> working on it full-time at any given point in time. If you look at the p2
> code and the OBR spec they are 90% the same thing and any differences are
> easily compensated for with a little effort.
>
> Competition is fine, I would just be more open about that aspect of it in
> the proposal.
>
> On 5-Apr-09, at 8:47 AM, Karl Pauls wrote:
>
>> On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl <jv...@sonatype.com>
>> wrote:
>>>
>>> On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:
>>>
>>>> Hello Jason,
>>>>
>>>> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>>>>
>>>>>> 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 is very much focused on server side
>>>>> provisioning as am I.
>>>>
>>>> Let me rephrase that, it's geared more towards desktop and server
>>>> environments, as compared to smaller (embedded, mobile) environments.
>>>> That
>>>> was the point I was trying to make here.
>>>>
>>>>>> 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?
>>>>
>>>> We started working on this system when p2 did not even exist. I even
>>>> remember talking to Jeff in those days about our system, but they
>>>> decided to
>>>> make their own, so you could equally well make this argument the other
>>>> way
>>>> round.
>>>>
>>>
>>> I'll use the same story I used on Richard. I created a DI and runtime
>>> system
>>> 5 years ago. So what. Guice and Equinox have a massive user community,
>>> professional support is available for both and so I will cull the
>>> technologies I developed. I don't think it really matters so much who was
>>> first but who got to a production system first that is known and support
>>> by
>>> thousands of users.
>>
>> Are you suggesting that we shouldn't incubate projects that overlap
>> with an existing production system outside the ASF?
>>
>>>>> 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.
>>>>
>>>> In my opinion, p2 is fine if you are already doing everything "the
>>>> Eclipse
>>>> way" and are targetting desktops and servers. There are however other
>>>> types
>>>> of systems that need provisioning, and Apache Ace tries to cater for
>>>> those
>>>> too.
>>>>
>>>
>>> Again you haven't really even looked at p2. What is the "Eclipse way" ?
>>> You're going to make/keep another system entirely because it's the
>>> "Eclipse
>>> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so I'm not
>>> sure what the "Eclipse way" means. I'll repeat again that p2 is not
>>> targeting desktops whatever aspects may appear most visible right now. I
>>> really don't think there is a system that couldn't be provisioned even
>>> with
>>> p2 in its current state. I have personally not found one yet.
>>
>> I don't think anyone is attacking p2. If people like and use it:
>> great. I certainly think the proposed project should be able to
>> interoperate with p2 repositories seamlessly. It sure would be great
>> If you could suggest any improvements to the proposal in the area of
>> interoperability with p2.
>>
>> With that out of the way, I do think there is room for another
>> provisioning solution out there. Granted, it might be that it just
>> doesn't have any added value over p2 and that people are going to
>> ignore it but I'd say this risk exists for all projects, no?
>>
>> During the incubation, we will see whether the project is able to
>> attract enough users and contributors. The initial interest looks very
>> promising IMO.
>>
>> regards,
>>
>> Karl
>>
>>>>> 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.
>>>>
>>>> OBR is a repository for components, augmented with metadata that
>>>> describes
>>>> dependencies. As such it's not a provisioning system, so in my opinion
>>>> you
>>>> should not compare it to p2.
>>>>
>>>>> 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.
>>>>
>>>> Nobody can look into the future, and since both p2 and Ace are indeed
>>>> software provisioning solutions, there will definitely be overlap in
>>>> features. There are also differences though. In the end, the users will
>>>> decide what they like best.
>>>>
>>>
>>> There's no doubt they will.
>>>
>>>> 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
>>> ----------------------------------------------------------
>>>
>>> You are never dedicated to something you have complete confidence in.
>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>> They know it is going to rise tomorrow. When people are fanatically
>>> dedicated to political or religious faiths or any other kind of
>>> dogmas or goals, it's always because these dogmas or
>>> goals are in doubt.
>>>
>>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> 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
> ----------------------------------------------------------
>
> To do two things at once is to do neither.
>
>  -—Publilius Syrus, Roman slave, first century B.C.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Karl Pauls
karlpauls@gmail.com

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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

On 6-Apr-09, at 12:33 AM, Richard S. Hall wrote:

> Jason,
>
> Although, we keep trying to point out that OBR != p2, you seem to  
> keep missing that point.
>

The argument is not lost on me. That they are not that far apart  
insofar as providing a repository system with an API to retrieve and  
manipulate artifacts is the point you are missing. They are not that  
wildly different and one could either of the easily evolve into the  
other. That's why I keep pointing it out because when anyone said OBR  
at EclipseCon the word provisioning always followed in the next  
sentence. Followed by a comparison with p2. I think both technologies  
are relevant in any discussion about provisioning OSGi.

> OBR is a simple repository model and API for accessing it, that's  
> all it is...it is not a provisioning system. As such, OBR has been  
> "done" for a long time. All other functionality should be hopefully  
> be buildable as layers on top, such as what Luminis has done with  
> their provisioning work.
>
> You act like there is some "gotcha" that OBR is not an OSGi spec,  
> but OBR has always existed outside of the OSGi specs, so who cares?  
> The proposal literally only mentions the letters "OBR" once as a  
> dependency and nothing more. It is hardly the main selling point.
>
> No one was shouting about OBR or p2, that was only you.
>

In a year from now when anyone is talking about provisioning OSGi what  
do you think the main underlying technologies bases will be? They will  
be OBR and p2. Either one of them will be expanded and changed and  
they will be the basis of most if not all provisioning technologies. I  
think you know that as well as I do.

> Also, the notion that we should just lay down because we can't  
> compete with some big company and all these man years they have  
> invested is somewhat ridiculous. If we all bought into that, then  
> none of us would be here.
>

As I also stated there are lots of small companies involved as well.  
I'm just saying pick your battles. Do you think a business manager is  
going to say "Hmm, this system has 5 man years of work in it and is  
used by a lot of people ... Well let's not consider that because  
that's ridiculous." Anyone trying to use the technology will not use  
that argument as a reason not to use it. I'm just saying it's a  
possible reason for not wanting to develop something else. If this was  
a proprietary solution not accessible, and not extensible then an open  
solution would be great, but that's not the case with p2. I would  
argue it's more of a proprietary case for OBR given the constraints to  
participate in the forming and implementation of the specification.

> If you just wanted to point out that p2 should be mentioned as a  
> competing technology in the proposal, I think you could have  
> accomplished that in a more reasonable manner.
>

Maybe. I'm not a dancer.

> Lastly, it is somewhat difficult for me to take community building  
> lessons from someone who claims to have had an OSGi awakening and is  
> willing to cull all of their own personal projects as a result, yet  
> I can count on probably a couple fingers how many discussions you've  
> instigated (or even responded to) regarding OSGi, OBR, or any topic  
> in the Felix community in all the years it has existed.
>

Heh. I _never_ claimed to be a an example of a good community builder.  
I wouldn't take any community building lessons from me. I write stuff,  
if you want to use it great. If you don't it's no skin off my back.  
That's the extent of my community building skill.

On the OSGi front I probably wouldn't be involved in many discussion  
on the Felix list because I use Equinox. So I don't think that's  
overly odd.

> -> richard
>
> On 4/5/09 2:11 PM, Jason van Zyl wrote:
>> I'm suggesting that  you two groups figure out how to work together  
>> on a very hard problem.
>>
>> I'm also saying that you are unlikely to out do the 5 man years in  
>> p2 already.
>>
>> As I said in the previous email if you want to make a competing  
>> system that's fine. But don't couch the proposal as something  
>> that's new and hasn't been addressed elsewhere because it has.
>>
>> You might want to be more clear in the proposal about p2 being a  
>> competitor, also make it clear that OBR has gone back to  
>> specification, and what it is you're actually working from. So when  
>> a user or potential developer looks at this and says what  
>> specification are you working from they can see "there isn't one  
>> yet", and if they ask "what about p2?", then it's clear you decided  
>> not to collaborate with them. I think you can even point out that  
>> they didn't collaborate with you either. Give people all the  
>> information.
>>
>> When I walked into the OSGi BOF at Eclipse I was dumbfounded. The  
>> same dose of sniping and grin fucking as other groups I've worked  
>> with which was disappointing but I guess I'm not surprised. There  
>> were attacks abound at EclipseCon. The way p2 came into existence  
>> probably could have been handled better, no doubt. But I don't find  
>> guys like Hal very compelling with his melodrama (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html 
>> ).
>>
>> Make it clear to people looking at the proposal that provisioning  
>> is a hard problem. These arguments about the "Eclipse way" of p2  
>> and non-focus on server side or other types of systems is nonsense.  
>> If you actually  have a pointer to p2 in your proposal -- which is  
>> conspicuously absent -- siting them as a direct competitor users  
>> will have a clear point of reference. If people had the background  
>> story they will probably go WTF just like I did.
>>
>> Both sides of the p2/OBR seem to be equally obstinate and non- 
>> collaborative. I used p2 because from a technical level as an end  
>> user because it worked. There are nightly builds, lots of  
>> documentation and at least 5 people working on it full-time at any  
>> given point in time. If you look at the p2 code and the OBR spec  
>> they are 90% the same thing and any differences are easily  
>> compensated for with a little effort.
>>
>> Competition is fine, I would just be more open about that aspect of  
>> it in the proposal.
>>
>> On 5-Apr-09, at 8:47 AM, Karl Pauls wrote:
>>
>>> On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl  
>>> <jv...@sonatype.com> wrote:
>>>>
>>>> On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:
>>>>
>>>>> Hello Jason,
>>>>>
>>>>> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>>>>>
>>>>>>> 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 is very much focused on server  
>>>>>> side
>>>>>> provisioning as am I.
>>>>>
>>>>> Let me rephrase that, it's geared more towards desktop and server
>>>>> environments, as compared to smaller (embedded, mobile)  
>>>>> environments. That
>>>>> was the point I was trying to make here.
>>>>>
>>>>>>> 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?
>>>>>
>>>>> We started working on this system when p2 did not even exist. I  
>>>>> even
>>>>> remember talking to Jeff in those days about our system, but  
>>>>> they decided to
>>>>> make their own, so you could equally well make this argument the  
>>>>> other way
>>>>> round.
>>>>>
>>>>
>>>> I'll use the same story I used on Richard. I created a DI and  
>>>> runtime system
>>>> 5 years ago. So what. Guice and Equinox have a massive user  
>>>> community,
>>>> professional support is available for both and so I will cull the
>>>> technologies I developed. I don't think it really matters so much  
>>>> who was
>>>> first but who got to a production system first that is known and  
>>>> support by
>>>> thousands of users.
>>>
>>> Are you suggesting that we shouldn't incubate projects that overlap
>>> with an existing production system outside the ASF?
>>>
>>>>>> 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.
>>>>>
>>>>> In my opinion, p2 is fine if you are already doing everything  
>>>>> "the Eclipse
>>>>> way" and are targetting desktops and servers. There are however  
>>>>> other types
>>>>> of systems that need provisioning, and Apache Ace tries to cater  
>>>>> for those
>>>>> too.
>>>>>
>>>>
>>>> Again you haven't really even looked at p2. What is the "Eclipse  
>>>> way" ?
>>>> You're going to make/keep another system entirely because it's  
>>>> the "Eclipse
>>>> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so  
>>>> I'm not
>>>> sure what the "Eclipse way" means. I'll repeat again that p2 is not
>>>> targeting desktops whatever aspects may appear most visible right  
>>>> now. I
>>>> really don't think there is a system that couldn't be provisioned  
>>>> even with
>>>> p2 in its current state. I have personally not found one yet.
>>>
>>> I don't think anyone is attacking p2. If people like and use it:
>>> great. I certainly think the proposed project should be able to
>>> interoperate with p2 repositories seamlessly. It sure would be great
>>> If you could suggest any improvements to the proposal in the area of
>>> interoperability with p2.
>>>
>>> With that out of the way, I do think there is room for another
>>> provisioning solution out there. Granted, it might be that it just
>>> doesn't have any added value over p2 and that people are going to
>>> ignore it but I'd say this risk exists for all projects, no?
>>>
>>> During the incubation, we will see whether the project is able to
>>> attract enough users and contributors. The initial interest looks  
>>> very
>>> promising IMO.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>>>> 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.
>>>>>
>>>>> OBR is a repository for components, augmented with metadata that  
>>>>> describes
>>>>> dependencies. As such it's not a provisioning system, so in my  
>>>>> opinion you
>>>>> should not compare it to p2.
>>>>>
>>>>>> 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.
>>>>>
>>>>> Nobody can look into the future, and since both p2 and Ace are  
>>>>> indeed
>>>>> software provisioning solutions, there will definitely be  
>>>>> overlap in
>>>>> features. There are also differences though. In the end, the  
>>>>> users will
>>>>> decide what they like best.
>>>>>
>>>>
>>>> There's no doubt they will.
>>>>
>>>>> 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
>>>> ----------------------------------------------------------
>>>>
>>>> You are never dedicated to something you have complete confidence  
>>>> in.
>>>> No one is fanatically shouting that the sun is going to rise  
>>>> tomorrow.
>>>> They know it is going to rise tomorrow. When people are fanatically
>>>> dedicated to political or religious faiths or any other kind of
>>>> dogmas or goals, it's always because these dogmas or
>>>> goals are in doubt.
>>>>
>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> ----------------------------------------------------------
>>
>> To do two things at once is to do neither.
>>
>> -—Publilius Syrus, Roman slave, first century B.C.
>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: [PROPOSAL] Apache Ace

["Richard S. Hall" <he...@ungoverned.org>]

Jason,

Although, we keep trying to point out that OBR != p2, you seem to keep 
missing that point.

OBR is a simple repository model and API for accessing it, that's all it 
is...it is not a provisioning system. As such, OBR has been "done" for a 
long time. All other functionality should be hopefully be buildable as 
layers on top, such as what Luminis has done with their provisioning work.

You act like there is some "gotcha" that OBR is not an OSGi spec, but 
OBR has always existed outside of the OSGi specs, so who cares? The 
proposal literally only mentions the letters "OBR" once as a dependency 
and nothing more. It is hardly the main selling point.

No one was shouting about OBR or p2, that was only you.

Also, the notion that we should just lay down because we can't compete 
with some big company and all these man years they have invested is 
somewhat ridiculous. If we all bought into that, then none of us would 
be here.

If you just wanted to point out that p2 should be mentioned as a 
competing technology in the proposal, I think you could have 
accomplished that in a more reasonable manner.

Lastly, it is somewhat difficult for me to take community building 
lessons from someone who claims to have had an OSGi awakening and is 
willing to cull all of their own personal projects as a result, yet I 
can count on probably a couple fingers how many discussions you've 
instigated (or even responded to) regarding OSGi, OBR, or any topic in 
the Felix community in all the years it has existed.

-> richard

On 4/5/09 2:11 PM, Jason van Zyl wrote:
> I'm suggesting that  you two groups figure out how to work together on 
> a very hard problem.
>
> I'm also saying that you are unlikely to out do the 5 man years in p2 
> already.
>
> As I said in the previous email if you want to make a competing system 
> that's fine. But don't couch the proposal as something that's new and 
> hasn't been addressed elsewhere because it has.
>
> You might want to be more clear in the proposal about p2 being a 
> competitor, also make it clear that OBR has gone back to 
> specification, and what it is you're actually working from. So when a 
> user or potential developer looks at this and says what specification 
> are you working from they can see "there isn't one yet", and if they 
> ask "what about p2?", then it's clear you decided not to collaborate 
> with them. I think you can even point out that they didn't collaborate 
> with you either. Give people all the information.
>
> When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same 
> dose of sniping and grin fucking as other groups I've worked with 
> which was disappointing but I guess I'm not surprised. There were 
> attacks abound at EclipseCon. The way p2 came into existence probably 
> could have been handled better, no doubt. But I don't find guys like 
> Hal very compelling with his melodrama 
> (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html). 
>
>
> Make it clear to people looking at the proposal that provisioning is a 
> hard problem. These arguments about the "Eclipse way" of p2 and 
> non-focus on server side or other types of systems is nonsense. If you 
> actually  have a pointer to p2 in your proposal -- which is 
> conspicuously absent -- siting them as a direct competitor users will 
> have a clear point of reference. If people had the background story 
> they will probably go WTF just like I did.
>
> Both sides of the p2/OBR seem to be equally obstinate and 
> non-collaborative. I used p2 because from a technical level as an end 
> user because it worked. There are nightly builds, lots of 
> documentation and at least 5 people working on it full-time at any 
> given point in time. If you look at the p2 code and the OBR spec they 
> are 90% the same thing and any differences are easily compensated for 
> with a little effort.
>
> Competition is fine, I would just be more open about that aspect of it 
> in the proposal.
>
> On 5-Apr-09, at 8:47 AM, Karl Pauls wrote:
>
>> On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl <jv...@sonatype.com> 
>> wrote:
>>>
>>> On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:
>>>
>>>> Hello Jason,
>>>>
>>>> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>>>>
>>>>>> 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 is very much focused on server side
>>>>> provisioning as am I.
>>>>
>>>> Let me rephrase that, it's geared more towards desktop and server
>>>> environments, as compared to smaller (embedded, mobile) 
>>>> environments. That
>>>> was the point I was trying to make here.
>>>>
>>>>>> 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?
>>>>
>>>> We started working on this system when p2 did not even exist. I even
>>>> remember talking to Jeff in those days about our system, but they 
>>>> decided to
>>>> make their own, so you could equally well make this argument the 
>>>> other way
>>>> round.
>>>>
>>>
>>> I'll use the same story I used on Richard. I created a DI and 
>>> runtime system
>>> 5 years ago. So what. Guice and Equinox have a massive user community,
>>> professional support is available for both and so I will cull the
>>> technologies I developed. I don't think it really matters so much 
>>> who was
>>> first but who got to a production system first that is known and 
>>> support by
>>> thousands of users.
>>
>> Are you suggesting that we shouldn't incubate projects that overlap
>> with an existing production system outside the ASF?
>>
>>>>> 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.
>>>>
>>>> In my opinion, p2 is fine if you are already doing everything "the 
>>>> Eclipse
>>>> way" and are targetting desktops and servers. There are however 
>>>> other types
>>>> of systems that need provisioning, and Apache Ace tries to cater 
>>>> for those
>>>> too.
>>>>
>>>
>>> Again you haven't really even looked at p2. What is the "Eclipse way" ?
>>> You're going to make/keep another system entirely because it's the 
>>> "Eclipse
>>> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so I'm 
>>> not
>>> sure what the "Eclipse way" means. I'll repeat again that p2 is not
>>> targeting desktops whatever aspects may appear most visible right 
>>> now. I
>>> really don't think there is a system that couldn't be provisioned 
>>> even with
>>> p2 in its current state. I have personally not found one yet.
>>
>> I don't think anyone is attacking p2. If people like and use it:
>> great. I certainly think the proposed project should be able to
>> interoperate with p2 repositories seamlessly. It sure would be great
>> If you could suggest any improvements to the proposal in the area of
>> interoperability with p2.
>>
>> With that out of the way, I do think there is room for another
>> provisioning solution out there. Granted, it might be that it just
>> doesn't have any added value over p2 and that people are going to
>> ignore it but I'd say this risk exists for all projects, no?
>>
>> During the incubation, we will see whether the project is able to
>> attract enough users and contributors. The initial interest looks very
>> promising IMO.
>>
>> regards,
>>
>> Karl
>>
>>>>> 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.
>>>>
>>>> OBR is a repository for components, augmented with metadata that 
>>>> describes
>>>> dependencies. As such it's not a provisioning system, so in my 
>>>> opinion you
>>>> should not compare it to p2.
>>>>
>>>>> 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.
>>>>
>>>> Nobody can look into the future, and since both p2 and Ace are indeed
>>>> software provisioning solutions, there will definitely be overlap in
>>>> features. There are also differences though. In the end, the users 
>>>> will
>>>> decide what they like best.
>>>>
>>>
>>> There's no doubt they will.
>>>
>>>> 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
>>> ----------------------------------------------------------
>>>
>>> You are never dedicated to something you have complete confidence in.
>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>> They know it is going to rise tomorrow. When people are fanatically
>>> dedicated to political or religious faiths or any other kind of
>>> dogmas or goals, it's always because these dogmas or
>>> goals are in doubt.
>>>
>>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>> -- 
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> 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
> ----------------------------------------------------------
>
> To do two things at once is to do neither.
>
>  -—Publilius Syrus, Roman slave, first century B.C.
>
>
> ---------------------------------------------------------------------
> 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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

I'm suggesting that  you two groups figure out how to work together on  
a very hard problem.

I'm also saying that you are unlikely to out do the 5 man years in p2  
already.

As I said in the previous email if you want to make a competing system  
that's fine. But don't couch the proposal as something that's new and  
hasn't been addressed elsewhere because it has.

You might want to be more clear in the proposal about p2 being a  
competitor, also make it clear that OBR has gone back to  
specification, and what it is you're actually working from. So when a  
user or potential developer looks at this and says what specification  
are you working from they can see "there isn't one yet", and if they  
ask "what about p2?", then it's clear you decided not to collaborate  
with them. I think you can even point out that they didn't collaborate  
with you either. Give people all the information.

When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same  
dose of sniping and grin fucking as other groups I've worked with  
which was disappointing but I guess I'm not surprised. There were  
attacks abound at EclipseCon. The way p2 came into existence probably  
could have been handled better, no doubt. But I don't find guys like  
Hal very compelling with his melodrama (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html 
).

Make it clear to people looking at the proposal that provisioning is a  
hard problem. These arguments about the "Eclipse way" of p2 and non- 
focus on server side or other types of systems is nonsense. If you  
actually  have a pointer to p2 in your proposal -- which is  
conspicuously absent -- siting them as a direct competitor users will  
have a clear point of reference. If people had the background story  
they will probably go WTF just like I did.

Both sides of the p2/OBR seem to be equally obstinate and non- 
collaborative. I used p2 because from a technical level as an end user  
because it worked. There are nightly builds, lots of documentation and  
at least 5 people working on it full-time at any given point in time.  
If you look at the p2 code and the OBR spec they are 90% the same  
thing and any differences are easily compensated for with a little  
effort.

Competition is fine, I would just be more open about that aspect of it  
in the proposal.

On 5-Apr-09, at 8:47 AM, Karl Pauls wrote:

> On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl <jv...@sonatype.com>  
> wrote:
>>
>> On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:
>>
>>> Hello Jason,
>>>
>>> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>>>
>>>>> 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 is very much focused on server  
>>>> side
>>>> provisioning as am I.
>>>
>>> Let me rephrase that, it's geared more towards desktop and server
>>> environments, as compared to smaller (embedded, mobile)  
>>> environments. That
>>> was the point I was trying to make here.
>>>
>>>>> 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?
>>>
>>> We started working on this system when p2 did not even exist. I even
>>> remember talking to Jeff in those days about our system, but they  
>>> decided to
>>> make their own, so you could equally well make this argument the  
>>> other way
>>> round.
>>>
>>
>> I'll use the same story I used on Richard. I created a DI and  
>> runtime system
>> 5 years ago. So what. Guice and Equinox have a massive user  
>> community,
>> professional support is available for both and so I will cull the
>> technologies I developed. I don't think it really matters so much  
>> who was
>> first but who got to a production system first that is known and  
>> support by
>> thousands of users.
>
> Are you suggesting that we shouldn't incubate projects that overlap
> with an existing production system outside the ASF?
>
>>>> 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.
>>>
>>> In my opinion, p2 is fine if you are already doing everything "the  
>>> Eclipse
>>> way" and are targetting desktops and servers. There are however  
>>> other types
>>> of systems that need provisioning, and Apache Ace tries to cater  
>>> for those
>>> too.
>>>
>>
>> Again you haven't really even looked at p2. What is the "Eclipse  
>> way" ?
>> You're going to make/keep another system entirely because it's the  
>> "Eclipse
>> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so  
>> I'm not
>> sure what the "Eclipse way" means. I'll repeat again that p2 is not
>> targeting desktops whatever aspects may appear most visible right  
>> now. I
>> really don't think there is a system that couldn't be provisioned  
>> even with
>> p2 in its current state. I have personally not found one yet.
>
> I don't think anyone is attacking p2. If people like and use it:
> great. I certainly think the proposed project should be able to
> interoperate with p2 repositories seamlessly. It sure would be great
> If you could suggest any improvements to the proposal in the area of
> interoperability with p2.
>
> With that out of the way, I do think there is room for another
> provisioning solution out there. Granted, it might be that it just
> doesn't have any added value over p2 and that people are going to
> ignore it but I'd say this risk exists for all projects, no?
>
> During the incubation, we will see whether the project is able to
> attract enough users and contributors. The initial interest looks very
> promising IMO.
>
> regards,
>
> Karl
>
>>>> 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.
>>>
>>> OBR is a repository for components, augmented with metadata that  
>>> describes
>>> dependencies. As such it's not a provisioning system, so in my  
>>> opinion you
>>> should not compare it to p2.
>>>
>>>> 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.
>>>
>>> Nobody can look into the future, and since both p2 and Ace are  
>>> indeed
>>> software provisioning solutions, there will definitely be overlap in
>>> features. There are also differences though. In the end, the users  
>>> will
>>> decide what they like best.
>>>
>>
>> There's no doubt they will.
>>
>>> 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
>> ----------------------------------------------------------
>>
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise  
>> tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>>
>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> -- 
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

To do two things at once is to do neither.

  -—Publilius Syrus, Roman slave, first century B.C.


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

Re: [PROPOSAL] Apache Ace

[Karl Pauls <ka...@gmail.com>]

On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:
>
>> Hello Jason,
>>
>> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>>
>>>> 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 is very much focused on server side
>>> provisioning as am I.
>>
>> Let me rephrase that, it's geared more towards desktop and server
>> environments, as compared to smaller (embedded, mobile) environments. That
>> was the point I was trying to make here.
>>
>>>> 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?
>>
>> We started working on this system when p2 did not even exist. I even
>> remember talking to Jeff in those days about our system, but they decided to
>> make their own, so you could equally well make this argument the other way
>> round.
>>
>
> I'll use the same story I used on Richard. I created a DI and runtime system
> 5 years ago. So what. Guice and Equinox have a massive user community,
> professional support is available for both and so I will cull the
> technologies I developed. I don't think it really matters so much who was
> first but who got to a production system first that is known and support by
> thousands of users.

Are you suggesting that we shouldn't incubate projects that overlap
with an existing production system outside the ASF?

>>> 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.
>>
>> In my opinion, p2 is fine if you are already doing everything "the Eclipse
>> way" and are targetting desktops and servers. There are however other types
>> of systems that need provisioning, and Apache Ace tries to cater for those
>> too.
>>
>
> Again you haven't really even looked at p2. What is the "Eclipse way" ?
> You're going to make/keep another system entirely because it's the "Eclipse
> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so I'm not
> sure what the "Eclipse way" means. I'll repeat again that p2 is not
> targeting desktops whatever aspects may appear most visible right now. I
> really don't think there is a system that couldn't be provisioned even with
> p2 in its current state. I have personally not found one yet.

I don't think anyone is attacking p2. If people like and use it:
great. I certainly think the proposed project should be able to
interoperate with p2 repositories seamlessly. It sure would be great
If you could suggest any improvements to the proposal in the area of
interoperability with p2.

With that out of the way, I do think there is room for another
provisioning solution out there. Granted, it might be that it just
doesn't have any added value over p2 and that people are going to
ignore it but I'd say this risk exists for all projects, no?

During the incubation, we will see whether the project is able to
attract enough users and contributors. The initial interest looks very
promising IMO.

regards,

Karl

>>> 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.
>>
>> OBR is a repository for components, augmented with metadata that describes
>> dependencies. As such it's not a provisioning system, so in my opinion you
>> should not compare it to p2.
>>
>>> 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.
>>
>> Nobody can look into the future, and since both p2 and Ace are indeed
>> software provisioning solutions, there will definitely be overlap in
>> features. There are also differences though. In the end, the users will
>> decide what they like best.
>>
>
> There's no doubt they will.
>
>> 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
> ----------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Karl Pauls
karlpauls@gmail.com

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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:

> Hello Jason,
>
> On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:
>
>>> 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 is very much focused on server  
>> side provisioning as am I.
>
> Let me rephrase that, it's geared more towards desktop and server  
> environments, as compared to smaller (embedded, mobile)  
> environments. That was the point I was trying to make here.
>
>>> 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?
>
> We started working on this system when p2 did not even exist. I even  
> remember talking to Jeff in those days about our system, but they  
> decided to make their own, so you could equally well make this  
> argument the other way round.
>

I'll use the same story I used on Richard. I created a DI and runtime  
system 5 years ago. So what. Guice and Equinox have a massive user  
community, professional support is available for both and so I will  
cull the technologies I developed. I don't think it really matters so  
much who was first but who got to a production system first that is  
known and support by thousands of users.

>> 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.
>
> In my opinion, p2 is fine if you are already doing everything "the  
> Eclipse way" and are targetting desktops and servers. There are  
> however other types of systems that need provisioning, and Apache  
> Ace tries to cater for those too.
>

Again you haven't really even looked at p2. What is the "Eclipse  
way" ? You're going to make/keep another system entirely because it's  
the "Eclipse way" ? I've seen JBoss and Tomcat servers provisioned  
with p2 so I'm not sure what the "Eclipse way" means. I'll repeat  
again that p2 is not targeting desktops whatever aspects may appear  
most visible right now. I really don't think there is a system that  
couldn't be provisioned even with p2 in its current state. I have  
personally not found one yet.

>> 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.
>
> OBR is a repository for components, augmented with metadata that  
> describes dependencies. As such it's not a provisioning system, so  
> in my opinion you should not compare it to p2.
>
>> 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.
>
> Nobody can look into the future, and since both p2 and Ace are  
> indeed software provisioning solutions, there will definitely be  
> overlap in features. There are also differences though. In the end,  
> the users will decide what they like best.
>

There's no doubt they will.

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

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance


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

Re: [PROPOSAL] Apache Ace

[Marcel Offermans <ma...@luminis.nl>]

Hello Jason,

On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:

>> 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 is very much focused on server side  
> provisioning as am I.

Let me rephrase that, it's geared more towards desktop and server  
environments, as compared to smaller (embedded, mobile) environments.  
That was the point I was trying to make here.

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

We started working on this system when p2 did not even exist. I even  
remember talking to Jeff in those days about our system, but they  
decided to make their own, so you could equally well make this  
argument the other way round.

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

In my opinion, p2 is fine if you are already doing everything "the  
Eclipse way" and are targetting desktops and servers. There are  
however other types of systems that need provisioning, and Apache Ace  
tries to cater for those too.

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

OBR is a repository for components, augmented with metadata that  
describes dependencies. As such it's not a provisioning system, so in  
my opinion you should not compare it to p2.

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

Nobody can look into the future, and since both p2 and Ace are indeed  
software provisioning solutions, there will definitely be overlap in  
features. There are also differences though. In the end, the users  
will decide what they like best.

Greetings, Marcel


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

Re: [PROPOSAL] Apache Ace

[Jason van Zyl <jv...@sonatype.com>]

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.

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

Re: [PROPOSAL] Apache Ace

[Marcel Offermans <ma...@luminis.nl>]

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 (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. :)

Greetings, Marcel


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

Re: [PROPOSAL] Apache Ace

[Martin Cooper <ma...@apache.org>]

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.

--
Martin Cooper



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

Re: [PROPOSAL] Apache Ace

[Niclas Hedhman <ni...@hedhman.org>]

On Fri, Apr 3, 2009 at 3:52 AM, Marcel Offermans
<ma...@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

+1

Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

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

Re: [PROPOSAL] Apache Ace

["Richard S. Hall" <he...@ungoverned.org>]

+1

-> richard

On 4/2/09 3: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: 
> http://wiki.apache.org/incubator/AceProposal
>
> I'm looking forward to all questions and feedback, positive or negative.
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> 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

Re: [PROPOSAL] Apache Ace

[Marcel Offermans <ma...@luminis.nl>]

Hello Bertrand,

On Apr 3, 2009, at 13:33 , Bertrand Delacretaz wrote:

>> ...The full proposal can be found on the wiki at:
>> http://wiki.apache.org/incubator/AceProposal...
>
> Thanks for the proposal, and +1 for incubation.

Thanks for your support!

> I would suggest having just a dev list at the beginning, and maybe add
> a user list only at the end of incubation. With a relatively small
> initial community, that helps in keeping things focused, IMHO.

That makes sense, so I modified the proposal to reflect that.

Greetings, Marcel


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

Re: [PROPOSAL] Apache Ace

[Bertrand Delacretaz <bd...@apache.org>]

Hi Marcel,

> ...The full proposal can be found on the wiki at:
> http://wiki.apache.org/incubator/AceProposal...

Thanks for the proposal, and +1 for incubation.

I would suggest having just a dev list at the beginning, and maybe add
a user list only at the end of incubation. With a relatively small
initial community, that helps in keeping things focused, IMHO.

-Bertrand

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