Posted by Mylesc on Fri Mar 19 14:48:44 1999
In Reply to: Re: Re: Re: Sys Admin - where do we put projects posted by william on March 19, 1999 at 14:26:33:
| Distribution: | paneris@i-way.co.uk |
|---|
> > Sounds sensible. With java the source and .class files can live
> > together quite nicely, so we might not need the dist directory
> > often (we wont necessary need to distribute the code)...>Actually I hate that. It just clogs things up. When I do
>mixed-language programming, I have a Java-style list or tree of
>packages, and put all the sources, of whatever language, together. I
>have a separate tree for computer-generated sources, if any, and a
>separate tree for each kind of object code: Java (and ML) bytecode,
>Linux-i586 objects, sunos5-sun4 objects ...I think that it's not too messy if we are only java on a project.
If the project gets more complicated we can organise our source
tress in a more complicated manner.>Apart from anything else it's nice to be able to do
>cvs add `find` without having to exclude non-sources
>in some ghastly config file.Remember, you don't need to bother recompiling java so you
can just copy the .class files over...
> > Agree. I'm quite on for that - sticking any common code into a project.
> > It helps in moving the code (e.g. installing it live). It's just
> > not very nice :-)>My feelings too.
>However here's a "right" way of doing it that *might* not be too
>painful: whenever we make a "release" of anything, we do a cvs tag of
>the entire repository to ensure recoverability. We get round the
>package-copying problem as follows: rather than doing
>CLASSPATH=../../administration or whatever, we do
>CLASSPATH=dependencies/administration, where dependencies is a
>directory containing symbolic links to the libraries we have used.
>Of course it's not automatic or foolproof ...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...> > OK. As I say, the cvsroot is different at the minute. I'm assuming that
> > no-one would have a problem making links, e.g. from /usr/local/sugar
> > to /usr/local/packages/inst/projects/sugar-#.## (I'm not really sure we
> > need the (customer) dir in there...?)>Nor am I, it was just a thought ...
Let's drop it then.
> > We don't need the links from httpd so much since we can alter classpath
> > and use virtual servers...>I don't like classpath or virtual servers, or any kind of environment
>variable or configuration file. I think everything should be in the
>file system. But that's an aesthetic thing.As I say, we can't do that for webmacro (have to use classpath) and
the virtual server would help us primarily to separate perl code (again,
I'm worrying about 'common' code which might not be totally commmon).
> > Similarly for shared code (e.g. org.paneris.utils) where I suggest we use
> > ../paneris/java (or ../paneris/perl)>Well I'd still rather group everything by functionality. I don't want
>to see files related to the same library/project, which are
>potentially in different languages, split in such a way that they don't
>have a common root.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).
>We should aim for a situation where "install X" is a matter
>of "cp -r X ..." plus running a script to make a few links.Yes.
>Perhaps we can adopt the Java naming convention for everything,
>and put the whole caboodle in>/usr/local/packages/inst/paneris/org/paneris/adminsystem
>---*.pm, *.class and *.html etc. etc. etc.
Mmmm... That's what I was thinking about with Java (my suggestion
boils down to sticking a 'java' dir between 'paneris' and 'org').>Certainly I feel very strongly that that's what we should do with the
>*sources*. (Hmmm, I suppose that means that for Java-friendliness we
>want to stick org/paneris on the front of everything ... but I'm on
>for that, why not?)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). I'm
less convinced about non-java...
Myles