Public SourceMage Discussion List

[Sergey A Lipnevich <sergeyli AT pisem.net>]

Nothing is standing in your way to unset a system-wide CLASSPATH for a 
specific app. At the same time, tools like Ant, iSQL-Viewer, Java-based 
editors, etc would benefit from CLASSPATH being set.

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.
>
> 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
>
> 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
>
> At 02:16 PM 23/09/2002 +0900, shivaken wrote:
>
> > Hi.
> >
> > On Monday 23 September 2002 07:54, Nick Jennings wrote:
> >
> > > > > > 1. The directory to put  java's jar library
> > > > > >         $Java_base/lib/**.jar
> > > > > >         or
> > > > > >         $Java_base/$spell\'s_name/lib/**.jar
> > > > >
> > > > > /opt is a good place to put things with funky directories. Or 
> > perhaps
> > > > > something in /var?
> > > >
> > > > /var is good I think.
> > > > But, I have to research other distributions directory policies,
> > > > before deciding our ones.
> > >
> > > /var is definetely *not* what we should do. The rule has been thus 
> > far,
> > > for anything requiring it's out heirarchy (i.e. java/lib java/bin 
> > etc.)
> > > it all goes in /opt.  (i.e. /opt/java/lib etc.)
> >
> > OK. /opt is good.
> > But, we have more flexibility.
> > If we define balky directory policy, New user will confuse and shun.
> > Because, at rpm based distro, sun's j2sdk will be installed at 
> > /usr/java.
> > So, We should support environment variable $JAVA_BASE.
> > To determine Java packages prefix. like JAVA_BASE=/usr/java
> > And we can recommend /opt.
> >
> > > > /etc/bashrc is a way for only bash user. (My shell is zsh...)
> > > > I want support tcsh and zsh.
> > > > At my machine, I wrote classpath at /etc/classpath. and
> > > > I set ". /etc/classpath" at /etc/zshrc.
> > >
> > > So then, maybe the spell could create a file to be sourced, and echo
> > > this info after the spell is cast.
> > >
> > > The only problem I could see with this, is if you are casting allot of
> > > stuff, you might miss the message.
> >
> > Casting allot is includes many problem I think.
> > When casted allot. you are not notifed which spells are succeeded to 
> > install.
> >
> > > Maybe we should have a: 'gaze notes <spell>'  for this kinda stuff? 
> > to get
> > > instructions, or reminders that are displayed after a spell is cast.
> >
> > For correct configuration?
> > That sounds good.
> > Now, you should 'gaze website <spell>' to get information.
> > But spell writer must have many tips.
> >
> >
> >
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>
>
>
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss