[
https://issues.apache.org/jira/browse/MATH-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351895#comment-17351895
]
Gilles Sadowski commented on MATH-1587:
---------------------------------------
I can't make much sense out of PR #178.
* The refactoring _must_ be done on a per-module basis (with an associated
JIRA "task"), each within its own PR.
* Whatever code is moved to its own module must be removed from where it came
from.
* Anything that purports to become a top-level module _must_ be refactored
(following a discussion on the "dev" ML).
* The suggestion on the [ML
thread|https://markmail.org/message/65654d2qvcayqyfk] was to create sub-modules
*inside* {{commons-math-legacy}}, for codes that won't be refactored in the
short term.
MATH-1586 is perhaps a good starting point (well-defined task).
> Break "legacy" codes into several modules
> -----------------------------------------
>
> Key: MATH-1587
> URL: https://issues.apache.org/jira/browse/MATH-1587
> Project: Commons Math
> Issue Type: Sub-task
> Reporter: Gilles Sadowski
> Priority: Major
> Labels: cyclic, dependencies, refactor
> Fix For: 4.0
>
>
> Splitting the {{commons-math-legacy}} module would help clarify the
> dependency relationships between the various functionalities of the library
> (towards removing unnecessary cyclic dependencies).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
