Hi Ben, Le 4 sept. 2015 à 17:04, Ben Coman a écrit :
> On Fri, Sep 4, 2015 at 9:13 PM, Christophe Demarey > <christophe.dema...@inria.fr> wrote: >> Hi, >> >> I created a job to automatically generate a report of the Pharo image >> dependencies as well as current bootstrap dependencies. >> You can find them here: >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTML_Report/dependency-report.html >> https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTML_Report/bootstrap-dependency-report.html >> >> >> There are a lot (too many) dependencies but you can focus on some of them >> with the search field. >> Dependencies inside orange boxes are dependencies that are there but that we >> ignore (for example, an example method adds an extra-dependency). It should >> be fixed later but is not a problem for now. Ignored dependencies are >> declared in the package manifest in #ignoredDependencies. >> Dependencies inside red boxes are dependencies we want to remove for the >> bootstrap. For now, they are listed in the bootstrap dependency report. >> >> People that are willing to help to have a more modular Pharo could first >> take a look at the bootstrap dependency report and check dependencies that >> we should cut. >> Once we know, we can open issues on fogbugz in the 'bootstrap category' and >> update manifests accordingly. >> To investigate more deeply dependencies, you can use the DependencyAnalyzer >> (in the Pharo Catalog) to actually check dependencies (inheritance, >> reference, extension, traits, message send). > > I tried the Dependency Analyzer. First a minor point, it wasn't > obvious how to invoke it. I expected to see "Dependency Analyzer" in > the tools but its not there. I think I correctly guessed it was > "Package Dependencies Browser", but it would be better to match the > catalog name. ok, I will fix that. I will also add the analyzer in the system. In a second step, I will introduce rules to check dependencies. > The sample dependency I looked at from bootstrap-dependency-report.html > was Collections-Streams --> Tool-Transcript > which seems to be due to only single method "Generator class>>examplePrimes". > So should this be coloured orange by marking it in #ignoredDependencies ? The clean solution is to have a package Collections-Streams-Example with this method. It depends how we want to be strict with that. I can live with no additional package and the dependency added in #ignoredDependencies. There are so many wrong dependencies in the system that I will prefer at a first step to put dependencies introduced by example methods or settings by example as ignored dependencies because they will not be called. We could fix that in a second step if we want and let us focus on stronger dependencies. Thanks for helping. PS: Even for people not having time to clean the system, when you contribute code to the image, pleas check that you do not introduce a dependency from a low-level package to a higher level package. It is not obvious to catch but for example, check that you do not introduce a dependency to UI packages when the package could work without UI.
smime.p7s
Description: S/MIME cryptographic signature
