FW: [CF-Devel] CFEditor cleaning up

[Mark Wedel]

  I feel I should say something about this discussion.  However, I'm a java 
novice, so can't access many of the specific points, so will instead deal with 
some of the broader issues.

CVS: There is no convenient way to rename files (have to delete them re-add 
them).  While CFJavaEditor may be a bit long winded as the top level directory 
name, it may not be worth the effort or renaming it.  Also, while removing files 
from CVS does not really remove them from the repository, it is possible to do 
that later step to end possible pathname conflicts (I can drop a message to 
sourceforge support saying 'please rm this directory').

Code Control: This is a much thornier issue.  For a long time, people have been 
very possessive about what work they have done (what, you changed my map without 
asking me, etc). And I can't say that I'm immune to doing that either - I have 
certainly said that such a change is not appropriate for whatever reason.  I 
certainly don't think it is necessary to have to post a warning about every 
minor change that has been made.  Big changes, like this, should be discussed.

The problem here is that there seems to be somewhat a conflict on what the right 
approach (in terms of naming of class files) is.  My take on it (which is only 
from reading through the messages) is that several developers think the new 
naming scheme is proper, where as AV likes the current naming scheme.  I can 
certainly understand AV's position - just renaming a bunch of stuff for the 
purpose of renaming it can be a pain.

  One possiblity is to just make a CVS directory for this different layout, 
effectively forking it.  Developers will vote with their fingers on which one 
gets updated.  I don't really advocate this approach, but this tends to be what 
happens when the views can't be reconciled.  The worst case scenario however is 
that that both get updated, but with different stuff (so one has cool features 
the other doesn't, and vice versa) - this now means extra work for both sides to 
port back and forth.


Build scripts:  My personel thought is leave the old ones around - if people 
find them useful, more power to them.  Choices are generally a good thing.  It 
is reasonable enough to say something like 'ant is the only supported build 
tool, but these other files/directions may be useful'.  I don't see any 
compelling reason why we have to get rid of the old ones.

  I know for myself that I still use the linux makefile.  Why?  Because 
installing ant on my system required some dependency I could find and RPM for, 
and the make method was working just fine.    But I did have to make some 
changes to the makefile.

  IF there is compelling reason to get rid of them, I suppose it makes some 
sense.  But I don't really see 'going to ant' also equating to 'we need to get 
rid of all the old build tools'.


Random thought for the day:
A 'binary' (.jar) archive makes a lot of sense for those people that just want 
to create/edit maps.  But along with that, the editor should probably be 
modified to read the archetypes and crossfire.0 (image) file and not rely on the 
arch directory.  I have a feeling the former should be very easy (all the parse 
code should be the same, your just not looking for all the files), reading the 
image file may be a little more work.

  Including the archetypes and image file with a binary version probably makes 
sense, and also provides for a 'cleaner' system to work on instead of having the 
arch directory.  It should also mean that startup will be much faster, as now it 
doesn't have to search the directory tree and do a whole bunch of opens.