Re: Organising the Poms

[Tom Barber <to...@meteorite.bi>]

Okay I do finally have a bit of spare time.

I need to find out what to test here. Starch I looked through all the
commits and found one of yours regarding the moving of a load of the
streaming deps to a new streaming component. Is that what I'm supposed to
be looking at?

Tom

On Thu, Aug 6, 2015 at 6:03 PM, Tom Barber <to...@meteorite.bi> wrote:

> The output in the poms (dependencies included) should be no different
> except oodt core excluded jars can still be excluded at child pom level
> On 6 Aug 2015 17:57, "Tom Barber" <to...@meteorite.bi> wrote:
>
>> Test away.  My understanding is a top level pom can contain everything in
>> maven central if you want. It would depend on how you do it I believe. No
>> one would include oodt core as a dependency would they?
>> On 6 Aug 2015 17:50, "Michael Starch" <st...@umich.edu> wrote:
>>
>>> Will just listing them as dependencies at that level cause a build error?
>>> Or does it need to be a dependency on code that is actually built?
>>>
>>> I aggree with Chris, we need to test this.
>>>
>>> -Michael
>>>
>>> On Thu, Aug 6, 2015 at 9:31 AM, Mattmann, Chris A (3980) <
>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>
>>> > We can’t bring the streaming deps back into the build, so this
>>> > must not do that.
>>> >
>>> > Can this be checked?
>>> >
>>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> > Chris Mattmann, Ph.D.
>>> > Chief Architect
>>> > Instrument Software and Science Data Systems Section (398)
>>> > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> > Office: 168-519, Mailstop: 168-527
>>> > Email: chris.a.mattmann@nasa.gov
>>> > WWW:  http://sunset.usc.edu/~mattmann/
>>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> > Adjunct Associate Professor, Computer Science Department
>>> > University of Southern California, Los Angeles, CA 90089 USA
>>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: <md...@gmail.com> on behalf of Michael Starch <
>>> starchmd@umich.edu
>>> > >
>>> > Reply-To: "dev@oodt.apache.org" <de...@oodt.apache.org>
>>> > Date: Thursday, August 6, 2015 at 8:28 AM
>>> > To: "dev@oodt.apache.org" <de...@oodt.apache.org>
>>> > Subject: Re: Organising the Poms
>>> >
>>> > >+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.ramirez@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.ramirez@jpl.nasa.gov <javascript:;><mailto:
>>> > >> paul.m.ramirez@jpl.nasa.gov <javascript:;>>
>>> > >> Office: 818-354-1015
>>> > >> Cell: 818-395-8194
>>> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> > >>
>>> > >> On Aug 6, 2015, at 7:48 AM, Tom Barber <tom.barber@meteorite.bi
>>> > >> <javascript:;><mailto:tom.barber@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.ramirez@jpl.nasa.gov
>>> > >> <javascript:;><mailto:paul.m.ramirez@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.barber@meteorite.bi
>>> > >> <javascript:;><mailto:tom.barber@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
>>> > >>
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>>