incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: [PROPOSAL] Apache Ace
Date Sun, 05 Apr 2009 22:56:55 GMT
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.


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

>> ).
>> 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 <>
>>> 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:
>>>>> For additional commands, e-mail:
>>>> Thanks,
>>>> Jason
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder,  Apache Maven
>>>> ----------------------------------------------------------
>>>> 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:
>>>> For additional commands, e-mail:
>>> --
>>> Karl Pauls
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> ----------------------------------------------------------
>> To do two things at once is to do neither.
>>  -—Publilius Syrus, Roman slave, first century B.C.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -- 
> Karl Pauls
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

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:
For additional commands, e-mail:

View raw message