[crossfire] jcrossclient lives.

[Brendan Lally]

On 11/12/05, Yann Chachkoff <
     yann.chachkoff at myrealbox.com
     > wrote:
>
      You missed my point. I wasn't suggesting that the JCrossclient should have been
     >
     part of the CF client subtree (as the X11, GTK and GTK2 are), but
     siomply why the
>
     JCrossclient wasn't part of the main Crossfire tree, alongside the
     (C) client, the Java
>
     Editor, the server, or the map sets.
     >
     
     >
      Given that all other CF-related subprojects so far have all been integrated in a
     >
      unique CVS root tree, I didn't get (and still don't) why it was different for JCrossclient.
     >
      It would have allowed all CF developers to contribute to the Java client, instead of
     >
      having to register a second time.
     
Three reasons:

1) It traditionally hasn't been, and I don't expect or rely on anyone
else in the project to know enough about it to fix my bugs, at least
not yet. I am only awake part of the day, and on #crossfire somewhat
less, so at least in the medium term to be able to say to someone who
might ask questions about it, 'this is not an official part of the
crossfire project, ask cavehippo' is a useful thing.

2) Because I am not an admin of the crossfire project and therefore
couldn't do file releases. (and as I previously stated, I will want to
do them a lot over the next few months.

3) The way it is written, much of it is still fairly interconnected,
there isn't as clear a seperation between the internal structure of
the client and the interface, as there is with the main client.

This and the fact that the entire source tree is currently 3524 source
lines of code (compared with 5293 in the last relase 4 and a half
years ago), so it would be very difficult to have multiple people work
on subprojects of any size without treading on each other's toes.


This does not mean I do not welcome any assistance, I do, and gladly,
but for small patches the patch tracker is a better choice, and for
large patches you /will/ need to coordinate with me anyway, at least
until I stop having every class in a state of flux. (so far the only
classes I haven't altered are VertPanel and PopWin, and I intend to
deal with them shortly).

Of course if sourceforge used a better source code management system,
like subversion, this wouldn't be an issue.

crossfire is a mature project, with a reasonable degree of stability,
and jcrossclient isn't.

At the point where I could say with reasonable certainty that there
would be no need for releases more frequently than every server
release, and that jcrossclient could be an optional extra for a server
admin with a spare web server, then it could usefully be incorporated
into the overall crossfire project. Until then, I don't see that as
neccessary or beneficial.