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 > >> > >> > >> > >
