3

After a lot of searching, it was the last option to raise it here! In eclipse, I am designing such project structure using Gradle, as shown below...

Algorithms              //Parent Project
    -SubModuleCore      //Child Project for common utilities & dependencies
        -build.gradle
    -SubModuleOne       //Child project for any operation
        -build.gradle   //Added 'SubModuleCore' as a dependency like compile project(':SubModuleCore')
    -SubModuleTwo       //Child project for another operation
        -build.gradle   //Added 'SubModuleCore' as a dependency like compile project(':SubModuleCore')
    -build.gradle
    -settings.gradle

Services                //Stand-Alone project
    -build.gradle       //Here I want to add 'Algorithms' as a single dependency
    -settings.gradle

Project structures are same in eclipse work-space as shown above. I am able to generate individual .jar of Algorithms project. So the problem is I want to add this Algorithms project as a single dependency in project Services like compile project(':Algorithms'). But eclipse just saying 'shut-up!'. I don't want to publish it somewhere like maven central / jitpack etc. instead I want to do it locally. I'm trying this way...

Services/build.gradle

apply plugin: 'war'
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'eclipse-wtp'
project.webAppDirName = 'WebContent'

repositories {
    jcenter()
    mavenCentral()
}

dependencies {
    compile fileTree(dir: 'lib', include: ['*.jar'])
    compile project(':Algorithms')
}

Services/settings.gradle

rootProject.name = 'Services'
include 'Algorithms'
project(':Algorithms').projectDir = new File(settingsDir, '../Algorithms')

Algorithms/build.gradle

apply plugin: 'java'
apply plugin: 'eclipse'

sourceCompatibility = "1.8";
targetCompatibility = "1.8";

subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse'

    sourceCompatibility = "1.8";
    targetCompatibility = "1.8";

    buildscript {
       dependencies {
          repositories {
            jcenter()
             mavenCentral()
          }
        }
    }

    repositories {
        jcenter()
        mavenCentral()
    }

}
subprojects.each { subproject -> 
   evaluationDependsOn(subproject.path) 
}
jar.dependsOn subprojects.tasks['classes']
jar {
  baseName = 'algorithms'
  subprojects.each { subproject ->
    from subproject.sourceSets.main.output.classesDir
  }
  from files('resources/log4j2.xml')
  from files('resources/application.properties')
}

Algorithms/settings.gradle

rootProject.name = 'Algorithms'
include ':SubModuleCore', ':SubModuleOne', ':SubModuleTwo'

I tried several solutions from SO, still not succeeded. Somebody please help me, I got stuck badly here. It seems I am very close to this, but don't know what is missing!

Thanks

User
  • 4,023
  • 4
  • 37
  • 63

1 Answers1

1

You can use the includeBuild feature.

Declare the included build in Services/settings.gradle

rootProject.name='Services'

includeBuild '../Algorithms'

and then express the dependency using

compile "${project.group}:${project.name}"

where project group and name the one from the Algorithms project.

Baptiste Mesta
  • 579
  • 4
  • 8
  • Settings file 'C:\Workspace\Services\settings.gradle' line: 21 A problem occurred evaluating settings 'Services'. Project with path 'Algorithms' could not be found. org.gradle.tooling.BuildException: Could not run build action using Gradle distribution – User Jul 26 '18 at 12:54
  • weird, can you share your project on github? – Baptiste Mesta Jul 26 '18 at 13:12
  • My fault! Your solution is 100% working, as expected. Thank you so much. I want one more favor, can you please tell me whether it is a good practice whatever I'm doing or it is not natural? I mean Can I do like this for a web application? – User Jul 26 '18 at 19:25
  • I think if your 2 projects stays in the same place (e.g. same git repository), it is easier to have a build.gradle at the root. This way, you will not have to do the includeBuild. also the part where you make the jar task depends on classes is weird, it is best to keep using normal conventions. read this for best practices: https://docs.gradle.org/current/userguide/organizing_gradle_projects.html – Baptiste Mesta Jul 27 '18 at 14:34