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

[Christian Andersson]

Please read this one through before answering :-) (i'm happy this kind of
discussion happens, since it allows me to learn)

> > So what you are saying is that  if we are several developers spread
across
> > several places (perheps even different countries) and in our project we
use
> > 3:rd party jar-files, is that we should have second system for
delivering
> > these jar-files to the developers and making sure that they are all
using
> > the same versions?
>
> "delivering" What can that possibly mean in this context?!?!?!  Surely
> each site can all keep their own copies of these files -- they don't
> change betweeen revisions, by definition!

Since cvs is a Version System, (sometimes only a single program, and
sometime it is set up as a client server system) it keeps track of different
version of files, and what do I have, I have different versions of files,
some older ones should be used with together with older versions of other
files. If we are packaging a bug-fix for our software for a specific user,
we would perheps need to use older versions of some files.
What these files contains really really should be no big difference, however
when it comes to cvs compared to other version systems, this does matter a
bit, since cvs stores not the complete file but the changes in a file (when
they are text files and not binary) so binary files are not cost-effective
to store in cvs, BUT they can be stored in cvs, if we are not supposed to do
so, then why let us?

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.

...
> and used in conjunction with your own software.  Since Jar files are
> used dynamically at run time you should use run-time configuration
> parameters to ensure the correct versions are found and used by a given
> version of your software.

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.

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.


> > And why should we have to use 2 different versioning systems for this, I
> > agree that using cvs for storing binary files are not "cost effective",
but
> > using 2 different versioning systems for this is I think even worse.
>
> Why would you try to use one tool which has a _very_ specific capability
> to do something that it is explicitly not designed to do?  Why would you
> insist on trying to hammer in machine screws with the handle of a
> soldering iron?

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)

Unfourtunally due to "design flaws"? in java, this particulary soldering
iron, have a handle that has a sharp edgeand fits to the screw, I do not
need to hammer at all, and this screw is a bitt different, so other
screwdrivers fit as good as this handle....

> > What wuld be nice to have is a developement project system that takes
care
> > of versioning and many more things, but unfourtunally I have not seen
any
> > that I like yeat, and that is not to costly. So for now cvs is a
> > sollution...
>
> Software development is done with a collection of tools that you need to
> learn to use and integrated to the best of their abilities and to suit
> _your_ needs.

I agree, but if we can manage with less tools, is not that better?
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)?

If I have to install/use more systems to be able to work, then it would take
more time and in effect cost more to develope programs, and I guess not even
you work for free all the time.
I admit that CVS is not 100% suited and there might be tools out there that
is, but I have not found it yet, to handle it all manually is possible, but
it takes up to much time for us developers, making hte programs more
expensive..  if cvs can lessen our time doing manually stuff, why not use
it..  and cvs can do this.
There are other version systems out there that can do this also, but many of
them are very expensive, and some cannot be used un such a variety of
different operating systems (I am using win2k, an other developer is using
linux)

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'm not telling that cvs should be used on the client that the finished
product is installed on, only in the developement... :-)

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)


> If you want an entirely integrated development environment then might I
> suggest you go find one.  They do exist, but so far as I know CVS is not
> even a component in any of them.  When I want such an environment I find
> the Squeak implementation of Smalltalk-80 to be very suitable for my
> needs.  I'm told some of the commercial Smalltalk implementations go
> even further down the road of full project managment and do even better
> with assisting in the whole process of software configuration management.

Well unfourtunally smalltalk is not an option for all to choose, and I'm
sure that smalltalk have other differences to java that makes it less
usuable.. ( have not used smalltalk myself, only read a little about it).
So for us (the company I'm working for now), Java is the system we will
use... We could ofcourse go to the .NET plattform, but do i really want
that?  Nope! :-) (if that happens, I think I'll be out there looking for a
new jobb)

/Christian Andersson