Yes, it does make sense and should be a goal. I think they only got out of
sync due to separate teams managing dependencies. Now would be a good time
to re-sync them.

--Mark

On Wed, Sep 2, 2015 at 2:04 PM, Anthony Baker <[email protected]> wrote:

> Would it make sense to use a single version of Spring jars throughout the
> build?
>
> > On Sep 2, 2015, at 1:10 PM, Nitin Lamba <[email protected]> wrote:
> >
> >
> >
> >> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
> >>> Hi Nitin,
> >>>
> >>> Looks like good progress! I had a few comments/questions:
> >>>
> >>> 1. Is there are reason why you added the pulseCompile,
> pulseTestCompile configurations rather than just use the standard compile
> and testCompile ones?
> >>> 2. I think it would be better to just rename and categorize the the
> tests to follow the conventions, rather than add different test and
> integrationTest targets. Maybe we can add another JIRA for that?
> >
> > Thanks Dan,
> >
> > 1. compile and test targets inherit from parent gradle project and use
> newer versions of Spring framework jars. I tried hard but couldn't override
> those dependencies from within a sub-project. Besides creating new tasks,
> the other option is to remove those from parent and move them downstream to
> different sub-projects using it. Is there a different way?
> >
> > 2. The new targets are required anyway to add a couple of new system
> properties. Agree that the tests need to be cleaned-up to follow
> conventions so I'll update GEODE-304 with those comments
> >
> >
> >> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
> >>> gemfire-assembly/build.gradle, line 188
> >>> <
> https://reviews.apache.org/r/38060/diff/1/?file=1062329#file1062329line188
> >
> >>>
> >>>    I don't think this is necessary to include the pulse jars in the
> lib directory - at least when I tried dropping a just the pulse war into
> the tools/Pulse directory with the old gemfire pulse it worked fine. I'm
> not sure what the classpath implications of putting them one place vs. the
> other are though.
> >
> > Thanks. I've removed the lines from gemfire-assembly's build gradle file.
> >
> >
> > - Nitin
> >
> >
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/38060/#review97495
> > -----------------------------------------------------------
> >
> >
> > On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
> >>
> >> -----------------------------------------------------------
> >> This is an automatically generated e-mail. To reply, visit:
> >> https://reviews.apache.org/r/38060/
> >> -----------------------------------------------------------
> >>
> >> (Updated Sept. 2, 2015, 6:42 p.m.)
> >>
> >>
> >> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
> >>
> >>
> >> Repository: geode
> >>
> >>
> >> Description
> >> -------
> >>
> >> Create new gradle script for PULSE to build archives (jar, war files)
> using the dependencies from existing ant build.xml file.
> >>
> >> These chances will be tracked on GEODE-12 branch until all subtasks are
> completed.
> >>
> >>
> >> Diffs
> >> -----
> >>
> >>  build.gradle 3bad39c
> >>  gemfire-assembly/build.gradle 0e51563
> >>  gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b
> >>  pulse/build.gradle PRE-CREATION
> >>  settings.gradle 7f6ed61
> >>
> >> Diff: https://reviews.apache.org/r/38060/diff/
> >>
> >>
> >> Testing
> >> -------
> >>
> >> - pulse.war file gets generated correctly and placed in tools/Pulse
> folder
> >> - Starting locator starts pulse within the embedded jetty instance
> >> - Unit and integration tests are blocked. GEODE-304 is tracking the
> issue separately
> >>
> >>
> >> Thanks,
> >>
> >> Nitin Lamba
> >>
> >>
> >
>
>


-- 
Mark Bretl
Software Build Engineer
Pivotal
503-533-3869
www.pivotal.io

Reply via email to