Re: Feasibility of using OODT file manager in Airavata

[DImuthu Upeksha]

Hi Chris,

Any update on this?

On Tue, Aug 4, 2015 at 12:05 AM, Chris Mattmann 
wrote:

> I’ll provide a detailed answer on this today. Sorry been on baby
> duties and enjoying every minute of it! :)
>
> —
> Chris Mattmann
> chris.mattm...@gmail.com
>
>
>
>
>
>
> -Original Message-
> From: "Pierce, Marlon" 
> Reply-To: 
> Date: Monday, August 3, 2015 at 8:14 AM
> To: "d...@airavata.apache.org" ,
> "dev@oodt.apache.org" 
> Subject: Re: Feasibility of using OODT file manager in Airavata
>
> >Hi Dimuthu-
> >
> >In regards to question #2, there should not be any licensing issues.
> >
> >Marlon
> >
> >
> >From: DImuthu Upeksha
> >mailto:dimuthu.upeks...@gmail.com>>
> >Reply-To: "d...@airavata.apache.org"
> >mailto:d...@airavata.apache.org>>
> >Date: Saturday, August 1, 2015 at 12:40 AM
> >To: "d...@airavata.apache.org"
> >mailto:d...@airavata.apache.org>>,
> >"dev@oodt.apache.org"
> >mailto:dev@oodt.apache.org>>
> >Subject: Feasibility of using OODT file manager in Airavata
> >
> >Hi all,
> >
> >I have been working on integrating a file staging server for Apache
> >Airavata as a part of my GSoC project. Main purpose of doing this is to
> >manage and store input/ output files for Airavata experiments.
> >
> >Main use case is as follows.
> >
> >1. Clients (users) can push input files and metadata to file server (OODT
> >file manager) and should receive the url/ identifier of uploaded file to
> >provide to Airavata
> >2. Users submit experiments to Airavata with the url of uploaded input
> >file
> >3. Airavata should be able to fetch the input file over SCP or some other
> >mechanism. If the file server exists in same machine where Airavata also
> >has been hosted, Airavata can directly fetch the file from the repository
> >folder.
> > 4. Once the experiment (job) is done, Airavata should be able to push
> >output files to file server and notify the client.
> >5. Client should be able to download the output file.
> >
> >In addition to that, enforcing security in uploading and downloading
> >files is required.
> >
> >I tried OODT file manager by following this [1] tutorial and managed to
> >push and download files using command line tools. Before going in to
> >integration, I need to know some details about the feasibility of using
> >OODT file manager for this scenario.
> >
> >1. Can OODT file manager simulate the role of file server that I have
> >mentioned earlier without using other modules of OODT project?
> >2. Is there any licensing issue if I use OODT file manager in Airavata?
> >3. What is the preferred way of using file manager client to talk to the
> >file manager programatically? Simply, is there a Java API for file
> >manager client rather than cli commands?
> >
> >[1]
> >https://cwiki.apache.org/confluence/display/OODT/OODT+Filemgr+User+Guide
> >
> >Thank You
> >Dimuthu
> >--
> >Regards
> >
> >W.Dimuthu Upeksha
> >Undergraduate
> >
> >Department of Computer Science And Engineering
> >
> >University of Moratuwa, Sri Lanka
>
>
>


-- 
Regards

W.Dimuthu Upeksha
Undergraduate
Department of Computer Science And Engineering

University of Moratuwa, Sri Lanka

Re: Organising the Poms

[Tom Barber]

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"  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"  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:  on behalf of Michael Starch <
>> starc...@umich.edu
>> > >
>> > Reply-To: "dev@oodt.apache.org" 
>> > Date: Thursday, August 6, 2015 at 8:28 AM
>> > To: "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:
>> > >>
>> > >> 
>> > >>
>> > >>
>> 1.9.5
>> > >> 
>> > >>
>> > >>
>> > >>
>> > >> child pom:
>> > >>
>> > >> 
>> > >>org.mockito
>> > >>mockito-all
>> > >>${org.mockito.mockito-all.version}
>> > >>test
>> > >>  
>> > >>
>> > >> 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 > > >> paul.m.rami...@jpl.nasa.gov >
>> > >> Office: 818-354-1015
>> > >> Cell: 818-395-8194
>> > >> 
>> > >>
>> > >> On Aug 6, 2015, at 7:48 AM, Tom Barber > > >> >
>> > >>  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)"
>> > >>> > >> >
>> > >> 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

Re: Organising the Poms

[Tom Barber]

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"  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:  on behalf of Michael Starch <
> starc...@umich.edu
> > >
> > Reply-To: "dev@oodt.apache.org" 
> > Date: Thursday, August 6, 2015 at 8:28 AM
> > To: "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:
> > >>
> > >> 
> > >>
> > >>
> 1.9.5
> > >> 
> > >>
> > >>
> > >>
> > >> child pom:
> > >>
> > >> 
> > >>org.mockito
> > >>mockito-all
> > >>${org.mockito.mockito-all.version}
> > >>test
> > >>  
> > >>
> > >> 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  > >> paul.m.rami...@jpl.nasa.gov >
> > >> Office: 818-354-1015
> > >> Cell: 818-395-8194
> > >> 
> > >>
> > >> On Aug 6, 2015, at 7:48 AM, Tom Barber  > >> >
> > >>  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)"
> > >> > >> >
> > >> 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

Re: Organising the Poms

