You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Branko Čibej <br...@xbc.nu> on 2009/11/11 13:03:47 UTC

OT: Subverting Eclipse (subject line changed to protect the guilty)

Igor Burilo wrote:
> Mark Phippard-3 wrote:
>   
>>> I gave counsel to the Eclipse Foundation and explained that they could
>>> provide a fully functioning JavaHL library to users with only EPL
>>> compatible code.  Basically, you just need to build without Neon, BDB
>>> and libintl support.  Of the three, the only thing an Eclipse client
>>> user needs is Neon, and Serf serves as a viable replacement.  I do not
>>> know why they never chose to release a binary built this way.  I can
>>> only assume that Igor and Polarion did not want to make these
>>> binaries.
>>>       
>
> Mark, it’s not a problem to build JavaHL. But as you said, to make it EPL
> compatible Eclipse should replace Neon by Serf or remove DAV libraries
> completely. It’s not a solution. In the first case proper functionality
> isn’t guaranteed (you and Michael Pilato are sceptic regarding Serf). Nobody
> would like to use SVN client, which is “different” and migh have problems.
>   

Sorry, but I have to say it: FUD, FUD, FUD! The *only* difference
between Serf and Neon that I'm aware of, in terms of functionality of
course, is that Neon (used to) have support for some authorization
models that Serf (used not to) have.

What you are saying is that Eclipse would only accept a Subversion
client with Neon in it ("proper functionality" FUD), but can't because
it has Neon in it so the license is wrong. That's just nitpicking for
the fun of it, and it assumes that Eclipse is itself the epitome of
perfection and should not be sullied by imperfect code. Bit of a paradox
there.

Which causes me to wonder how come you happen to trust Polarions
Java-only reimplementation of Subversion protocols -- that were never
seen, let alone certified as correct, by the Subversion community -- to
guarantee "proper functionality".

-- Brane


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