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.mattm...@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: <mdsta...@gmail.com> on behalf of Michael Starch <starc...@umich.edu> Reply-To: "dev@oodt.apache.org" <dev@oodt.apache.org> Date: Thursday, August 6, 2015 at 8:28 AM To: "dev@oodt.apache.org" <dev@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.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 >> >> >>
