[moving from library-dev]
Peter Donald wrote:
>
> Danger Will Robinson ! Danger ! Prepare to don a asbestos suit ;)
>
> This is an arguement done to death ;) Personally I would prefer to suck
> down tagged binaries from a known place (ie CJAN) but until the
> infrastructure is in place binaries in CVS is an ease of use issue.
;-)
The following (cut and pasted from jakarta-avalon/build.xml) is a tolerable
compromise (though I probably would have placed build.classes first). It
provides a default set of jars, and an easy method to override the default.
What I most object to is not providing some mechanism to override the
default.
<path id="project.class.path">
<pathelement path="${java.class.path}" />
<fileset dir="${lib.dir}">
<include name="*.jar" />
</fileset>
<pathelement path="${build.classes}" />
</path>
Gump, and the corresponding changes I made to Ant to support it, have
largely addressed the versioning issues I had with checking in jars. I
would still discourage checking in jars that are not associated with a
tagged level of the cvs from which it was built (typically a release).
Checking in generated code (java, html, etc.) is still something I am
working to eliminate.
- Sam Ruby
P.S. I still maintain that CJAN is unworkable until there is some level of
version-to-version compatibility observed by the various projects.
Obtaining a jar from a project that only works with last Thursday's version
of jakarta-wizbang-widget only works if everybody else that uses that
widget standardizes on that same version.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
