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<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