[Michael Starch]

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:  on behalf of Michael Starch  >
> Reply-To: "dev@oodt.apache.org" 
> Date: Thursday, August 6, 2015 at 8:28 AM
> To: "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:
> >>
> >> 
> >>
> >> 1.9.5
> >> 
> >>
> >>
> >>
> >> child pom:
> >>
> >> 
> >>org.mockito
> >>mockito-all
> >>${org.mockito.mockito-all.version}
> >>test
> >>  
> >>
> >> 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  >> paul.m.rami...@jpl.nasa.gov >
> >> Office: 818-354-1015
> >> Cell: 818-395-8194
> >> 
> >>
> >> On Aug 6, 2015, at 7:48 AM, Tom Barber  >> >
> >>  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)"
> >> >> >
> >> 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  >> 

Re: Organising the Poms

[Mattmann, Chris A (3980)]

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:  on behalf of Michael Starch 
Reply-To: "dev@oodt.apache.org" 
Date: Thursday, August 6, 2015 at 8:28 AM
To: "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:
>>
>> 
>>
>> 1.9.5
>> 
>>
>>
>>
>> child pom:
>>
>> 
>>org.mockito
>>mockito-all
>>${org.mockito.mockito-all.version}
>>test
>>  
>>
>> 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 > paul.m.rami...@jpl.nasa.gov >
>> Office: 818-354-1015
>> Cell: 818-395-8194
>> 
>>
>> On Aug 6, 2015, at 7:48 AM, Tom Barber > >
>>  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)"
>>> >
>> 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 > > 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
>> c

Re: Organising the Poms

[Ramirez, Paul M (398M)]

Agreed you have patch for this already so +1

--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
Office: 818-354-1015
Cell: 818-395-8194


On Aug 6, 2015, at 7:56 AM, Tom Barber 
mailto:tom.bar...@meteorite.bi>>
 wrote:

It all being said. I'm happy with whatever the general consensus is, I just
want to be able to maintain versions better!
On 6 Aug 2015 15:51, "Ramirez, Paul M (398M)" 
mailto:paul.m.rami...@jpl.nasa.gov>>
wrote:

I looked at the PR on my phone so maybe I was confused. Looking at it
again.

--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
Office: 818-354-1015
Cell: 818-395-8194


On Aug 6, 2015, at 7:48 AM, Tom Barber 
mailto:tom.bar...@meteorite.bi>mailto:tom.bar...@meteorite.bi>>>
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)" 
mailto:paul.m.rami...@jpl.nasa.gov>
>
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 
mailto:tom.bar...@meteorite.bi>mailto:tom.bar...@meteorite.bi>>> 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

Re: Organising the Poms

[Michael Starch]

+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:
>
> 
>
> 1.9.5
> 
>
>
>
> child pom:
>
> 
>org.mockito
>mockito-all
>${org.mockito.mockito-all.version}
>test
>  
>
> 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  paul.m.rami...@jpl.nasa.gov >
> Office: 818-354-1015
> Cell: 818-395-8194
> 
>
> On Aug 6, 2015, at 7:48 AM, Tom Barber  >
>  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)"  >
> 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  > 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
>
>
>

Re: Organising the Poms

[BW]

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:
>
> 
>
> 1.9.5
> 
>
>
>
> child pom:
>
> 
>org.mockito
>mockito-all
>${org.mockito.mockito-all.version}
>test
>  
>
> 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  paul.m.rami...@jpl.nasa.gov >
> Office: 818-354-1015
> Cell: 818-395-8194
> 
>
> On Aug 6, 2015, at 7:48 AM, Tom Barber  >
>  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)"  >
> 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  > 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
>
>
>

Re: Organising the Poms

[Ramirez, Paul M (398M)]

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:


1.9.5




child pom:


   org.mockito
   mockito-all
   ${org.mockito.mockito-all.version}
   test
 

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
Office: 818-354-1015
Cell: 818-395-8194


On Aug 6, 2015, at 7:48 AM, Tom Barber 
mailto:tom.bar...@meteorite.bi>>
 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)" 
mailto:paul.m.rami...@jpl.nasa.gov>>
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 
mailto:tom.bar...@meteorite.bi>> 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

Re: Organising the Poms

[Tom Barber]

It all being said. I'm happy with whatever the general consensus is, I just
want to be able to maintain versions better!
On 6 Aug 2015 15:51, "Ramirez, Paul M (398M)" 
wrote:

> I looked at the PR on my phone so maybe I was confused. Looking at it
> again.
>
> --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
> Office: 818-354-1015
> Cell: 818-395-8194
> 
>
> On Aug 6, 2015, at 7:48 AM, Tom Barber  tom.bar...@meteorite.bi>>
>  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)"  >
> 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>> 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
>
>
>

Re: Organising the Poms

[Ramirez, Paul M (398M)]

I looked at the PR on my phone so maybe I was confused. Looking at it again.

--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
Office: 818-354-1015
Cell: 818-395-8194


On Aug 6, 2015, at 7:48 AM, Tom Barber 
mailto:tom.bar...@meteorite.bi>>
 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)" 
mailto:paul.m.rami...@jpl.nasa.gov>>
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 
mailto:tom.bar...@meteorite.bi>> 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

Re: Organising the Poms

[Tom Barber]

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

Re: Organising the Poms

[Ramirez, Paul M (398M)]

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

RE: Organising the Poms

[Mallder, Valerie]

+1



Sent from my iPhone.

From: Tom Barber 
Sent: Thursday, August 6, 2015 4:17:17 AM
To: dev@oodt.apache.org
Subject: Organising the Poms

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

Organising the Poms

[Tom Barber]

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