But I'm only learning... (was Re: stop this religious war;)

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

But I'm only learning... (was Re: stop this religious war;)

Posted by Myles on Fri Mar 19 17:26:48 1999

In Reply to: stop this religious war; was Re: Re: Re: Re: Re: Sys Admin - where do we put projects posted by william on March 19, 1999 at 16:17:28:

Distribution:	paneris@i-way.co.uk

[should .class files live in the same directories as .java files?]
> 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).
Yep. Let's agree on a separation for shared libraries and code, and
then it's down to the project leader on a project by project basis.

[one classpath -> different packages for different versions of the same
library code]
> 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.
Yes.
> > 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?
Like that! Does help help with the webmacro problem, but I like it!
> > 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 ...
../paneris/util/java it is then.
> > 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
OK. All
[put everything in a module: ends with:]
> 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.
Whoo! Heavy, man.
OK, I'm going to re-arrange the sugar project on my machine to get
a proper feel for all this. I'll write it up and draft a "how to set
up a new project" doc we can talk about.
Myles

Follow Ups:

Done it! Myles Fri Apr 9 21:14:58 1999 (4)

Re: Done it! TimJ Tue Apr 13 11:48:38 1999 (1)

Re: Re: Done it! Myles Tue Apr 13 12:39:57 1999 (1)

slightly disturbing TimJ Tue Apr 13 9:20:03 1999 (1)

Re: slightly disturbing williamc Tue Apr 13 13:42:06 1999 (1)

Re: Re: slightly disturbing TimJ Tue Apr 13 13:56:02 1999 (1)

Re: Re: Re: slightly disturbing william Tue Apr 13 15:18:44 1999 (1)
Re: Done it! TimP Mon Apr 12 12:56:11 1999 (0)
Re: Done it! WilliamC Fri Apr 9 22:02:57 1999 (0)

Re: But I'm only learning... (was Re: stop this religious war;) JohnR Fri Mar 19 20:59:49 1999 (0)

Re: But I'm only learning... (was Re: stop this religious war;) william Fri Mar 19 20:47:55 1999 (1)

Re: Re: But I'm only learning... (was Re: stop this religious war;) TimJ Mon Mar 22 8:18:48 1999 (1)

Post a Followup

Name:

E-Mail:

Copy:

Circulation:

AlexH	Catalyst	Chameleon	ColinR
DanielH	JackM	JennyP	JohnR
KeithH	KiraB	KrugerD	MikeC
MylesC	NicR	PatickG	RachelG
TimJ	TimP	WilliamC	WilliamS
paneris

Subject:

>[should .class files live in the same directories as .java files?]

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

>Yep. Let's agree on a separation for shared libraries and code, and
>then it's down to the project leader on a project by project basis.

>
>[one classpath -> different packages for different versions of the same
>library code]

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

>Yes.

>> > 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?

>Like that! Does help help with the webmacro problem, but I like it!

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

>../paneris/util/java it is then.

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

>OK. All

>[put everything in a module: ends with:]

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

>Whoo! Heavy, man.

>OK, I'm going to re-arrange the sugar project on my machine to get
>a proper feel for all this. I'll write it up and draft a "how to set
>up a new project" doc we can talk about.

>Myles

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