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