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

Re: Re: Sys Admin - where do we put projects

Posted by Myles on Fri Mar 19 13:27:35 1999

In Reply to: Re: Sys Admin - where do we put projects posted by Willc (uploaded by Mylesc) on March 19, 1999 at 13:24:57:

Distribution: paneris@i-way.co.uk
All,

[snip]

>No, it should go along with the code. The quality docs, code
>documentation docs, code drafts, scribbled notes, code, templates,
>test data, even the live data should all be a seamless,
>cross-referring whole with the integrity of the references maintained
>by CVS checkpointing.

OK. I suppose that because we will be interacting with the project docs
via the web interface things will be OK so long as PanerisII knows
where to find it (or we can create links).


> > This just leaves the templates. At present we can only have one
> > template directory for each instance of webmacro.
>
>This is a technical problem and there is bound to be a solution,
>whether it involves symbolic links or hacking webmacro to behave
>differently or whatever. As far as I can see, if webmacro has a
>single template directory then it's entirely natural to call the
>templates "sugar/foo..." since otherwise you are collapsing namespaces
>and making a great big scrambled pudding of a directory.

Indeed. You've then got to careful about changing the source to read
in the correct templates if, for instance, you decide that the templates
for the db admin stuff should live in templates/admin rather than
templates/paneris :-) C'est la vie.

[what about templates]
> > We could have a whether it involves symlinks or
> > jserv zone for each webmacro application, but the JVM that webmacro
> > launches is relatively large (I'm not sure if it's large enough to
> > worry about).
>
>The executable and shared libraries will be shared between processes.
>In fact there is something to be said in favour of splitting
>essentially separate tasks between separate JVMs: garbage collection
>takes time essentially proportional to the size of your live data set.

OK. We can worry about that when we start getting perfomance troubles...

>Fine, if projects really do correspond to Unix users (as httpd is a
>Unix user). Otherwise something under /usr/local is a fair choice.

/usr/local it is, then, unless anyone has an idea why not...

>I would argue for
>/usr/local/packages/master/cvsroot/projects/bloggs-plc/sugar as the
>CVS repository,

At present the CVS root is /usr/cvsroot. Can we checkout projects/bloggs-plc?
I was under the impression that you (initially) had to check out
a top-level module (i.e. projects, nots projects/bloggs-plc). I'm
wrong, I assume.

BTW, how do you find out what modules you have in your CVS repository
using a cvs command (i.e. without cd'ing over to the repository
and looking at the directories!)?

Remember that I-way back the machine up, so we don't have to worry
so much about doing it manually...

>/usr/local/packages/inst/projects/bloggs-plc/sugar-1.06 as the
>installed, currently running version and
>/usr/local/packages/dist/projects/bloggs-plc/sugar-1.06 as the
>canonical distribution (only needed if there is compilation or
>equivalent to be done).

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)...

> > We can get access to generic handlers so long as the
> > classpath includes the central repostitory of generic
> > code.
>
>Yeah, or what I do is make symlinks out of /usr/local/lib/java. For
>some reason I don't like PATHs, CLASSPATHs, Perl INCs, C -Is ...
>symlinks let you have these relationships explicit in the filesystem,
>not hidden in some stupid .bash_profile.

There's not much option with WebMacro. To find it's config file
(WebMacro.properties) and its handlers, they must all be in the
CLASSPATH, as defined in jserv.properties. Similarly for shared
code (such as the org.paneris.util package).


> > If we need to, we can copy the code into each project (but then we
> > would have to worry about multiple versions - ugh).
>
>Yes but if you don't do that, then you have to be very disciplined
>about versioning on the libraries and effectively making a new release
>of *all* the libraries every time you make a snapshot of one of the
>projects they depend on. Otherwise things break annoyingly.

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 :-)


>That suggests the following directory structure:
>
>/usr/local everything installed specially on this machine
>/usr/local/packages the bodies of the installed software
>/usr/local/packages/dist ... their distributions, where necessary
>/usr/local/packages/inst ... their actual installations
>/usr/local/packages
>/usr/local/packages/master master copies of our software
>/usr/local/packages/master/cvsroot
> our CVS repository
>/usr/local/packages/master/cvsroot/
> our libraries (source + docs)
>/usr/local/packages/master/cvsroot/projects//
> our projects (source + docs)
>/usr/local/packages/inst/paneris//-#.##
> installed binaries etc. of a project

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 dir in there...?)


>/usr/local/bin links to the appropriate files in packages/inst
>/usr/local/lib ditto, where necessary
>/usr/local/include etc.
>/etc this machine's configuration
>/home stuff specific to particular users
>
>in particular:
>
>/home/httpd links into packages/inst, or
> working copies in developers
> directories

We don't need the links from httpd so much since we can alter classpath
and use virtual servers...

[method of working snipped]

To summarise then:

Projects (e.g. sugar)
---------------------

Create the first go and stick it in the CVS repository (where-ever that is -
it shouldn't matter) as projects/sugar

Then get (whatever release of it we want) and stick it in

/usr/local/packages/dist/projects/sugar-#.## or
/usr/local/packages/inst/projects/sugar-#.##

The .../dist/... version is only required if we need to do significant compiling
(and I suggest that with Java we don't bother - keep the .class files with the
.java and keep it all in the relevant ../inst/.. directory).

For ease, we should set up a link from /usr/local/sugar to ../inst/projects/sugar-#.##


Shared Libraries (e.g. Administration handlers)
-----------------------------------------------

Much the same as above, except we talk about ../paneris/administration
rather than ../projects/sugar.

Similarly for shared code (e.g. org.paneris.utils) where I suggest we use
../paneris/java (or ../paneris/perl)


Comments?

Myles



Follow Ups: