Nice +1
On Thursday, August 6, 2015, Ramirez, Paul M (398M) <
paul.m.rami...@jpl.nasa.gov> wrote:
> I see what you're saying. Below is an example of what I'm saying. You have
> them as a dependency in the master pom now versus just a set of properties
> in the master pom. Both would accomplish the same thing. I agree "mvn
> dependency:tree" should not be affect on the child pom area but would list
> all those dependencies under the master too.
>
>
> master pom:
>
> <properties>
>
> <org.mockito.mockito-all.version>1.9.5</org.mockito.mockito-all.version>
> </properties>
>
>
>
> child pom:
>
> <dependency>
> <groupId>org.mockito</groupId>
> <artifactId>mockito-all</artifactId>
> <version>${org.mockito.mockito-all.version}</version>
> <scope>test</scope>
> </dependency>
>
> Personal preference is this but since you created the patch already for
> the other version I'm +1 on it unless the above convinces you it's better.
>
>
> --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 <javascript:;><mailto:
> paul.m.rami...@jpl.nasa.gov <javascript:;>>
> Office: 818-354-1015
> Cell: 818-395-8194
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> On Aug 6, 2015, at 7:48 AM, Tom Barber <tom.bar...@meteorite.bi
> <javascript:;><mailto:tom.bar...@meteorite.bi <javascript:;>>>
> 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
> <javascript:;><mailto:paul.m.rami...@jpl.nasa.gov <javascript:;>>>
> 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
> <javascript:;><mailto:tom.bar...@meteorite.bi <javascript:;>>> 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
>
>
>
