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" <tom.bar...@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" <starc...@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.mattm...@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.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 >> > >> >> > >> >> > >> >> > >> > >> >
