Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <B9628E5E-0A87-418A-A4D3-E8C7B0318F0E@sonatype.com>
From: Jason van Zyl <jvanzyl@sonatype.com>
To: general@incubator.apache.org
In-Reply-To: <487a994c0904050847g126798deo7f08d15350f484b2@mail.gmail.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [PROPOSAL] Apache Ace
Date: Sun, 5 Apr 2009 11:11:39 -0700
References: <91363FE9-DA18-4FDB-B80F-1299A75DE2AF@luminis.nl>
 <16d6c6200904041139x29ea84a8i34f959c448acdaac@mail.gmail.com>
 <69BF31D9-5176-4480-AA5D-E30BCE75132E@luminis.nl>
 <80A4D320-A9CB-46A0-9341-E495CDF77DCE@sonatype.com>
 <4502AA68-D301-432E-8018-0F10CCC9465D@luminis.nl>
 <A4613A6A-0BA0-4B90-AF10-C428DCD3153A@sonatype.com>
 <487a994c0904050847g126798deo7f08d15350f484b2@mail.gmail.com>

I'm suggesting that  you two groups figure out how to work together on =20=

a very hard problem.

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

already.

As I said in the previous email if you want to make a competing system =20=

that's fine. But don't couch the proposal as something that's new and =20=

hasn't been addressed elsewhere because it has.

You might want to be more clear in the proposal about p2 being a =20
competitor, also make it clear that OBR has gone back to =20
specification, and what it is you're actually working from. So when a =20=

user or potential developer looks at this and says what specification =20=

are you working from they can see "there isn't one yet", and if they =20
ask "what about p2?", then it's clear you decided not to collaborate =20
with them. I think you can even point out that they didn't collaborate =20=

with you either. Give people all the information.

When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same =20=

dose of sniping and grin fucking as other groups I've worked with =20
which was disappointing but I guess I'm not surprised. There were =20
attacks abound at EclipseCon. The way p2 came into existence probably =20=

could have been handled better, no doubt. But I don't find guys like =20
Hal very compelling with his melodrama =
(http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bund=
le-repository.html=20
).

Make it clear to people looking at the proposal that provisioning is a =20=

hard problem. These arguments about the "Eclipse way" of p2 and non-=20
focus on server side or other types of systems is nonsense. If you =20
actually  have a pointer to p2 in your proposal -- which is =20
conspicuously absent -- siting them as a direct competitor users will =20=

have a clear point of reference. If people had the background story =20
they will probably go WTF just like I did.

Both sides of the p2/OBR seem to be equally obstinate and non-=20
collaborative. I used p2 because from a technical level as an end user =20=

because it worked. There are nightly builds, lots of documentation and =20=

at least 5 people working on it full-time at any given point in time. =20=

If you look at the p2 code and the OBR spec they are 90% the same =20
thing and any differences are easily compensated for with a little =20
effort.

Competition is fine, I would just be more open about that aspect of it =20=

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 <jvanzyl@sonatype.com> =20=

> 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 =20
>>>>> types
>>>>> of artifacts. If you look at the "agent" part, it is geared =20
>>>>> towards
>>>>> desktop environments
>>>>
>>>> Not true.
>>>
>>>> Jeff McAffer's demo at EclipseCon is a case in point. He =20
>>>> provisioned
>>>> an EC2 node using p2. [...] Jeff is very much focused on server =20
>>>> side
>>>> provisioning as am I.
>>>
>>> Let me rephrase that, it's geared more towards desktop and server
>>> environments, as compared to smaller (embedded, mobile) =20
>>> 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 =20=

>>> decided to
>>> make their own, so you could equally well make this argument the =20
>>> other way
>>> round.
>>>
>>
>> I'll use the same story I used on Richard. I created a DI and =20
>> runtime system
>> 5 years ago. So what. Guice and Equinox have a massive user =20
>> 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 =20
>> who was
>> first but who got to a production system first that is known and =20
>> 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 =20=

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

>>> Eclipse
>>> way" and are targetting desktops and servers. There are however =20
>>> other types
>>> of systems that need provisioning, and Apache Ace tries to cater =20
>>> for those
>>> too.
>>>
>>
>> Again you haven't really even looked at p2. What is the "Eclipse =20
>> way" ?
>> You're going to make/keep another system entirely because it's the =20=

>> "Eclipse
>> way" ? I've seen JBoss and Tomcat servers provisioned with p2 so =20
>> 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 =20
>> now. I
>> really don't think there is a system that couldn't be provisioned =20
>> 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 =20=

>>>> 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 =20
>>> describes
>>> dependencies. As such it's not a provisioning system, so in my =20
>>> opinion you
>>> should not compare it to p2.
>>>
>>>> There's nothing wrong with competition but I think anyone doing =20
>>>> 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 =20
>>>> OBR or
>>>> anything else including non-OSGi systems.
>>>
>>> Nobody can look into the future, and since both p2 and Ace are =20
>>> indeed
>>> software provisioning solutions, there will definitely be overlap in
>>> features. There are also differences though. In the end, the users =20=

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

  -=97Publilius 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