On Mon, Jan 07, 2002 at 12:42:14PM -0800, Ian Clarke wrote: > On Mon, Jan 07, 2002 at 09:33:43PM +0100, Oskar Sandberg wrote: > > This is my alternative: Leave the code in the current module. As I said, > > changing the java package name would be nice, but it is far from worth > > the effort of moving all the code. The beautification that needs to be > > made is the removal of all non-java and non-fred stuff from that module. > > The currently layout is FUBARed. Firstly, having the Makefile and > scripts in a "scripts/" directory *within* the code tree is ugly as > hell, virtually every project in every language has seen the benefits of > placing things like scripts and READMEs in the top level directory, and > the code in sub-directories off that, it is simply neater. The emerging > standard practice with Java is increasingly to place the Java source > code in a src/ directory, and the class files into a separate build > directory. If you are so desperate to compile the code in your normal > way then simply make a symlink to the freenet directory in src/ from > your Java tree.
I agree that the script/ directory ought to be moved out - that is what I said. > > This also means we won't destroy the often very useful version history > > of the files. > > We won't destroy it anyway, it will still be in the old "Freenet" > module. You think leaving the Freenet code in two modules will be less confusing? > > If you want to do have a module be the preperation area for the > > distributions, then have that module contain the scripts and readmes and > > whatnot - it is completely possible with CVS to check out one module > > into a subdirectory of another, so you could easly have a src/ > > subdirectory of that module and checkout the Freenet module int it (thus > > having your directory structure look just the way you want it). > > And what is the advantage of that over simply having the directory in > CVS in the format in which it is distributed? Every other project I am > familiar with does it that way, and it works beautifully for them. This > would save us the confusion and inconvenience of having CVS-based > developers working with a different directory structure than developers > who might just be developing patches on the distributed code base. It's not a different directory structure, the only difference is that the java source module starts from the src/ directory of your wrapper module so people who don't want your wrapper can ignore it. > > I think that the only decent thing to do is have the binary > > distributions move the Freenet package into a system specific java tree > > - but since I am not planning to make the distributions, I will have > > accept that others choose the route of folly. Just leave the code alone. > > Firstly, the issue of where the .jar or class files are placed during > installation is orthogonal to the layout of the directory structure in > CVS. Secondly, no matter how much you try to pretend that there is a > standard place to put Java .class files on popular operating systems, it > won't become true. Didn't I just say you can make the distributions any way you want (to my liking or not - I'm just not going to stop whining about). I don't agree that the issues are orthogonal, but you can certainly do the installation either way without forcing the unnecessary directories on CVS users. > Your desire to put some kind of ideology (which I > don't necessarily agree with anyway) before ease of installation is a > very good reason why you should leave the installation work to people > who care about the ordinary user. a) If I didn't care about the ordinary user, then I wouldn't care about that issue half as much - I know how to unpack jar files and build my own trees. My concerns are just longer term then pointy-clickyness. b) Why in the world would copying the class files into c:/Program~1/java rather then c:\Program~1\Freenet\ make installation any more complicated? > > Ian. > > -- > Ian Clarke ian at freenetproject.org > Founder & Coordinator, The Freenet Project http://freenetproject.org/ > Chief Technology Officer, Uprizer Inc. http://www.uprizer.com/ -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
