Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] (no subject)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: shivaken <shivaken AT jcom.home.ne.jp>
  • To: Damien Mascord <tusker AT tusker.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] (no subject)
  • Date: Mon, 23 Sep 2002 15:41:10 +0900

Hi.

On Monday 23 September 2002 14:51, Damien Mascord wrote:
> Hey guys,
>
> In my opinion CLASSPATH should never be set in a system wide environment.
>
> If you do this, then applications that use non-system classloaders (such as
> servlet engines), will have potentially different classes to load, and
> therefore problems arise.
>
> A CLASSPATH should always be set by the applications shell script, which
> should base it's CLASSPATH on the needed jars, etc, that are used by that
> application.
>
> Imagine a scenario where you have two different JDKs loaded in your system,
> and therefore you would have different tools.jar and rt.jar that would
> conflict.

Sorry, I haven't consider about that conflict, though I have experienced.
Your opinion is just.

> JAVA_BASE is not a standard environment variable, and JAVA_HOME should be
> used instead.
>
> Personally, I would boycott the use of a system wide CLASSPATH altogether,
> and have application specific CLASSPATH.
>
> This is very easy, as the scripts that start the application can point to
> the particular jars that it needs. This means that the dependencies are
> also easy, as the location of a particular spells jars are known.
>
> In my opinion, it is much better to have a
>
> /usr/java/lib/<$spell-$version>/*.jar or /opt/java....
>
> rather than
>
> /usr/java/lib/*.jar

Yea, my local policy is
"/usr/java/<$spell-$version>/lib/*.jar"
or "/usr/java/<$spell-$version>/*.jar"


> I would also re-iterate that it should not reside in /var, as it is a
> static installation, and not "variable".
>
> Because different versions of spells may contain the same named jar files,
> and therefore we would have a conflict of namespace.
>
> The reason I interject here is because I am a Softare Engineer working on
> many java projects, and would not like to see SourceMage being a
> distribution shunned because it had a weird non-java-esque configuration.
>
> Damien

I do not want SourceMage to be weird distribution, too.

How do you think casting any java packages?
I want ask you more questions about such policies.

Thanks allot.





Archive powered by MHonArc 2.6.24.

Top of Page