Distributing Java Source

[Roedy Green]

1. is there any format considered more vanilla than ZIP for
distributing Java source?

2. If you distribute source via a Version control system, which is the
preferred one for Java multiplatform?

3. Is there a place where I can post my source in a vcs for free or
cheaply? SourceForge turned me down because of my "non-miltary use"
restriction. My ISP is always too busy to do the work to let me set
up my own server.

 

[Thomas Kellerer]

Roedy Green, 23.07.2008 14:21:

1. is there any format considered more vanilla than ZIP for
distributing Java source?

JAR file?

Although that is essentially the same as a ZIP file, it is "built into" Java.

So you can be sure that anyone who has the JDK installed (otherwise he/she wouldn't be interested in the sources, right?) can un-jar it, even if no "ZIP utilitiy" is installed on that system

Thomas

 

[Tom Anderson]

1. is there any format considered more vanilla than ZIP for distributing
Java source?

Not that i'm aware of. I might be tempted to use a JAR, so i could
indicate version numbers and other things in the manifest, but that's not
a huge advantage.

2. If you distribute source via a Version control system, which is the
preferred one for Java multiplatform?

For distribution, it's hard to beat CVS, since there are clients for every
platform under the sun, including plugins for IDEs, virtual filesystems,
etc, and it's very well-understood, and a well-established standard.
Subversion is a 'better CVS', but it doesn't yet have as wide support, i'd
say. The more radical changeset-oriented systems, like git, are only
really necessary if you're doing distributed, anarchic development, which
i think you aren't (since your development isn't distributed - i make no
comment as to its anarchicity!).

3. Is there a place where I can post my source in a vcs for free or
cheaply? SourceForge turned me down because of my "non-miltary use"
restriction. My ISP is always too busy to do the work to let me set up
my own server.

I can't think of any off the top of my head that will let you use an
arbitrary license, as you would need to impose your non-military
restriction. You could work your way through this list and see if any
will, though:

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

tom

 

[David Segall]

Is there a place where I can post my source in a vcs for free or
cheaply?

Try http://www.cheap-jsp-hosting.com/. Dave Miller
<[email protected]> seems keen to cooperate with
active Java programmers and, I believe, recently gave some space to
Andrew Thompson <http://pscode.org/>. My only contact with them was an
enquiry about an addition to their supplied JVM. The reply was prompt
and offered a risk free (for me) solution.

My ISP is always too busy to do the work to let me set
up my own server.

I don't understand this bit. Unless your ISP is the host what have
they got to do with setting up your own server? On the other hand, if
they are willing to provide a free host, then I would keep nagging.

 

[Roedy Green]

1. is there any format considered more vanilla than ZIP for
distributing Java source?

2. If you distribute source via a Version control system, which is the
preferred one for Java multiplatform?

3. Is there a place where I can post my source in a vcs for free or
cheaply? SourceForge turned me down because of my "non-miltary use"
restriction. My ISP is always too busy to do the work to let me set
up my own server.

I have summarised your collective wisdom at
http://mindprod.com/jgloss/distributingsource.html

 

[Dave Miller]

Another option is to pay for a VPS (Virtual Private Server). It's just
like having your own dedicated machine but cheaper (you get a choice of
OS, full root access, install whatever software you like and reboot
whenever you feel like it). I use SliceHost and I'm very happy with
their service. On a 256Mb slice I run Apache, Jetty and MySQL with no
problems. VPSLink is an alternative provider that has lower spec slices
available (from $7 a month), but I can't vouch for their service having
never used it myself.

SliceHost: https://manage.slicehost.com/customers/new?referrer=456685539
(this is a referral link)
VPSLink: http://vpslink.com/vps-hosting/

Dan.

VPS used to be a midpoint between a managed environment and a full
dedicated server. Rather than a full dedicated at $100, you could buy a
quarter of a dedicated VPS at $40. That was then.

Now, in order to compete on price, some VPS providers are cutting
servers into extremely small pieces. When Dan buys a 256MB virtual
server he is buying, in essence, a computer with 256MB of total RAM. In
that there is no GUI to suck up power, that can work (as Dan attests).
When other vendors try to cut that down further (a 64MB computer?)
they're either trying to kid the customers or they're kidding themselves.

It comes down to how much you want to be involved in customizing the
server and maintaining it. MB for MB managed hosting is cheaper than VPS
and removes the need to do maintenance, security updates, etc. VPS gives
you a totally customized experience as a practicing server admin.

 

