I follow the digest, so by the time I read the list a thread has pretty
much reached conclusion. But I've never seen this discussed before and
it's something I've had questions about. As a general rule, I think
you should never check in libraries (i.e., jars) upon which a revision
controlled module is dependent. That is, I don't believe they should be
checked in with the source. The configuration management of dependent
libraries is tracked separately, matching source versions to library
versions. I don't know that Jakarta has any conventions for doing this.
Are there any in the works? I'm not familiar with Gump. Where can I find
it? Finally, what's the right way to deal with Ant?
1. should we assume someone has Ant installed already the way the use
of Makefiles assumes you've already got make
2. should we include the ant jar in CVS so that anoncvs users can build
immediately even if they don't have Ant installed
3. should we leave the ant jar out of CVS, assuming that someone doing
a checkout has it installed, but package it with releases so a user
doesn't have to download ant separately to build the source
I'm thinking 3 makes the most sense, but I'd like to know what the official
convention is before removing ant.jar from the jakarta-oro source tree.
Having that jar in there has always bothered me since it gets "stale."
>Checking in generated code (java, html, etc.) is still something I am
>working to eliminate.
That's another good general rule. Anything that's generated
should not be revision controlled as it is derived from existing
revision controlled units (e.g., you check in YACC grammars, not the
generated parser).
>P.S. I still maintain that CJAN is unworkable until there is some level of
>version-to-version compatibility observed by the various projects.
Ditto.
Your message said [moving from library-dev]. I don't see that mailing list
advertised on the web site. What's its purpose and does one subscribe via
the usual listname-subscribe mechanism?
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
