Tom, An alternate approach would be to leave the dependencies as is but manage the versions as properties in the top level pom. With this patch we lose traceability of what dependencies are required where. This alternate approach would make overrides easier for people too as it would stand as a placeholder for folks to substitute out a property reference with a version.
With this we lose the utility of "mvn dependency:tree" I'd align the property name with the fully qualified artifact name that way there was a clear mapping. I think this would accomplish what you were looking to do. Thoughts? --Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Ramirez - Group Supervisor Computer Science for Data Intensive Applications Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109 Office: 818-354-1015 Cell: 818-395-8194 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sent from my iPhone > On Aug 6, 2015, at 5:18 AM, Tom Barber <tom.bar...@meteorite.bi> wrote: > > Hello folks, > > I sent a pull request last night but its also worth discussing on here. > > When me an StarchMD were having a chat in Austin, we wanted to sort out > some of the build process and locations. > > Personally one of my issues when using OODT is the sheer amount of > dependencies. Clearly most of these are required, but keeping track of the > versions across modules is a pain. The pull request you see here: > https://github.com/apache/oodt/pull/25 addresses that by moving the > versions from the sub modules up to OODT Core so when a version is changed > it is changed in all the submodules. This removes a lot of the duplication > and I believe it makes it easier to see which version is being used. > > If there is a requirement to override a specific version of a dependency in > a submodule this can still be done, but it would also be nicer, in my > opinion, just upgrade the main dependency so that all modules rely on the > same version which makes integration a whole lot easier. > > Let me know your thoughts. > > Thanks > > Tom
