oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramirez, Paul M (398M)" <paul.m.rami...@jpl.nasa.gov>
Subject Re: Organising the Poms
Date Thu, 06 Aug 2015 13:41:54 GMT
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.barber@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

Mime
View raw message