Feature/android support

[choutman]

Android projects are based on Java. However, the Android Gradle plugin has its own way of defining its source sets and the corresponding class paths. In an Android project it is possible to have "build flavors". This enables Android developers to build different kinds of the same Android app using the same code base. For instance a free version and a paid version of the same app.

This pull request enables Android projects to build a class diagram using this plugin. Currently, only Android projects with Kotlin are supported.

[RoRoche]

Hi,
Thanks a lot for contributing to this project! It feeds my motivation because is a proof the concept is relevant. 😊🔋
I see that the Travis CI build failed and it reveals failing tests.
Did it run correctly locally?

[choutman]

Hi, I love it when documentation can be generated instead of statically created. So thank you for setting up the project. I just checked and locally the tests are succeeding. Later this evening I will try to locate the issue. First I thought it was due to different JDK versions, but it's not. Kind regards, Coen

…

On Thu, 10 Sep 2020 at 14:57, Romain Rochegude ***@***.***> wrote: Hi, Thanks a lot for contributing to this project! It feeds my motivation because is a proof the concept is relevant :) I see that the Travis CI build failed and it reveals failing tests. Did it run correctly locally? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA326UVOG3XT37JRUQSVPY3SFDELRANCNFSM4REQQV2A> .

[codecov-commenter]

Codecov Report

Merging #17 into master will increase coverage by 3.28%.
The diff coverage is 48.71%.

@@             Coverage Diff              @@
##             master      #17      +/-   ##
============================================
+ Coverage     63.21%   66.50%   +3.28%     
- Complexity       31       43      +12     
============================================
  Files            18       21       +3     
  Lines           174      209      +35     
  Branches          8       13       +5     
============================================
+ Hits            110      139      +29     
  Misses           64       64              
- Partials          0        6       +6     

Impacted Files	Coverage Δ	Complexity Δ
.../roroche/plantuml/urls/CompileClasspathUrls.groovy	33.33% <0.00%> (+33.33%)	1.00 <0.00> (+1.00)
...oroche/plantuml/tasks/BuildClassDiagramTask.groovy	62.06% <16.66%> (-7.17%)	2.00 <0.00> (ø)
...roroche/plantuml/android/AndroidProjectType.groovy	42.85% <42.85%> (ø)	5.00 <5.00> (?)
...roroche/plantuml/urls/MainOutputUrlsFactory.groovy	55.55% <55.55%> (ø)	1.00 <1.00> (?)
...e/plantuml/urls/CompileClasspathUrlsFactory.groovy	62.50% <62.50%> (ø)	2.00 <2.00> (?)
...github/roroche/plantuml/urls/MainOutputUrls.groovy	22.22% <0.00%> (+22.22%)	1.00% <0.00%> (+1.00%)
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 918e50c...efcf738. Read the comment docs.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[RoRoche]

Oh nice you made the build passes. Well done!
I'll perform the review within a few days.
FYI I strongly follow Elegant Objects principles: https://www.elegantobjects.org/
Some rules I can't transgress are: no null, no static, no public method without a declaration in an interface. 😉
Here are some hints about feedbacks I'm gonna make.
Happy refactor 😄

[RoRoche]

I target to don't have any static method in the codebase. Here is why: https://www.yegor256.com/2017/02/07/private-method-is-new-class.html

But looking at the source code you suggest, I guess that we could try something:

interface SuppertedProject {
  fun sourceUrls(): Urls

  abstract class Wrap(delegate: SuppertedProject) : SuppertedProject by delegate
}

class DefaultProject: SuppertedProject  {
  // do classical stuff
}

class AndroidLibrary: SuppertedProject {
  // do specific Android library stuff
}

class AndroidApplication: SuppertedProject {
  // do specific Android library stuff
}

// a impl that can determine the proper project impl to use or throw
class SmartProject(project: Project) : SupportedProject.Wrap(
  delegate = when(project) {
    project.pluginManager.hasPlugin("com.android.application") -> AndroidApplication()
    project.pluginManager.hasPlugin("com.android.library") -> AndroidLibrary()
    else -> DefaultProject()
  }
)

[RoRoche]

Pretty much the same comment, for these reasons:

• https://www.yegor256.com/2015/02/20/utility-classes-vs-functional-programming.html
• https://www.yegor256.com/2017/11/14/static-factory-methods.html

So you can move the logic to the SupportedProject suggested above.

[RoRoche]

Please use the high-level type, which is Urls in this case. The motivation is to always work by contract: https://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html#2-he-works-by-contracts

[RoRoche]

so this logic will also go to the dedicated Android's SupportedProject.

[RoRoche]

So this logic can go to a KotlinProject: SupportedProject and it will be composed such as:

class KotlinProject(private val project: Project): SupportedProject {
  fun sourceUrls(): Urls {
    def debugTask = project.tasks.find {
      it.name.contains("compile") && it.name.contains("DebugKotlin")
    }
    return new MainOutputUrls(
      new FilesUrls(
        [debugTask.destinationDir].toSet()
      )
    )
  }
}

class AndroidApplication(project: Project): SupportedProject.Wrap(
  delegate = KotlinProject(project)
) {
  fun sourceUrls(): Urls {
    val ktSrcUrls = super.sourceUrls()
    // return the specific list + ktSrcUrls 
  }
}

[RoRoche]

this logic goes to the default DefaultProject implementation.

[RoRoche]

I think we can reproduce the mechanism found here: https://github.com/RoRoche/plantuml-gradle-plugin/blob/master/src/test/groovy/com/github/roroche/plantuml/BuiltProject.groovy

I suggest a new interface such as:

interface TestableProject {
  fun toProject(): Project
}

and then you can put the logic to prepare a project such as:

class TestableAndroidApplication: TestableProject {
  fun toProject(): Project {
    ProjectBuilder.builder().build()
    project.apply plugin: "com.android.application"
    project.android {
      compileSdkVersion 21
    }
    project.evaluate()
    return project
  }
}

This will remove duplicate code in test.

[RoRoche]

These testing concerns must go to a dedicated Assertion implementation. Here is why: https://www.pragmaticobjects.com/chapters/003_reusable_assertions.html

The project is based on this library: https://github.com/pragmatic-objects/oo-tests

Here is an example: https://github.com/RoRoche/plantuml-gradle-plugin/blob/master/src/test/groovy/com/github/roroche/plantuml/BuildClassDiagramTaskTest.groovy

[RoRoche]

But maybe these tests are not worth considering now and we should focus the effort on the next ones (those about Urls generation)

[choutman]

Thanks for the review. As you may have noticed I did not have the time yet to make any changes. I'll try to get around it soon.