Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not

[Noel Yap]

--- Christian Andersson <address@hidden> wrote:
> Delivering, well I could use e-mail for sending out
> different versions of
> files to the developers,  we could also be using
> ftp, or any other such
> system,instead of using a system that already does
> this and are beeing used.

Since CVS isn't meant to be used to deliver, I
wouldn't use it to do so even if it can.  There are
other, much easier-to-use tools that accomplish this
(eg rcp and scp).

> That might be a possible sollution, but unlike
> libraries and dll files it is
> easy for several versions
> of a jar file to exist within one machine without
> them competing with each
> others, with for example microsoft (urgh) and dll
> files this is not so, if
> you try to access a dcom component in that system
> there is only one version
> of that component,you cannot (afaik) have 2 versions
> of the same dcom
> component registered.  Also there is one more
> difference, Dll components
> know there version, not all jar-files know theirs
> and there is not ONE
> system to ask for this information, like there is
> with dll files.

You can embed the version into the filename (eg
xerces-1.1.jar) then use symlinks for those who just
want to use the default version.

> If the jar-file if has a manifest file, you can
> specify the version number,
> however there might be no manifest file, and then we
> do not know th version
> of the jar file, and even worse is the fact that
> unless you write your own
> classloader, your java program has no say  in what
> jar-files should be used,
> I cannot in the java program  find out that there is
> 3 different versions of
> a jar (class) and use the one appropiate, it uses
> the principle first found
> first used, patching a program can then be done by
> just palsing a new
> jarfile first in the classpath that is used to start
> the program.)
> What I can do is making an external script that does
> this, however since
> java is designed to exist on several different
> operating systems we cannot
> relly on the script to solve this (try scripting in
> dos, it can be done but
> it is not easy, and there are limitations that you
> do not have in for
> example bash and other such shells)  and
> unfourtunally we as programmers do
> not have much say in what operating systems the
> users should use when
> running our system.

Have you tried using Cygwin?  (Caveat: One needs to
wrap java (and the other Java executables) under
Cygwin so that pathnames are translated into something
they understand).

> Not designed to? then my english must not be that
> good, here I thought  cvs
> stood for concurrent version system, a system that
> manages to keep track and
> controle different versions of files. and what was
> my problem? well i have
> different versions of files and I need to
> control/keep track of them.I need
> to control that the developers  are using the newest
> files to work with,
> although, this however is not something cvs can do
> for me, I have to do that
> manually by checking with the cvs that I have the
> latest versions of files
> that I need to work with. Although cvs is not
> primarly designed to store
> binary files, it can do that, but remember that cvs
> was not designed to be a
> client server system either, but that has now
> changed, it was also not
> really designed to have a gui-client, but it has
> that now also (and these
> two things is somthing I am very glad for)

CVS doesn't have a GUI.

CVS is meant to be a concurrent versioning system, but
the design prevents it from achieving this goal when
it comes to non-diff3-able files.  I see no reason why
this design cannot be changed in order to achieve its
intended purpose.

Also, if you minimize (more like eliminate) concurrent
dev on non-diff3-able files, there should be no
problems other than the growth of the archive files.

> I agree, but if we can manage with less tools, is
> not that better?

Not necessarily.  I don't know your background, but
the Unix mentality is to have a bunch of tools that do
one thing extremely well and are easily integrated
into one another.

My primary trivial example of this are "find",
"xargs", and "grep" being used in something like:

  "find . -name '*.java' | xargs grep 'class MyClass'"


where in Windows, you'd have one tool that can do
this.  However, the Windows tool wouldn't be able to
do:

  "find . -name '*.java' | xargs egrep 'class
+MyClass|class +TheirClass'

In Unix, one can even pipe the output of the above
into the input of another command.  Furthermore, if
you want the ease-of-use that you get with Windows,
you can create a wrapper script and even a GUI front
end to it.

> for instance lets say that you have an enviroment
> where you are working
> against several databases, then you might have
> several sql-editors (the
> mysql program for mysql, sql+ for oracle and a gui
> program for informix) and
> several ways to run sql-code (to test it manually
> for example) would it not
> be better and more efficient if you could have just
> one program for this
> (some sql-programs do just this)?

In this case, yes, since their purpose is the same (ie
interact with a database).  Of course, you'll probably
lose some proprietary capabilities if you go this
route.

> The only thing I miss in cvs, is an easier way to
> handle dependecies, but I
> do not think cvs was designed  for this at all. 
> ofcourse you could tag
> files so that you manually have controll of this,
> but here we might have to
> use a different tool, which I have not found yet.
> ofcourse we could use
> tagging, if my understanding of that is correct, but
> then i think it would
> be a more manual handling, if you can tell me that I
> am wrong, I would be
> pleased.

I haven't found anything that handles dependencies. 
The problem is that higher-level dependencies are
semantic in nature (eg what versions of CVS work with
what versions of RCS, what versions of xalan work with
what versions of xerces, what versions of Tomcat work
with what versions of Apache)  They typically have no
correspondence to code.

> I'm not telling that cvs should be used on the
> client that the finished
> product is installed on, only in the developement...
> :-)

That's good to know.  But then, why not use the same
deployment tool in both development and production?

> I am also not saying that the cvs sollution is the
> best sollution, but sofar
> I have not found a better one, that allows us to
> share7manage/control
> different versions of the same jar file with a
> minimum penelty cost (in time
> and money)

It sounds like at least some of your development
environment is shared.  Is this true?  Can this be
changed?

I've found that no tool makes it easy to share a
development environment.  Instead, team processes and
procedures must be created and followed in order to
coordinate everyone.  It's much easier to have
isolated development environments for each developer.

Noel

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/