[thufir]

1. is there any format considered more vanilla than ZIP for distributing
Java source?

2. If you distribute source via a Version control system, which is the
preferred one for Java multiplatform?

3. Is there a place where I can post my source in a vcs for free or
cheaply? SourceForge turned me down because of my "non-miltary use"
restriction. My ISP is always too busy to do the work to let me set up
my own server.

I like code.google.com, which is free, which uses subversion (similar to
cvs), but git seems popular (I don't know any git websites). Dunno about
the licensing, with google you have to select from a preset list. If the
license you want isn't there, then you can always request that from
google -- they seem pretty responsive and have a google group for
code.google.com stuff.

How much code do you have that it must be compressed? When you checkout
code from subversion there's no compression. If you're compressing, that
sounds like an opportunity for file corruption.



-Thufir

 

[thufir]

JAR file?

Although that is essentially the same as a ZIP file, it is "built into"
Java.

On that note, you can include the src directory when the jar is built, so
that, yes, the jar runs the app, but source can be extracted. ?


-Thufir

 

[Tom Anderson]

How much code do you have that it must be compressed?

I think the desire to use an archive file is more about having one single
file to distribute than about reducing size. Even then, reducing size is
useful - it might not make much difference to the downloader, but a 60%
reduction in file size also means a 60% reduction in Roedy's bandwidth
use, which could save him some dollars. And that's Canadian dollars, which
are really worth something!

When you checkout code from subversion there's no compression. If
you're compressing, that sounds like an opportunity for file corruption.

Oh really. And you've had that happen to you, have you?

A compressed file has better protection against external corruption than
an uncompressed one - there are fewer bits to be hit by cosmic rays or
other random processes, and all archive formats worth bothering with
include checksums, which will detect many kinds of corruption. An
increased chance of corruption could only come from a defective
implementation of the compressor or decompressor, and the simple fact is
that there aren't many such implementations in use in the wild.

tom

 

[Roedy Green]

I don't understand this bit. Unless your ISP is the host what have
they got to do with setting up your own server? On the other hand, if
they are willing to provide a free host, then I would keep nagging.

At this point I have only static html serving, offered free. For me
to have the ability to set up my own code he has to do various changes
to ensure I don't screw up other clients.

 

[Roedy Green]

I like code.google.com, which is free, which uses subversion

isn't that just for google widgets?

 

[Roedy Green]

How much code do you have that it must be compressed? When you checkout
code from subversion there's no compression. If you're compressing, that
sounds like an opportunity for file corruption.

My source code is perfectly ordinary and not that big, under 25 MB, no
compression. Then there are the docs, scripts, class files, jars etc.
Zipped it is about 65 MB.

The website is about 700 MB of HTML, images, zips etc. That is what I
was thinking about gzipping to improve response.

 

[Roedy Green]

I think the desire to use an archive file is more about having one single
file to distribute than about reducing size. Even then, reducing size is
useful - it might not make much difference to the downloader, but a 60%
reduction in file size also means a 60% reduction in Roedy's bandwidth
use, which could save him some dollars. And that's Canadian dollars, which
are really worth something!

The desire to serve via a VCS system is primarily to comply with a
request from JetBrains intellij IDEA, my IDE. They want me to do that
as a condition for getting a free copy of the IDE.

It it also might encourage interest in my code, making it more
"serious" and getting free publicity from the hosting VCS.

Anyone trying to stay on top of my many micro changes could do it more
efficiently than by downloading entire ZIPs each time. It also makes
it clearer to them just what I changed.

 

[Roedy Green]

Oh really. And you've had that happen to you, have you?

A compressed file has better protection against external corruption than
an uncompressed one - there are fewer bits to be hit by cosmic rays or
other random processes, and all archive formats worth bothering with
include checksums, which will detect many kinds of corruption. An
increased chance of corruption could only come from a defective
implementation of the compressor or decompressor, and the simple fact is
that there aren't many such implementations in use in the wild.

The other nice feature of compression is it comes with an extra layer
of checksum. If something does go wrong with the transmission
(usually the tail end chopped off) you will soon find out.

The protocols that version control systems use can be quite clever for
syncing two copies of a program to detect deltas, or to update a
version. They don't have to send the entire thing either way. It
would make sense for them to compress that delta protocol as well. I
don't know exactly what they do, however.

That fact that it is not common knowledge how the protocols work is a
good sign. People only tend to know about stuff that DOESN'T work
properly.

 

[Jason Cavett]

Not that i'm aware of. I might be tempted to use a JAR, so i could
indicate version numbers and other things in the manifest, but that's not
a huge advantage.


For distribution, it's hard to beat CVS, since there are clients for every
platform under the sun, including plugins for IDEs, virtual filesystems,
etc, and it's very well-understood, and a well-established standard.
Subversion is a 'better CVS', but it doesn't yet have as wide support, i'd
say. The more radical changeset-oriented systems, like git, are only
really necessary if you're doing distributed, anarchic development, which
i think you aren't (since your development isn't distributed - i make no
comment as to its anarchicity!).


