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