1111530IMP15-9a121b8959-62
LORM metric has impediments (see puzzles in LORM.xml). Once they are resolved, cover the metric with autotests and add it to reports list. (details on how to test the metrics are to be negotiated here - #107)
src/main/java/org/jpeek/App.javaKapralov Sergeyskapralov@mail.ru20411130IMP111-5690cd5a27-36
LORM: figure out how to extract the concepts from each method of a class and then measure their "dispersal": how far apart they are semantically speaking. This would be the same as asking "to what degree are these methods talking about the same things?". Based on a couple of supporting papers that I added to this ticket (here: https://github.com/yegor256/jpeek/issues/111#issuecomment-365651455), I believe the way forward is to use Latent Semantic Indexing of the methods of the class and see how close or synonymous they are with the concept expressed in the class name itself. There seem to be a few java libraries available for latent semantic indexing that we can use.
src/main/resources/org/jpeek/metrics/LORM.xslrultorme@rultor.com1121530IMP15-c8802e5565-73
`conceptual-relations` are pairs of methods in the class for which one method contains conceptual relations forming external links out of the set of concepts that belong to the method to or from the set of concepts belonging to another method in the class (quoted from here: https://github.com/yegor256/jpeek/blob/master/papers/izadkhah17.pdf). Right now it is stubbed because information about the method's conceptual relations are not available anywhere in the project. Ensure that JPeek core collects information on such relations (#110) and unstub the lines commented below.
src/main/resources/org/jpeek/metrics/LORM.xslKapralov Sergeyskapralov@mail.ru16011230IMP112-f7b740c567-88
Implement natural language processing techniques to analyze conceptual similarity of methods. Two methods have a `conceptual-relation` if they contain at least one same `concept`. `concepts` are identified by semantic processing of the class/method, as being associated in the knowledge-base with that class/method (original paper in /papers/etzkorn00.pdf). The original paper does not explicitly define the implementation of semantic processing, or which NLP methods are being used, but it is a knowledge-based system, which means that additional input must inserted into the LORM method - that is, a set of possible concepts - which are then recognized in a particular method/piece of code. This set of possible concepts depends on the `domain` that the class is in. One way of interpreting what the `domain` is (this is not defined in the original paper), is the business domain the class is used for. Another definition of `domain` also comes to mind - the programming language being used. Concepts could be defined as all reserved Java keywords and "semantic processing" recognizes which reserved keywords are used in a particular method. Hence, if two methods use same reserved keywords, they have a `conceptual-relation`. Using this definition would require no additional input by the user of the LORM method. Right now it is stubbed because NLP/semantic processing is not implemented yet.k Ensure that JPeek core implements these techniques, collects information on such relations and unstub the lines commented below.
src/main/resources/org/jpeek/metrics/LORM.xslRok Povsicrok.povsic@gmail.com117930IMP9-5e913f6c59-62
TCC metric has impediments (see puzzles in TCC.xml). Once they are resolved, cover the metric with autotests and add it to reports list. (details on how to test the metrics are to be negotiated here - #107)
src/main/java/org/jpeek/App.javaKapralov Sergeyskapralov@mail.ru118930IMP9-e2b8b5ba64-67
LCC metric has impediments (see puzzles in LCC.xml). Once they are resolved, cover the metric with autotests and add it to reports list. (details on how to test the metrics are to be negotiated here - #107)
src/main/java/org/jpeek/App.javaKapralov Sergeyskapralov@mail.ru25211830DEV118-aa952a1573-78
Add test for LCC with "IndirectlyRelatedPairs" and others. In "IndirectlyRelatedPairs" all methods exist in one transitive closure, so the result should be {@code 1d}. Also, all classes without transitive relations should have the same LCC metric as TCC metric. Before do it we have to fix puzzles in LCC.xml.
src/test/java/org/jpeek/MetricsTest.javaAlexander Menshikovsharplermc@gmail.com25311830DEV118-1644575875-77
LCC metric has impediments (see puzzles in LCC.xml and in `MetricsTest`). Once they are resolved add it to reports list.
src/main/java/org/jpeek/App.javaAlexander Menshikovsharplermc@gmail.com35611830DEV118-560e90f953-59
Add test for LCC with "IndirectlyRelatedPairs" and others. In "IndirectlyRelatedPairs" all methods exist in one transitive closure, so the result should be {@code 1d}. Also, all classes without transitive relations should have the same LCC metric as TCC metric. Before do it we have to fix puzzles in LCC.xml. @checkstyle JavadocTagsCheck (500 lines)
src/test/java/org/jpeek/MetricsTest.javaMohamed Nizarnizarucsc@gmail.com119930IMP9-7a54dc2b62-65
`indirectly-related-pairs` are pairs of methods, which are through other directly connected methods. https://pdfs.semanticscholar.org/672e/de6e3e600eafd84036a0b983b88e481ac626.pdf Right now it is stubbed because information about method-method communication is yet to be provided in skeleton.xml (issue #106).
src/main/resources/org/jpeek/metrics/LCC.xslKapralov Sergeyskapralov@mail.ru21711930DEV119-5f1c56e061-67
`indirectly-related-pairs` are pairs of methods, which are connected through `directly-related-pairs`. See section 3.1 of https://pdfs.semanticscholar.org/672e/de6e3e600eafd84036a0b983b88e481ac626.pdf The key sentence is "The indirect connection relation is the **transitive closure** of direct connection relation". See https://en.wikipedia.org/wiki/Transitive_closure for more info on what is a Transitive Closure. We need to apply a Transitive Closure Algorithm on a graph of `directly-related-pairs`. A simpliest Transitive Closure algorithms has O(V³) time complexity and involves a mutable V×V table (V is amount of vertices). See https://www.geeksforgeeks.org/transitive-closure-of-a-graph/ for an example.
src/main/resources/org/jpeek/metrics/LCC.xslreximreximkut@gmail.com120930IMP9-57e7e31a48-50
`directly-related-pairs` currently don't take into account cases when two methods are directly related through calling the third one. This could be possible to take into account only when skeleton will be able to provide method-method relation information (issue #106)
src/main/resources/org/jpeek/metrics/TCC.xslKapralov Sergeyskapralov@mail.ru19312030IMP120-5199fe2242-44
TCC: inclusion of inherited attributes and methods in the analysis should be configurable. Come back here after #187 is fixed and adjust the xpath for `attrs` and `methods` accordingly.
src/main/resources/org/jpeek/metrics/TCC.xslrultorme@rultor.com19412030IMP120-7c3cf0d448-49
TCC: this metric needs to exclude private methods from the analysis. Adjust the xpath for `methods` accordingly after #188 is fixed.
src/main/resources/org/jpeek/metrics/TCC.xslrultorme@rultor.com19512030IMP120-bc67ce3857-59
TCC: need to come back and refactor the following after #156 is fixed. The ops for fields must be properly filtered to ensure that they belong to the enclosing class.
src/main/resources/org/jpeek/metrics/TCC.xslrultorme@rultor.com1219330IMP93-25a7c26738-40
NHD needs to be tested against the following after #103 is fixed: NoMethods, OneVoidMethodWithoutParams, WithoutAttributes, OneMethodCreatesLambda. NHD score for all these is "NaN".
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1229330IMP93-1245446541-43
NHD calculation needs to take into account the method's visibility, which should be configurable and implemented after #101 is fixed.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1241830IMP18-58649db938-40
Impediment: #103 must be fixed before LCOM5 is tested against: NoMethods, OneVoidMethodWithoutParams, WithoutAttributes, OneMethodCreatesLambda. The LCOM5 value for these will be "NaN".
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1251830IMP18-f4ca747e41-43
Impediment: test for LCOM5 with "Bar" is not working because the generated skeleton.xml is not including all attributes being used by a method. See #114.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1389230IMP92-98d84f5f50-52
Impediment: test for LCOM2/3 with "Bar" is not working because the generated skeleton.xml is not including all attributes being used by a method. See #114.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1399230IMP92-8b89e20553-55
Impediment: test for LCOM3 with "OneMethodCreatesLambda" does not work because the skeleton.xml creates a <method> for the lambda with no way to discriminate it from regular methods.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com22813930DEV139-752903d5142-149
LCOM3: Must first fix #171 by ignoring synthetic methods. These are constructs generated by the compiler that are not declared in the source code. After fixing, implement test case "OneMethodCreatesLambda" for LCOM3. To ignore synthetic methods, enclose the entire body of this method within an IF that checks if `access` != Opcode.ACC_SYNTHETIC. As per docs for ClassVisitor.visitMethod: "This parameter also indicates if the method is synthetic and/or deprecated."
src/main/java/org/jpeek/skeleton/XmlClass.javaGeorge Aristygeorge.aristy@gmail.com1406830IMP68-6427b29450-53
SCOM has an impediment on issue #103: cannot currently be tested in MetricsTest when the resulting value is "NaN". Affected tests are: NoMethods, OneVoidMethodWithoutParams, WithoutAttributes, OneMethodCreatesLambda.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1416830IMP68-96e0ea9254-56
SCOM has an impediment on issue #114: cannot currently be tested against "Bar" because the skeleton is incorrectly excluding some attributes from some methods that are using them.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com1426830IMP68-03d5665d129-131
Calculate SCOM_min as per page 86 of the paper (I don't know what the "int" function means). This value can be used as a guide to determine whether a class needs to be split into several classes.
src/main/resources/org/jpeek/metrics/SCOM.xslGeorge Aristygeorge.aristy@gmail.com1431730IMP17-e026505369-72
MWE metric has impediments (see puzzles in MWE.xml). Once they are resolved, cover the metric with autotests and add it to reports list. (details on how to test the metrics are to be negotiated here - #107)
src/main/java/org/jpeek/App.javaKapralov Sergeyskapralov@mail.ru1441730IMP17-049820b647-52
The current implementation of MWE metric expects information about LDA topics and their probability in skeleton.xml by xpath `class/methods/method/topics/topic`. `topic` items must have two mandatory attributes - `@name` (topic unique identifier) and `@p` (probability of the topic's occurence in the method). Currently this part of information is missing in skeleton.xml. Ensure that the core part of JPeek provides the information about topics and their probability and update the metric in accordance with the provided XML structure.
src/main/resources/org/jpeek/metrics/MWE.xslKapralov Sergeyskapralov@mail.ru1451730IMP17-f82757ae75-79
Di value is supposed to be calculated by formula: Di = sum( -Qdi * log(Qdi) ) / log(n). See the MWE metric description for details. However, logarithm function is currently not available in XSL, that's why it is stubbed. Ensure that there is a way to define logarithm in metrics XSL and unstub Di calculation.
src/main/resources/org/jpeek/metrics/MWE.xslKapralov Sergeyskapralov@mail.ru1466615IMP66-9d79a0db122-124
Add the CCM metric report here when all the puzzles about it are resolved. It requires 'params' to be passed in in order to properly include or exclude ctors.
src/main/java/org/jpeek/App.javaGeorge Aristygeorge.aristy@gmail.com1476630IMP66-c487e21b52-55
For CCM, the following test cases need to be added after #103 is fixed: NoMethods, WithoutAttributes, OneMethodCreatesLambda, OneVoidMethodWithoutParams. The CCM value for these cases is NaN.
src/main/resources/org/jpeek/metrics/CCM.xslGeorge Aristygeorge.aristy@gmail.com1486630IMP66-1f52dc9d58-60
For CCM, cannot add test case for class Bar because it is blocked by #114. Omission of the 'NAME' <op> for "getKey" messes up calculations. Add test case after #114 is fixed.
src/main/resources/org/jpeek/metrics/CCM.xslGeorge Aristygeorge.aristy@gmail.com1496630IMP66-72fdfc2363-67
For CCM, need to add OR condition to the following xsl:if to check whether two methods both call another method in common for the same class. The skeleton currently does not produce this information. After this is done, we can add test cases for Foo, OverloadMethods, and TwoCommonAttributes.
src/main/resources/org/jpeek/metrics/CCM.xslGeorge Aristygeorge.aristy@gmail.com15410430IMP104-9f730941104-107
The logic for overwriting the target directory is very procedural and needs to be refactored. Suggestion: 'target' should be its own animated object where the logic is triggered in its 'toPath' method.
src/main/java/org/jpeek/Main.javaGeorge Aristygeorge.aristy@gmail.com16610030IMP100-e0c9e789127-131
The skeleton for each Report is transformed by applying various changes via XSLChain. This mechanism is for stuff that does not apply to all the metrics and shouldn't necessarily be in the common skeleton. Start implementing and applying stylesheets (where needed), as required in the initial ticket (#100).
src/main/java/org/jpeek/App.javaMihai Andronacheamihaiemil@gmail.com1756430IMP64-b6d7d67d66-69
Implement the C3 method according to the description above. The variable names and comments have to be extracted into a set of words. JPeek core will have to provide all comments for each method so words can be extracted and LSI calculated for each method.
src/main/resources/org/jpeek/metrics/C3.xslRok Povsicrok.povsic@gmail.com17610630IMP106-8e3f4f0173-76
Adding a new 'op' for calls to methods broke some tests and hence they were removed. Need to do the math for those tests and then add them back: SCOM with "Foo", SCOM with "MethodsWithDiffParamTypes", and SCOM with "OverloadMethods".
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com18011430IMP114-7bfa1f3a270-281
Find and include the name of the variable the method is called on, if possible. Currently, only the name of called method is retrieved. This is currently implemented in `visitMethodInsn` down below. Example 1: `Bar.NAME.length();` - Here, `length` is retrieved from the method `visitMethodInsn`'s - param `name`, but the word `NAME` itself is not included in any of - the `visitMethodInsn` arguments. Example 2: `src.length();` - Here, `length` is retrieved from the method `visitMethodInsn`'s - param `name` but the word `src` itself is not included in any of - the `visitMethodInsn` arguments.
src/main/java/org/jpeek/Skeleton.javaRok Povsicrok.povsic@gmail.com18110330IMP103-11fe862663-69
NaN-based assertions introduced in #103 made complexity of `testsTarget` higher. Potentially, if more possible invariants will be introduced, enlarging complexity may become real problem for this method. That's why parametrized tests as a generic way of testing all metrics is proposed to be refactored. Possible alternatives are either classical JUnit modules, one per test, or wrapping parameters to reusable test case objects, like described here - https://github.com/yegor256/cactoos-test
src/test/java/org/jpeek/MetricsTest.javaKapralov Sergeyskapralov@mail.ru19913430IMP134-9a3b0d9026-28
Index.xsd: add `xsd:documentation` tags as per issue #134. We need to document the schemas in src/resources/org/jpeek/xsd so that the semantics of the generated XML documents is transparent for maintainers.
src/main/resources/org/jpeek/xsd/index.xsdrultorme@rultor.com28219930DEV199-15890460143-144
Index.xsd: add `xsd:documentation` as per #199 to the `bars` element. The element seems to describe the graph on the index.html
src/main/resources/org/jpeek/xsd/index.xsdrultorme@rultor.com20013430IMP134-3180ea3826-28
Matrix.xsd: add `xsd:documentation` tags as per issue #134. We need to document the schemas in src/resources/org/jpeek/xsd so that the semantics of the generated XML documents is transparent for maintainers.
src/main/resources/org/jpeek/xsd/matrix.xsdrultorme@rultor.com20113430IMP134-7dff704326-28
Metric.xsd: add `xsd:documentation` tags as per issue #134. We need to document the schemas in src/resources/org/jpeek/xsd so that the semantics of the generated XML documents is transparent for maintainers.
src/main/resources/org/jpeek/xsd/metric.xsdrultorme@rultor.com2039030IMP90-29fbce7677-78
OCC metric: need to implement the rest of the test cases. Could only fit test for sample class "Foo" within budget in this one.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com2056730IMP67-33d4046977-78
PCC: add the rest of the test cases for this metric. Could only fit test case for MethodsWithDiffParamTypes within budget.
src/test/java/org/jpeek/MetricsTest.javaGeorge Aristygeorge.aristy@gmail.com215830DEV8-429ff08255-57
LCOM4: #156 needs to be fixed in order to avoid confusing access to fields belonging to other classes as if they actually belong to this class. Once #156 is fixed, refactor xpaths 'this_attrs' and 'other_attrs' accordingly.
src/main/resources/org/jpeek/metrics/LCOM4.xslrultorme@rultor.com31021530DEV215-e68a3c3f76-83
LCOM4: Graph algorithm to determine disjoint sets. Currently we can only identify the dependencies via only one graph hop so we can't trace methodFour that uses 'num' indirectly via methodTwo and methodOne. Calculating Disjoint sets (also known as Connected Components), requires a graph traversal algorithm like depth-first search. This one will be tricky to implement in XSLT. After implementing, remove the @Ignore.
src/test/java/org/jpeek/metrics/Lcom4Test.java@rultorme@rultor.com41531030DEV310-b9e19c8374-82
LCOM4: Graph algorithm to determine disjoint sets. We started to implement disjoint calculus by putting a disabled test. Continue to implement the actual calculus of these sets and remove the @Disabled annotation on DisjointTest. so we can't trace methodFour that uses 'num' indirectly Calculating Disjoint sets (also known as Connected Components), requires a graph traversal algorithm like depth-first search. This one will be tricky to implement in XSLT. After implementing, remove the @Disabled from the below test too.
src/test/java/org/jpeek/metrics/Lcom4Test.javaHDoussdouss.hamdi@gmail.com43141530DEV415-1e78bb5374-77
LCOM4: Graph algorithm to determine disjoint sets. Disjoint sets calculus is now implemented. We should continue calculating LCOM4 metrics (probably you should wait for #413, #403. After implementing, remove the @Disabled from the below test too.
src/test/java/org/jpeek/metrics/Lcom4Test.javaHDoussdouss.hamdi@gmail.com216830DEV8-435f2b3360-61
LCOM4: need to finish implementing the rest of the test cases. Only test case "MethodMethodCalls" was implemented in this 30min ticket.
src/main/resources/org/jpeek/metrics/LCOM4.xslrultorme@rultor.com29421630DEV216-0c93d2e360-62
LCOM4: need to finish implementing the rest of the test cases. Only test case "OneCommonAttribute", "NotCommonAttributes", "NotCommonAttributesWithAllArgsConstructor", was implemented in this 30min ticket.
src/main/resources/org/jpeek/metrics/LCOM4.xslrultorme@rultor.com29521630DEV216-5540d94265-69
LCOM4: "NotCommonAttributesWithAllArgsConstructor" test now fails. Constructor with all attributes parameters should not affect LCOM4 metric. So LCOM4.xsl needs to be fixed in order to avoid constructors affection to the metric values. "NotCommonAttributesWithAllArgsConstructor" test case must be added into collection returning by the targets() in the MetricsTest.java when this puzzle done.
src/main/resources/org/jpeek/metrics/LCOM4.xslrultorme@rultor.com2186530DEV65-657d930a51-53
TLCOM: we are including access to ALL fields here. After #156 is fixed, come back and refactor xpath for $Ms_that_use_attrs, $left_attrs, and $right_attrs in order to avoid including access to fields belonging to other classes.
src/main/resources/org/jpeek/metrics/TLCOM.xslGeorge Aristygeorge.aristy@gmail.com2196530DEV65-8529ead179-83
TLCOM: need to establish transitive connections between methods with arbitrarily long chains of method calls between them. Right now, this code can establish transitive connections to a max depth of 3 levels, ie up to something like this: m1 calls m2 calls m3 which uses a3 therefore m1 is connected to m3. It will miss connections in longer chains. After fixing this, maybe we can add it to the standard metrics in App.
src/main/resources/org/jpeek/metrics/TLCOM.xslGeorge Aristygeorge.aristy@gmail.com2206515DEV65-76f12f4d86-87
TLCOM: add test for OneMethodCreatesLambda after #171 is fixed. The extra synthetic method introduced by the compiler distorts this metric's result.
src/main/resources/org/jpeek/metrics/TLCOM.xslGeorge Aristygeorge.aristy@gmail.com22413530DEV135-d5b2c3f626-28
Skeleton.xsd: add a reference to this schema from the generated skeleton.xml. Schemas from src/resources/org/jpeek/xsd must be referenced in generated XMLs.
src/main/resources/org/jpeek/xsd/skeleton.xsdGeorge Aristygeorge.aristy@gmail.com22513530DEV135-9cabe02729-31
Matrix.xsd: add a reference to this schema from the generated matrix.xml. Schemas from src/resources/org/jpeek/xsd must be referenced in generated XMLs.
src/main/resources/org/jpeek/xsd/matrix.xsdGeorge Aristygeorge.aristy@gmail.com22613530DEV135-4462c34d29-31
Index.xsd: add a reference to this schema from the generated index.xml. Schemas from src/resources/org/jpeek/xsd must be referenced in generated XMLs.
src/main/resources/org/jpeek/xsd/index.xsdGeorge Aristygeorge.aristy@gmail.com22713530DEV135-1c80191e142-146
The current solution to add the reference to 'metric.xsd' in the generated 'metric.xml' is too complex for the task at hand. Refactor towards a simpler solution that ideally would just require one or two Xembly instructions to add the required attribute.
src/main/java/org/jpeek/Report.javaGeorge Aristygeorge.aristy@gmail.com32722730DEV227-fbf042c2209-214
Add a test to check whether passing params to XSLDocument really works. Currently only C3 metric template is known to use parameter named 'ctors'. However C3.xsl is a work in progress and has impediments, see #175. In case the parameter becomes obsolete, consider simplifying construction of XSLDocument without params (see reviews to #326).
src/main/java/org/jpeek/Report.javaIlyas Gasanovtorso.nafi@gmail.com26115630DEV156-4fb50d7939-43
Skeleton must be upgraded to determine if a field being accessed in a method belongs to that class or to another class. The test in findFieldWithQualifiedName must be uncommented when this issue is resolved. Please see #156 for more detailing in upgrading skeleton behavior.
src/test/java/org/jpeek/skeleton/SkeletonTest.javarultorme@rultor.com29718830DEV188-d010c84531-33
Skeleton.xsd: remove method/@public. We should use the new enum method/@visibility which is more flexible. For this remove the attribute from this file and from XmlClass.java
src/main/resources/org/jpeek/xsd/skeleton.xsd@Serranyapeterlamby@web.de35929730DEV297-5540e44685-86
this method appears three times and may be useful for future tests, so extract the method as a new class.
src/test/java/org/jpeek/skeleton/XmlClassTest.javaGnusin Pavelpavel.sin.gnusin@gmail.com35730830DEV308-016448ee45-48
Due to introduce new version of qulice 0.18.17 there were many 'JavadocTagsCheck' suppression, so we need to fix that by remove author, version and since tags in all javadoc. After that remove 'JavadocTagsCheck' suppression.
src/main/java/org/jpeek/Main.javaGnusin Pavelpavel.sin.gnusin@gmail.com35815630DEV156-7b4862fe38-43
Skeleton must be upgraded to determine if a field being accessed in a method belongs to that class or to another class. The test in findFieldWithQualifiedName must be uncommented when this issue is resolved. Please see #156 for more detailing in upgrading skeleton behavior. @checkstyle JavadocTagsCheck (500 lines)
src/test/java/org/jpeek/skeleton/SkeletonTest.javaMohamed Nizarnizarucsc@gmail.com38032330DEV323-1d9c683531-34
Migrate the tests in the sub-packages: org.jpeek.metrics, org.jpeek.skeleton and org.jpeek.web to junit 5, so they won't import any classes from junit 4 anymore. Then, we should find a way to exclude junit 4 from project dependecy, so they won't be imported anymore.
src/test/java/org/jpeek/package-info.javaHamdi Doussdouss.hamdi@gmail.com38838030DEV380-bf03436929-33
Migrate the tests in the remaining sub-package org.jpeek.web to junit 5, so they won't import any classes from Junit 4 anymore. Once we have no more Junit 4 tests, we can remove junit-vintage-engine dependency. Ideally, we should find a way to exclude junit 4 from project dependecy, so its API won't be imported anymore.
src/test/java/org/jpeek/package-info.javaHDoussdouss.hamdi@gmail.com38132330DEV323-a6bff46158-59
This test is fully written against JUnit 4 API. Migrate this parametrized test to junit 5, so it won't import any classes from junit 4 anymore.
src/test/java/org/jpeek/MetricsTest.javaHDoussdouss.hamdi@gmail.com39029630DEV296-9cbcd90632-35
Now that we have the infrastructure to implement some metrics in other means than XSL transformations. We should try to implement some metrics with Java. We could start with LCOM4 metric that implies a graph traversal algorithm.
src/main/java/org/jpeek/Report.javaHamdi Doussdouss.hamdi@gmail.com39639030DEV390-2105ac60146-151
this constructor now has too many arguments. We should find a way to refactor the constructor or the class to have fewer parameters. We could start by analyzing the usage of this.params (args in this constructor) and get rid of it if it is not used. Another idea could be to have a data class contaning reporting params: name, args, mean, sigma.
src/main/java/org/jpeek/XslReport.javaHDoussdouss.hamdi@gmail.com39739030DEV390-3f627cdf33-36
We have a separate interface to calculate XML metrics. We should continue to the goal defined in #296 where we should have a java implementation to calculate metrics. The motivation is to be able to make calculations impossible or too difficult to implement in xsl, like LCOM4.
src/main/java/org/jpeek/Calculus.javaHamdi Doussdouss.hamdi@gmail.com40839730DEV397-9435187533-36
We start having the infrastructure for graph building from skeleton. The graph have just nodes for now without any connection between them. We should continue to build nodes connections to reflect methods (inter-)calls. After that, we should continue to implement an LCOM4 metrics calculus based on the graph.
src/main/java/org/jpeek/Calculus.javaHDoussdouss.hamdi@gmail.com41240830DEV408-c3533a7c33-35
We start having the infrastructure for graph building from skeleton with node connections representing methods intercalls. We should continue to implement XML metrics generation using Java (see original issue #296).
src/main/java/org/jpeek/Calculus.javaHamdi Doussdouss.hamdi@gmail.com41641230DEV412-3d56567633-38
We start implementing LCOM4Calculus implementation. We should continue calculating real 'class@value' and 'class/vars/var[@id=pairs]/text' values and remove @Disabled annotation on all Lcom4CalculusTest class. If we choose to calculate LCOM4 with Java only we should also remove LCOM4.xsl part that is doing the calculus and let the xsl here just to build the structure of the xml result. This part is especially the one calculating "xsl:variable name='E'" L73->L89, and the one doing the division L97 -> L99
src/main/java/org/jpeek/calculus/Calculus.javaHamdi Doussdouss.hamdi@gmail.com41741230DEV412-a459088d40-42
The methodMethodCalls test is asserting the expected LCOM4 value for MethodMethodCalls. Let's have more test cases for LCOM4 metric to cover more realistic cases.
src/test/java/org/jpeek/calculus/java/Lcom4Test.javaHDoussdouss.hamdi@gmail.com41340830DEV408-56dd88a671-74
Nodes connections are built based on method calls. For now, the skeleton does not reflect which overloaded method is called, so the identification of the called method is made by its name. We should wait for #403 to be solved and enhance this implementation to consider the overloaded called method.
src/main/java/org/jpeek/graph/XmlGraph.javaHamdi Doussdouss.hamdi@gmail.com44041330DEV413-309fe9c4110-113
The following 2 private methods (call and args) could be extracted in two new class to encapsulate logic of serializing an XML method call to its string representation; and the logic of serializing an XML method arguments to its string representation.
src/main/java/org/jpeek/graph/XmlGraph.javaHamdi Doussdouss.hamdi@gmail.com44344030DEV440-332bf73335-37
This class XmlMethodCall should be made public and a test class named XmlMethodCallTest should be added to verify its behaviour.
src/main/java/org/jpeek/graph/XmlMethodCall.javaVictor Noëlvictor.noel@crazydwarves.org44444030DEV440-83d3f1f735-37
This class XmlMethodArgs should be made public and a test class named XmlMethodArgsTest should be added to verify its behaviour.
src/main/java/org/jpeek/graph/XmlMethodArgs.javaVictor Noëlvictor.noel@crazydwarves.org45944430DEV444-ff900aeb54-56
This test was disabled because the implementation of XmlMethodArgs was modified to comply with what will be done in #437. Wait until #437 is resolved and then reenable this test
src/test/java/org/jpeek/graph/XmlMethodArgsTest.javaHamdi Doussdouss.hamdi@gmail.com44141330DEV413-b264bb9843-45
In #413 we evolved graph connection building to take into account overloaded method differentiation as stated in #403. Wait until #403 is fully resolved (for now, it still has the puzzle #437) and then activate back the 2 tests in this class.
src/test/java/org/jpeek/graph/XmlGraphTest.javaHamdi Doussdouss.hamdi@gmail.com44544130DEV441-ed4884a540-43
Continue the work started with extracting XmlMethodCall and XmlMethodArgs and extract more code from this class pertaining to serializing XML to string. The objective is to have tested classes and to remove the checkstyle suppression below.
src/main/java/org/jpeek/graph/XmlGraph.javaVictor Noëlvictor.noel@crazydwarves.org47244530DEV445-b9bbd96639-44
Continue the work started with extracting XmlMethodCall, XmlMethodArgs and XmlMethodSignature, and extract more code from this class pertaining to serializing XML to string. The objective is to have tested classes and to remove the checkstyle suppression below. Finally consider extracting the whole 'build' method body into a separate class extending ListEnvelope.
src/main/java/org/jpeek/graph/XmlGraph.javaVytautas Žurauskaszurauskas.vytautas@gmail.com47344530DEV445-1cfd81f677-80
This method works only for skeletons with a single class because it assigns all methods in the skeleton to the first class it finds. Instead, it should iterate through classes and then through methods of each class.
src/main/java/org/jpeek/graph/XmlGraph.javaVytautas Žurauskaszurauskas.vytautas@gmail.com47330DEV473-a79b415538-41
Find a way to eliminate this ClassDataAbstractionCouplingCheck. The class probably needs to be split into smaller ones, perhaps extracting the maps into separate objects (extending MapEnvelopes), or maybe the list itself.
src/main/java/org/jpeek/graph/XmlGraph.javaVytautas Žurauskaszurauskas.vytautas@gmail.com48440032330DEV323-1670a5eb58-62
This test is fully written against JUnit 4 API. Migrate this parametrized test to junit 5, so it won't import any classes from junit 4 anymore. Once we have no more Junit 4 tests, we can remove junit-vintage-engine dependency. Ideally, we should find a way to exclude junit 4 from project dependecy, so its API won't be imported anymore.
src/test/java/org/jpeek/MetricsTest.javaHDoussdouss.hamdi@gmail.com43740330DEV403-214b0d9e87-102
Method call description has to contain information about the method's arguments. That is important to differentiate overloaded methods to calculate LCOM4. We need to add a tag 'name' to reflect the method name and a tag 'args' to reflect the method's arguments. skeleton.xsd should be changed to support the method's arguments. Also, don't forget to delete @Disabled lines in SkeletonTest#skeletonShouldReflectExactOverloadedCalledMethod. Example: <op code="call"> <name>OverloadMethods.methodOne</name> <args> <arg type="Ljava/lang/String">?</arg> <arg type="Ljava/lang/String">?</arg> </args> </op>
src/main/java/org/jpeek/skeleton/OpsOf.javasbt-garus-dggarus.d.g@gmail.com46943730DEV437-43230a3b52-61
Skeleton structure has changed in #437, and therefore some xsl metrics calculus are in error or give bad results. Fix the corresponding xslt files and then reput these expected results in metricstest-params.csv MethodsWithDiffParamTypes,CCM,0.0667d MethodsWithDiffParamTypes,SCOM,0.2381d OverloadMethods,SCOM,0.75d TwoCommonAttributes,TLCOM,4.0d Bar,CCM,0.2222d TwoCommonMethods,CCM,0.0333d TwoCommonMethods,LORM,0.26667d
src/test/java/org/jpeek/MetricsTest.javarultorme@rultor.com47043730DEV437-e6b9517141-42
This test was disabled after skeleton structure has changed as in #437. Fix LORM.xsl to make it comply with the new structure and then reenable this test again.
src/test/java/org/jpeek/metrics/LormTest.javarultorme@rultor.com45344730DEV447-5b43df5f49-54
This class includes the constructor as part of the methods it considers, so it breaks some of the metrics. For example the CCM metrics test on OverloadMethods (see metricstest-params.csv) expects 0.6 as a result while it should be 1. See #447 for details on that. Find out if the constructor should be counted as one of the methods or not (does it depend on the metrics for example?) and fix it this class and the tests if needed.
src/main/java/org/jpeek/skeleton/XmlClass.javaVictor Noëlvictor.noel@crazydwarves.org46045230DEV452-fc6e85e048-50
Improve how to use section on README.md How to Use section must be improved; we need to explain the many parameters that jpeek jar accepts and the default values for each parameter.
README.mdpaulodamasopauloeduardolobo@gmail.com46145230DEV452-6485f2e2138-141
Extract report building Analyze method is too big. We need to extract report building from here and use a map instead of if statements se we can make easier to add and remove metrics from execution.
src/main/java/org/jpeek/App.javapaulodamasopauloeduardolobo@gmail.com48144930DEV449-96cd40b839-50
The `node` method in this interface was designed with only XSL implementation in mind - it uses the `metric` parameter to select the XSL file and uses that file to transform the `skeleton`. This makes Java based implementations a little awkward because the `metric` parameter becomes redundant: there is a Java implementation for each metric, and these implementations already know which metric they are for. The question becomes - how to select correct java implementation for a given metric and integrate it seamlessly with XSL calculus in `XslReport`. One option could be removing the `metric` parameter from the method and injecting a Calculus for a concrete metric in `XslReport` directly. Another could be implementing Chain Of Responsibility pattern. Decide on the best way to integrate Java based Calculus with XSL based Calculus in `XslReport` and implement it.
src/main/java/org/jpeek/calculus/Calculus.javaVytautas Žurauskaszurauskas.vytautas@gmail.com48244930DEV449-dd12396b88-94
Implement NCC calculation with `XmlGraph` and use this class to fix CCM metric (see issue #449). To do this, this class, once it works correctly, should be integrated with XSL based calculuses in `XslReport` (see `todo #449` in Calculus). Write a test to make sure the metric is calculated correctly. Also, decide whether the whole CCM metric should be implemented in Java, or only the NCC part. Update this `todo` accordingly.
src/main/java/org/jpeek/calculus/java/Ccm.javaVytautas Žurauskaszurauskas.vytautas@gmail.com