I can't think of any off the top of my head that will let you use an
arbitrary license, as you would need to impose your non-military
restriction. You could work your way through this list and see if any
will, though:

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosti...

tom

Or Subversion (SVN). CVS-like, but a lot nicer/better features.

 

[Arne Vajhøj]

1. is there any format considered more vanilla than ZIP for
distributing Java source?

No.

foobar-n.m-bin.zip for just want to run it people
foobar-n.m-src.zip for build yourself people
source control for contributors

2. If you distribute source via a Version control system, which is the
preferred one for Java multiplatform?

CVS or SVN

There is a move from CVS to SVN, but I believe there are still a better
chance than people has CVS support already.

Arne

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew schreef:
| Jason Cavett wrote:
|> Or Subversion (SVN). CVS-like, but a lot nicer/better features.
|
| Not a lot nice, and not all the features are better, and does it really
| do everything that CVS does?

Not being an expert in the matter, I’d have to not agree with you. Svn
is *designed* to be a successor and enhancement to cvs. Atomic commits,
a lot of functions that to not need a server connection which do in cvs
etc. And you can be sure that it does most of what cvs does. Although
it is not a 1-1 replacement, the commands are different, of course.

And then, there is cvs2svn and svnview (makes repository available for
browsing).

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkiIXjgACgkQBGFP0CTku6PVlwCeJ86tTnbgATzY+mrb/lG67uTL
MQcAn3TzBv6f9tS1pPUQc8cg1tWdlToW
=LnvO
-----END PGP SIGNATURE-----

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew schreef:
| Daniel Dyer wrote:
|> That may have been the case a few years ago, but I don't think it is
|> now. I'd say that Subversion is at least as widely supported as CVS.
|
| Call me Luddite, but I don't get it. CVS works great, and I've taken
| the time to learn some of its cooler features, and I don't like all the
| "improvements" in Subversion. Some, sure, but not all, and not enough
| to justify the learning curve. So far.

Ok, this is getting OT, but could you elaborate on that? I use both,
svn for my own projects and cvs for other projects I contribute to, and
I have to say svn suits me better most of the time. Though I have to
admit that cvs is also still developing and getting better.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkiIXp8ACgkQBGFP0CTku6O60wCgpxT6I1T/fNd140yO5K3nO4tG
UaEAn0hYAqA5XSWQ7ux77PcO0co/BbPu
=PpdC
-----END PGP SIGNATURE-----

 

[Roedy Green]

Atomic commits are a big plus, IMO.

Subversion versions not only file contents and file existence, but
also directories, copies, and renames. This means you can delete and
restore directories. You don’t have to keep dead empty directories
around forever as in CVS. It also means that Subversion keeps track of
the history of the renaming of a file. In CVS renaming looks like the
deletion and creation of a new file with no record of the connection.

 

[Owen Jacobson]

Lew schreef:
| Daniel Dyer wrote:
|
|> That may have been the case a few years ago, but I don't think it is
|> now.  I'd say that Subversion is at least as widely supported as CVS..
|
| Call me Luddite, but I don't get it.  CVS works great, and I've taken
| the time to learn some of its cooler features, and I don't like all the
| "improvements" in Subversion.  Some, sure, but not all, and not enough
| to justify the learning curve.  So far.

Ok, this is getting OT, but could you elaborate on that?  I use both,
svn for my own projects and cvs for other projects I contribute to, and
I have to say svn suits me better most of the time.  Though I have to
admit that cvs is also still developing and getting better.

Of the (fairly wide) range of version control tools I've used, svn's
approach to branches and merging is the second most primitive - second
to CVS. That's improving; svn 1.5 adds a much-needed merge-tracking
feature, but ultimately branches need to be a fundamental concept for
a version control system, and for svn they're not; they're a second-
order consequence of another feature entirely, instead.

-o