[ Follow Ups ] [ Post Followup ] [ Discussions at the Paneris newbox node ]

stop this religious war; was Re: Re: Re: Re: Re: Sys Admin - where do we put projects

Posted by william on Fri Mar 19 16:17:28 1999

In Reply to: Re: Re: Re: Re: Sys Admin - where do we put projects posted by Mylesc on March 19, 1999 at 14:48:44:

Distribution: paneris@i-way.co.uk
multiboard@paneris.co.uk writes:
> Remember, you don't need to bother recompiling java so you
> can just copy the .class files over...

Sorry, I didn't make myself very clear ... the point is, in my
source tree (which is also the doc tree) I only want to see things I
have typed in myself. Everything else should go in a parallel tree
well out of the way so that I don't have to explicitly exclude all
that .class and .o garbage when I browse directory listings, make
backups, run wildcard cvs add commands, and so on. Java actually
makes that really easy with the -d option.

This is really an issue for one's own personal development area, of
course, but it becomes a bit of a public standard because you have to
have support for this separation in your Makefiles (if any).

> Like that. The main trouble is that we only get one chance to set
> the CLASSPATH for JServ, so if we have several copies of the same
> classes, I assume we'll only ever get the one that appears first
> when Java searches the classpath, unless we put them in different
> packages...

That's not very nice. There was talk when they did marshalling and
RMI of introducing class versioning into Java but it didn't seem to go
anywhere ...

I suppose the only thing we can do is be very strict about renaming
packages (changing a version number) whenever the interface changes.
Hopefully the number of "inadvertent" changes that break things badly
will be small enough that we can fix them by hand.

> As I say, we can't do that for webmacro (have to use classpath)

What happens if you have a once-set CLASSPATH (at boot time) of
/usr/local/share/java/*, with symlinks out of there to everything you
want to include?

> OK. How about ../paneris/common/java/.. Remember that the code I am talking
> about here is not part of any specific project or even library, (e.g. TimJ's
> own Vector class). Another option might be ../paneris/util/java
> (with org/paneris/util/Vector.class etc under it).

Fine, sounds good. `.utils' is traditional ...

> We should certainly do that for stuff in the org.paneris packages, but
> many webmacro handlers are not in a package (maybe they should be).

yep, definitely

> I'm less convinced about non-java...

Well I think it's nice to put sources in the same directory if they
belong in the same package. Because Java is so uncompromising about
the way it maps package structure onto directory structure, it sort of
forces you to do the same with your other languages if you want to
keep things together.

There are really two cases to think about here.

One is if you have mixed languages because you really do run them
all as part of the same system---for instance if you have C extensions
to Java, or some Perl which acts inextricably as CGI middleware to a
C++ backend, or whatever. Then you may well end up with several
languages in literally the same directory because the sources really
do belong together. If you have

xyzproj/stuff/{*.java,*.pm}

then you simply have a Java package org.paneris.xyzproj.stuff and a
Perl package org::paneris::xyzproj::stuff.

The other case is if you have different subpackages associated with
a project which are implemented in different languages. For instance,
one might have alternative Perl/CGI and Java/servlet interfaces to a
web site. Those might profitably go in different subdirectories of
that project---in

xyzproj/frontend/servlet/*.java

and

xyzproj/frontend/cgi/*.pm

This induces a Java package org.paneris.xyzproj.frontend.servlet and a
Perl package org::paneris::xyzproj::frontend::cgi. Because the two
frontends are different subpackages, you don't actually get Java and
Perl sharing a directory, but they do share a tree.

By the way there is also

xyzproj/frontend/servlet/frontPage.template

as well as

xyzproj/frontend/servlet/doc/requirements/index.html, etc.

and probably

xyzproj/frontend/servlet/doc/guide/index.html
xyzproj/frontend/servlet/doc/guide/examples/Example1.java

which induces the package

org.paneris.xyzproj.frontend.servlet.doc.guide.examples

In short I really do mean everything we type in, from Java to Perl to
HTML to GIFs to templates to documentation to documentation examples,
should be filed according to what project and submodule they belong
to.



Follow Ups: