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
<jvan...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
Karl Pauls
karlpa...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
