Thomas Hallgren <thomas@tada.se> wrote on 07/06/2006 03:45:47 AM:
> Mark Phippard wrote:
> > The initial very rough draft for the proposal has been committed to
the
> > repository. You can view it online at:
> >
> > http://subclipse.tigris.org/proposal/index.html
> >
> > If you would like to contribute some edits you can check this out into
> > Eclipse from this URL:
> >
> > http://subclipse.tigris.org/svn/subclipse/trunk/www/proposal
> >
> > It is in our repository as a Simple Eclipse Project, currently with
just
> > the single HTML file.
> >
> The proposal focus a lot on JavaHL versus JavaSVN. Too much if you ask
me.
> Both have their pros and cons.
I think it is important to be clear that we are based on JavaHL because
clearly a lot of people have a problem with that. I want to be up front
about our architecture and what we are proposing.
> As a provider of headless Eclipse plugins, I care a lot about being able
to
> create platform
> agnostic distributions (I expect that to be common for most Java shops
that
> doesn't use
> SWT). For us, using JavaHL is really problematic since it effectively
removes all
> distribution advantages of using Java.
There is no problem building JavaHL for all platforms, the issue is
figuring out how to distribute it as a fragment in a way that it will
work. If we can get some changes made to Eclipse to help, you'd just have
to install the right fragment for the OS and it should just work. This is
somewhat proven today using the Windows platform as the example.
> Doing commercial stuff, I'd avoid JavaSVN due to it's license. I might
even
> avoid it doing
> Open Source since I don't want to contaminate my distributions.
>
> Neither has an EPL license and hence, neither can be submitted to
Eclipse
> (not at present anyway).
I do not think there will be any difficulty at all in getting the
Subversion license accepted. We are not planning to relicense JavaHL as
EPL, we can't. JavaHL is Subversion, and Subversion has its own license.
The Subversion license is just the Apache License with CollabNet replacing
the ASF in the text. There is already a lot of Apache code in Eclipse.
> You already conclude that "One of the main problems with CVS that
Subversionsought to
> address was the lack of an official API". OK, so take the full
consequences of that
> statement. You now submit something to the most commonly used Java based
> IDE. What would be
> more natural then to propose an EPL licensed SVN Java API?
Speaking only for myself, all I can say is that I have no interest in this
and think it is a terrible idea. I doubt I would even participate in a
project that went in that direction. When Eclipse decided to re-engineer
CVS client they did so knowing that:
a) There were no alternatives anyway, as CVS does not have any official
API
b) CVS development had been dead for years. They did not have to worry
about major changes.
Even given those two things, they still have had some trouble being
compatible with multiple versions, mostly because of a).
Subversion does have an official API, it is fully supported, and
Subversion is very actively developed. If you started working on a client
now, by the time you were done Subversion would have had 2 or 3 more
releases with a ton of major new features. Alex has done a pretty good
job keeping up with JavaSVN but it is a lot of work. There are a lot of
features in 1.4 that he still has to add, and major changes such as merge
tracking are already happening in trunk for the next release. It never
ends.
Even if JavaSVN were licensed as EPL, I'd still want a JavaHL-centric
solution.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Jul 6 14:40:27 2006