+1
Paul R's recommendation is cleaner. This is more likely to be adopted and
used.
I do have one concern. We banished the streaming components to their own
submodule to keep its dependencies from mucking with the build. Will
pulling these back to top level reintroduce this issue?
Also, we should get in the habit of upgrading top level versions, as
overriding in a child leads to multiple versions of the jar in the
classpath in some situations. Thus random runtime exceptions can occur.
Michael
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
>
>
>
