I removed the 'dependency' from collections to collections-codegen. It should never have been there, I was flailing around trying to explain your mysterious problems. Now the codegen is in its own little bubble, and the two versions should not interact.
On Thu, Mar 18, 2010 at 7:13 AM, Sean Owen <sro...@gmail.com> wrote: > Yes that'd be nice I imagine, to force use of 2.4. > > Separately, I made changes to use long[1] and double[1] as a > simplistic version of MutableLong/MutableDouble. I don't entirely like > it but it works fine and doesn't have any library dependency. > > But, that really only dodges the problem that we have a lurking > version conflict here so I'd rather not 'fix' it this way. But at > least I can work again for now. > > On Wed, Mar 17, 2010 at 10:04 PM, Benson Margulies > <bimargul...@gmail.com> wrote: >> Some use of 'excludes' is called for here. I'll have a look. >> >> On Wed, Mar 17, 2010 at 11:00 AM, Sean Owen <sro...@gmail.com> wrote: >>> Two postscripts: >>> >>> Velocity 1.6.3 (latest) depends on 2.4, but isn't in Maven. >>> >>> The issue is using some methods on MutableLong/Double etc. in lang >>> that aren't in 2.1. But if we're using those classes merely as a way >>> to store a number as an object in a way that's efficient to change, >>> then I submit that a plain old long[1] or double[1] is simpler and >>> severs that dependency altogether. >>> >>> On Wed, Mar 17, 2010 at 2:52 PM, Sean Owen <sro...@gmail.com> wrote: >>>> I'm seeing a little problem in compiling now that only bites when >>>> working through my IDE, but I still think it deserves a resolution: >>>> >>>> core uses commons-lang 2.4. core also depends on >>>> collections-codegen-plugin, which depends on velocity 1.5, which >>>> depends on commons-lang 2.1. My IDE takes 2.1 somehow and fails though >>>> the main build doesn't seem to mind. >>>> >>>> Is there a way to tell Maven, somehow, to definitely use 2.4? because >>>> I believe velocity would work with that too. >>>> Alternatively it's just a little surgery to make us compatible back to >>>> 2.1, but, would rather not do so I guess in principle. >>>> >>> >> >
