The rationale for the change was to add an extension point to the build system to enable client modules, such as transports and authentication/authorisation add-ons. The easiest way of doing this was the property used which has happened to involve requiring a 3 year old version of Ant.
Should it be a policy to support things that are over 6 years old at this point? RHEL4? I've been seeing RHEL5 based builds getting broken with increasing regularity recently... Robbie On 18 August 2011 14:07, Gordon Sim <[email protected]> wrote: > On 08/17/2011 08:21 PM, Robbie Gemmell wrote: >> >> You say you cant update, but is that really the case? All that is >> required to update Ant would be to unpack the ~6+ MB binary (e.g. >> from http://www.apache.org/dist/ant/binaries/ ) and add the bin >> directory to your path, job done. > > In more controlled build environments this is not always so simple. > >> The alternative would be to rework the additions to support 1.6.5, >> but at over 6 years old I think its time we gave up on that and take >> advantage of the bug fixes and newer features in later releases >> (theres a few I've spotted in 1.8.X that I look forward to using at >> some point down the line, once its suitably aged). > > Looking at the change in question, > http://svn.apache.org/viewvc?view=revision&revision=1149163, would I be > right in saying the use of the newer attribute is to make the existence of > the client-plugins dir optional? > > A bit of context on the thinking there would be useful in considering what > the options would be for those stuck on earlier versions. > > --Gordon > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
