Stefan Bodewig wrote: > >> Doing an explicit build of XO (using Ant's <javac> task directly) >> might help work around these issues. > > This is one of two possible solutions: > > (1) build the stuff Maven depends upon without Maven > > (2) bootstrap Maven with some precompiled dependencies, build the > stuff Maven depends upon with the bootstrapped Maven version, rebuild > Maven with the latest dependencies. > > It may be easier to do (1) to start with, but I'd expect Maven to > gather more and more dependencies that use Maven to build, so getting > (2) right is the better option IMHO.
Option (1) above requires the cooperation of the developers of Maven (and possibly commons), but for as long as it is technically feasible, it is the superior option, IMHO. There have been times in the development of Ant that today's version of Ant could not be built with yesterday's version of Ant. For an example, if a new feature was added and made use of in Ant's own build.xml. This can be problematic at times as features introduced between releases are not viewed as subject to normal deprecation policies as they have not been made public. Furthermore, monitoring compliance is easily monitored using Gump - failures will result otherwise. There even is an analog of this situation within Ant - building of Ant should not require optional.jar. Typically developers of Ant include optional.jar so they won't normally be aware of situations where this rule is violated, but the way in which builds are arranged in Gump will verify this constraint on every complete run. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
