[Insight-developers] Module dependcies help : How to move classes out of Review

Luis Ibanez luis.ibanez at kitware.com
Sat Jun 18 14:31:03 EDT 2011


Hi Michael,

To move classes from the Review directory into their final destination,
you (or any other developer) must first perform a review of the code
following this checklist:

http://www.itk.org/Wiki/ITK_Release_4/Modularization/Code_Reviews/Checklist

A patch should be prepared addressing any issues where the code fails
to pass the items of this checklist.

The patch should be submitted to Gerrit, and it should follow the
standard review procedure.

Please do so independently of any other patch.
That is, do no mix this "moving out of Review" patch
with things like adding new classes at the same time.

The destination directories have been identified here:

https://spreadsheets.google.com/a/kitware.com/spreadsheet/ccc?key=0ApfVzIsZe0VFdFUxdE95WE5kMVE4LTJ6b3ZYQnpRalE&hl=en_US#gid=0


    Thanks


         Luis


--------------------------------
On Tue, Jun 14, 2011 at 5:35 PM, M Stauffer (V) <mstauff at verizon.net> wrote:
>>From: Brad King [mailto:brad.king at kitware.com]
>>Sent: Tuesday, June 14, 2011 10:47 AM
>>To: M Stauffer (V)
>>Cc: 'ITK-dev-list-mstauff at ver'; Luis Ibanez
>>Subject: Re: [Insight-developers] Module dependcies help
>>
>>On 06/14/2011 10:31 AM, M Stauffer (V) wrote:
>>> Is the new paradigm to include new classes directly in the module to
>>> which they most directly belong, forgoing the Review module?
>>There are
>>> some classes in Review, e.g. CompositeTransform,  that
>>> ITK-RegistrationRefactoring depends on, so we'll have to
>>also move those
>>> to other modules?
>>
>>The Review module exists only to hold classes that came from the Review
>>directory prior to modularization.  These were left from the
>>old CVS-based
>>workflow where the Review directory was used to put things that had not
>>been reviewed for inclusion.  Now we use Git branches and Gerrit to do
>>reviews so everything can be committed directly to its final intended
>>location.
>>
>>If you have some classes that need to be moved out of Review into more
>>permanent modules, please list them.
>
> OK that makes sense. I can move some classes out of
> RegistrationRefactoring to avoid circular dependencies there.
>
> The following six classes need to be moved out of Review for our needs.
> I don't know the official procedure for moving classes out of Review and
> changing dependencies, but for now I've moved these out and added
> dependencies as described below to get things to build and test. How
> should I proceed in terms of eventually merging into itk?
>
> 1) itkDeformationFieldTransform* (base class for
> Core/Transform/itkBSplineDeformationFieldTransform). I moved it to
> Core/Transform.
>
> The following three are needed by DeformationFieldTransform and tests.
> It looks like they'll require some new dependcies from what I'm seeing
> while I experiment with moving them.
>
> 2) itkBSplineScatteredDataPointSetToImageFilter* - used in
> itkBSplineDeformationFieldTransform. I moved to Core/Common for now
> 3) itkCoxDeBoorBSplineKernelFunction* - used in
> itkBSplineScatteredDataPointSetToImageFilter and in
> itkBSplineControlPointImageFunction. I moved to Core/Common for now.
> 4) itkBSplineControlPointImageFunction* - used in
> itkBSplineScatteredDataPointSetToImageFilterTest. I moved to
> Numerics/Optimizers.
>
> I then added these dependecies:
>
> Added ITK-Common to ITK-Transform.
> Added test dependency ITK-Optimizers to ITK-Common.
> Added ITK-ImageFunction to ITK-Optimizers.
>
> I moved these two to RegistrationRefactoring for now since they're part
> of our new registration framework:
>
> 5)itkCompositeTransform*
> 6)itkObjectToObjectMetric*
>
> Cheers,
> Michael
>
>


More information about the Insight-developers mailing list