[CF-Devel] CFEditor cleaning up
Michael Keuchen
Michael.Keuchen at hamburg.de
Sat Aug 3 10:36:17 CDT 2002
Andreas Vogl schrieb:
>
>
Michael Keuchen wrote:
>
>
> Modifications to the build scripts are no problem.
>
> There is only one unchangeable condition for this scripts to work:
>
> All source files must be in a root package or a subpackage of it.
>
> Source files out of packages (like the old CFJavaEditor class) are
>
> not recognized by the build file.
>
>
I propose the following directory structure (on CVS):
I disagree with you, will make an own thread out of this.
Here I will only comment the worst of your ideas.
>
Btw, the latest sixlegs png library works as you've used it.
>
------
>
CFJavaEditor/
>
CFJavaEditor.jar <- working archive
No! No one needs this and the files are doubled.
The program can run with unzipped files, and if you - I cannot
imagine why - would want to have the jar file, you can create it with
the build script (target "jar").
In my first mail, I wrote:
>>
- Support for two different distributions
>>
Either source files or the jar is included in a distribution
>>
package.
Wasn't this clear enough?
Two distributions:
A) The src-distribution (also called "developer release")
- contains the files from the cvs repository
- contains all source files
- does not contain CFJavaEditor.jar
B) The exe-distribution (also called "mapmaker release")
- is built from the src-distribution when stable
- does not contain source files
- contains the CFJavaEditor.jar
>
... <- configuration files like autojoin.txt
All around the world configuration files are in a directory
called "conf" or "config". In most Java projects, "conf" is used.
>
icons/
>
HelpFiles/
>
system/
>
make/
What the hell do you want to put in this directory?
>
... <- build scripts for various OS
Oh my god! Build scripts for various OS are always a complete mess
and nearly impossible to maintain. That's the reason I made an ant
buildfile. Ant - if you do not know that, you should visit the
homepage
http://jakarta.apache.org/ant
- is a program for building
projects that is pure java and supposed to work in the same
way on all OS.
To remove these files was the main point of my proposal - you couldn't
have missed it.
>
lib/
>
png.jar
>
src/
>
CFJavaEditor.java
Hä? You cited my paragraph about not having source files without
a package (that is called the "default package") and leave this
file where it was. Of course it belongs in the same package as the
other source files.
>
cfeditor/
>
... <- editor classes
>
------
>
>
Now, I believe there are two issues that we need to discuss:
>
First, the way jar/non-jar execution and resource files work together
>
(and somewhat related, the way releases should be made).
>
Second, the thing about package names.
>
>
1. About the resource files
>
>
Currently it works like this: First, the editor looks for the
>
resource (config) files at the default place (this is root).
>
If any resource file is not found, the editor trys to get it
>
as system resource from the jar. If that fails too, an
>
errormessage is written and the file is really missing.
Yep, I like your CFileReader. It's a good idea.
But it didn't work with my JVM.
I had to replace
ClassLoader.getSystemResource
with
this.getClassLoader().getResource
and then it was o.k.
This is strange, as ClassLoader.getSystemClassLoader
returns the same object as this.getClassLoader.
But the JDK documentation is not clear at this point,
and I have not looked into its source code.
I have changed the settings so the first place where the
configuration files are searched is the "conf" directory.
(See my comment above.)
"If the file is not found there, the editor trys to get it
as a resource from the classpath." Not only from the jar.
A classpath consists of directories and/or jar files, and
for the programmer it does not matter where a class or
resource comes from.
"This behaviour has the advantage that the editor can not
only be executed as jar package and directly from the java
classes, but that a user can overwrite the default settings
by having a modified file in the conf directory."
>
This behaviour has the advantage that the editor can both be
>
executed as jar package and directly from the java classes.
>
Besides, it is easy to use modified resource files, no matter
>
which way you run the editor.
>
>
Therefor I don't want to have changes that make it impossible
>
to run the editor from anything other than a jar package.
Do you really believe I have not tested running the editor from
the class files without a jar?
>
>
Note that your version of the editor contains such changes.
>
The method "getIcon()" in your CGUIUtils.java fetches icons
>
only from jar. If the application is not run from jar, it
>
crashes. This is something I don't want.
No, it does not. Please check this first before accusing me of
an error. Of course I have tested it. And you?
>
2. About package names
>
>
First of all, you cannot delete directorys in CVS. Thanks
Bob Tanner already corrected this.
>
to Bob Tanner there's already a load of unused empty directorys
>
on CVS. Moving between directorys in CVS is a royal pain -
Why is changing directories a "royal pain" to you?
What program/tool do you use for it?
>
so much for flexibility.
>
I don't want clicking through all those subdirs either.
>
>
Second, Crossfire on the whole is not a java project.
>
If you start using java conventions, you're in fact
>
alienating from the rest of the project.
"CFJavaEditor is a java project.
If you start making your own conventions, you're in fact
alienating from the rest of the world."
>
Third, what if the used domain-name stops to support Crossfire?
>
What if the main site switches? Then we have to
>
move all those directorys again. We're not a company
>
owning our domain after all.
That's a point for you. So long as there isn't a lasting
domain, package names are not final.
>
3. Releases
>
>
There can be two releases. The "developer release" which is
>
effectively a copy from CVS, and the "mapmaker release" which
>
could have the following structure:
>
>
------
>
CFJavaEditor/
>
CFJavaEditor.jar
>
icons/
>
HelpFiles/
>
system/
>
------
>
>
Later, the icons and system dir could also get stuffed into
>
the jar file. In the end only jar and HelpFiles will remain.
Why later? I already did this.
I also put the HelpFiles in the jar. While looking through them,
I recognized this was not a good idea, as they contain information
about starting the editor. Better to have them outside.
>
>
Some misc. answers following...
>
> [...] What of the files would be changed by
>
> users? Surely not the help files, the icons and the "system"
>
> PNG pictures, but what about these four:
>
> - autojoin.txt
>
> - spells.def
>
> - typenumbers.def
>
> - types.txt
>
> Are they meant to be changed by a user?
>
>
Yes - meant to be changed by users. Also updated more often.
>
They are very important files.
Not convinced.
Can you give me one clear example why a normal user would change any
of these four files?
>
>
> > > - Separating the PNG support from the CFEditor code.
>
>
>
> O.K., please check it.
>
> (BTW: That's the typical outcome of forking development.)
>
>
Checked your stuff and it works. I'm not sure what you mean
>
with your comment, but the fork was unavoidable.
>
And since the png code is marginally small, there was
>
absolutely no need to hurry with changing that.
>
In fact, it even made things easier as you could run the
>
whole editor with "javac" without much hassle.
>
>
> There's one more thing I have to tell you.
>
> My first intention for changing the editor was to have an
>
> editor for Tabacha. [...] I turned back the changes and
>
> made the version you see. Two changes, that make sense, remain:
>
> The image size is now a constant (in IGUIConstants:
>
> TILE_XLEN, TILE_YLEN) and some code in ArchObjectStack is
>
> moved to a separate private method "generateFaceName".
>
>
These two changes are fine.
>
>
Andreas
>
>
--
>
GMX - Die Kommunikationsplattform im Internet.
>
http://www.gmx.net
More information about the crossfire
mailing list