oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Barber <tom.bar...@meteorite.bi>
Subject Re: Organising the Poms
Date Thu, 06 Aug 2015 14:56:36 GMT
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.ramirez@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.ramirez@jpl.nasa.gov<mailto:paul.m.ramirez@jpl.nasa.gov>
> Office: 818-354-1015
> Cell: 818-395-8194
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> On Aug 6, 2015, at 7:48 AM, Tom Barber <tom.barber@meteorite.bi<mailto:
> tom.barber@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.ramirez@jpl.nasa.gov
> <mailto:paul.m.ramirez@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.barber@meteorite.bi<mailto:
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message