Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oodt.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAFC9u91+BSW7gA0G27PizxtjZhj4hfAS-KM8D3b8S+OwMZaDcg@mail.gmail.com>
References: 
 <CABML50cKdFZG4JpAER_cY9CzSGEMnPkA2wraJ80WKL2QwrHepQ@mail.gmail.com>
	<D959202E-7E8C-4CB9-8C6A-4328AB2E098D@jpl.nasa.gov>
	<CABML50etd91cFDtv6WxE1L_PrG_q6jEWK5dT+KWSastcOCEqxg@mail.gmail.com>
	<725117AB-230B-41E3-BC85-41E527A81132@jpl.nasa.gov>
	<CAK9SBgY8yAWXxXHav1jJ5gzgz6rvHDPMn4MH1rzyJ+PDaABiyg@mail.gmail.com>
	<CAFC9u93gYexZSM6cO7WSyzofDjJR9MDp_7whQkJDez+MpAbD-A@mail.gmail.com>
	<D1E8D9CE.3643F%chris.a.mattmann@jpl.nasa.gov>
	<CAFC9u91+BSW7gA0G27PizxtjZhj4hfAS-KM8D3b8S+OwMZaDcg@mail.gmail.com>
Date: Thu, 6 Aug 2015 17:57:58 +0100
Message-ID: 
 <CABML50cbgjd=oTEQ9MqrR0GGB+UG2mcAgZLOF6oiSSevz1dtfQ@mail.gmail.com>
Subject: Re: Organising the Poms
From: Tom Barber <tom.barber@meteorite.bi>
To: dev@oodt.apache.org
Content-Type: multipart/alternative; boundary=001a1134946cdccad5051ca76b66

--001a1134946cdccad5051ca76b66
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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" <starchmd@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.mattmann@jpl.nasa.gov> wrote:
>
> > We can=E2=80=99t 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.mattmann@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: <mdstarch@gmail.com> on behalf of Michael Starch <
> starchmd@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.ramirez@jpl.nasa.gov> wrote:
> > >
> > >> I see what you're saying. Below is an example of what I'm saying. Yo=
u
> > >>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 "mv=
n
> > >> dependency:tree" should not be affect on the child pom area but woul=
d
> > >>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.ramirez@jpl.nasa.gov <javascript:;><mailto:
> > >> paul.m.ramirez@jpl.nasa.gov <javascript:;>>
> > >> Office: 818-354-1015
> > >> Cell: 818-395-8194
> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >>
> > >> On Aug 6, 2015, at 7:48 AM, Tom Barber <tom.barber@meteorite.bi
> > >> <javascript:;><mailto:tom.barber@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.ramirez@jpl.nasa.gov
> > >> <javascript:;><mailto:paul.m.ramirez@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 stan=
d
> > >>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 yo=
u
> > >>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.barber@meteorite.bi
> > >> <javascript:;><mailto:tom.barber@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 m=
y
> > >> opinion, just upgrade the main dependency so that all modules rely o=
n
> > >>the
> > >> same version which makes integration a whole lot easier.
> > >>
> > >> Let me know your thoughts.
> > >>
> > >> Thanks
> > >>
> > >> Tom
> > >>
> > >>
> > >>
> >
> >
>

--001a1134946cdccad5051ca76b66--