Michael Wechner wrote:
Jörn Nettingsmeier wrote:
Michael Wechner wrote:
Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
[...]
btw, why do we ship class files in svn?
because these classes are considered as tools. Do you want to ship
Lenya with the ant java sources and first build ant?!
ok, that's an argument, but it gets absurd pretty quick.
in the c world, it would in fact be totally inconceivable to have the
make and autotools binaries in a cvs. (although in tarballs it's
common to include auto*-generated scripts as a courtesy to users -
that's fine by me.)
i'm sure you have very good reasons for shipping ant,
the reason for shipping ant is to simplify the installement.
It would be very silly to make it complicated again, which
would mean
- Remove ant
- Remove jetty
- Remove the config classes
and as an alternative add a very complicated INSTALL.txt
Would you really want that?
no, and i have said so. you are ignoring the part of my message where i
acknowlege that there can be good reasons for shipping generated files
sometimes:
but that should be an exception and ease-of-use hack, not an argument
for binaries in a svn tree. i'm not even sure i like the abundance of
jar files, but i must confess having all those as svn externals would
become unwieldy. it's a trade-off.
in any case, building those ant tasks takes only a few seconds and
requires no configuration, i.e. it can't possibly go wrong.
and having as few generated files as possible in the repo is certainly
a good idea.
as said these files were once built on the fly, but then somebody moved
them
into the tools dir. You might want to check why these files were moved
in the first place ...
not if they are considered tools, whereas I agree that one should
separate the build process from the build process
of the tools. See for instance the tools/config.
Can we please put back these classes such that Lenya can be built
again with Java 1.4?
if i understand the issue correctly, the classes are there, but
whenever some committer with java 1.5 commits and forgets to exclude
them, they will be in a bytecode version that is not
backwards-compatible to 1.4.
Lenya is currently targeting Java 1.4 and NOT 1.5. At the same time 1.4
is compatible with 1.5, but not necessarily the other way around. So,
what's the problem?!
the problem is (as you have found out yourself) that the tree is easily
broken when committers use java 1.5.
while it makes sense to stay 1.4 compatible for the foreseeable future,
it's certainly not wise to make life unnecessarily hard for developers
who want to use 1.5 (because lenya needs testing on that platform).
thus, in this particular and well defined case, generated files do more
harm than good, hence, let's get rid of them.
in the general case, it is always wise to think twice before adding
generated files to a repository. as you have stated, sometimes, even
after thinking twice, one arrives at the decision to do it :-D
and that's fine. but it's not an all-or-nothing decision.
and that is definitely a strong argument towards getting rid of those
class files. all we need to do is add compile-build-tasks to the "all"
target. there doesn't even have to be an extra build step for trunk
users.
as said, then theses classes need to be moved from tools to the source.
This might make sense, but I don't see an urgent reason for this to happen
and I think we should put our resources into other things.
the tree is broken every other day because of this and needs manual
intervention that is currently undocumented except in one message by
renaud. that is enough of a problem to re-evaluate things.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
