It all being said. I'm happy with whatever the general consensus is, I just want to be able to maintain versions better! On 6 Aug 2015 15:51, "Ramirez, Paul M (398M)" <paul.m.rami...@jpl.nasa.gov> wrote:
> I looked at the PR on my phone so maybe I was confused. Looking at it > again. > > --Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Paul Ramirez, M.S. > Technical Group Supervisor > Computer Science for Data Intensive Applications (398M) > Instrument Software and Science Data Systems Section (398) > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 158-264, Mailstop: 158-242 > Email: paul.m.rami...@jpl.nasa.gov<mailto:paul.m.rami...@jpl.nasa.gov> > Office: 818-354-1015 > Cell: 818-395-8194 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > On Aug 6, 2015, at 7:48 AM, Tom Barber <tom.bar...@meteorite.bi<mailto: > tom.bar...@meteorite.bi>> > wrote: > > Hi Paul > > I'm not at my desk so I can't check dependency:tree but I wouldn't expect a > different output. > > You also shouldn't loose track of module dependency requirements the > dependency is still listed in the child pom it's just missing it's version > attribute. Parameterization seems like a lot of overkill and maintenance > that would get ignored pretty quickly and gains you little. > > Tom > On 6 Aug 2015 14:42, "Ramirez, Paul M (398M)" <paul.m.rami...@jpl.nasa.gov > <mailto:paul.m.rami...@jpl.nasa.gov>> > wrote: > > 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<mailto: > 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 > > >
