Gradle-7 (11) Gradle Multiproyecto (4). ERRORES que te machacan!!

0. Antes de importar cualquier proyecto hijo al proyecto padre, hay que hacer una copia de seguridad!!, pues revertir los cambios es muy difícil, por culpa de la caché y otros cambios inesperados que hace Eclipse.

1. No se compilan los proyectos simples por un error de compilación de un proyecto que depende de estos.

Si borramos todos los jars del directorio al que volcamos los jars (para aseguranos que se vuelvan a generar correctamente), y existe un proyecto "grande" que utiliza otros proyectos, entonces no genera los jars iniciales si hay un error de compilación del proyecto "grande", por tanto, hasta que no se depuren los errores, no se volverá a generar los "jars".

Cuidado cuando importemos un proyecto

2. DESAPARECE el proyecto padre de la "Gradle Tasks" y aparecen los hijos con error. 

Suele suceder en alguno de estos casos:

a. Copiamos más de un proyecto hijo a la vez a la carpeta del padre. Es preferible solo copiar una carpeta, arreglar su "build.gradle" (del hijo), y añadir el proyecto a "settings.gradle" del padre ese proyecto. 

b. Cuando en el "build.gradle" del hijo no hemos dado bien el nombre de algún proyecto del que depende en el apartado de "dependencies", en este ejemplo, el proyecto que hace referencia no existe, pues el correcto es "A004-PDF" y no "A004-PDFS"

dependencies {
    // Use JUnit Jupiter for testing.
    testImplementation libs.junit.jupiter
        
    api(project(path: ':A001-WS_Shdw', configuration: 'shadow'))
    api(project(":A004-PDFS"))
}  

c. Cambiar los guiones "-" por puntos "." a la hora de referenciar las librerias que se han definido en el fichero "settings.gradle" del proyecto padre. En el fichero "settings.gradle" del proyecto padre, podemos definir las dependencias que utilizamos, y así tener un mayor control de las versiones que se utilizan aquí mostramos un ejemplo real de dicho fichero

rootProject.name = 'AllProjects'

include('A000-Basic', 'A002-Jackson','A003-Excel', 'A004-PDF', 'A006-CMIS' )
        
dependencyResolutionManagement {
    versionCatalogs {
        libs {
            //library('commons-lang3', 'org.apache.commons', 'commons-lang3').version {
            //    strictly '[3.8, 4.0['
            //    prefer '3.9'
            //}
            library('junit-jupiter',           'org.junit.jupiter:junit-jupiter:5.7.2')
            library('lombok',                  'org.projectlombok:lombok:1.18.20')
                       
            library('commons-beanutils',        'commons-beanutils:commons-beanutils:1.9.4')
            library('commons-io',               'commons-io:commons-io:2.11.0')
            library('commons-lang3',            'org.apache.commons:commons-lang3:3.12.0')
            library('commons-codec',            'commons-codec:commons-codec:1.15')
        }
    }
}

Por ejemplo para la librería con alias  "commons-io" , para indicarla en el fichero "build.gradle" del proyecto que la utiliza debemos indicar la referencia "commons.io" (cambiando el guión "-" por el punto ".") en la sección de "dependencies"

dependencies {
    // Use JUnit Jupiter for testing.
    testImplementation libs.junit.jupiter
    api libs.commons-io //mal hay un guión en la referencia

    api libs.commons.io //bien, se hs sustituido el guión por un punto

}

d. Cuando se borra un comentario al inicio de la dependencia, hay que comprobar que no haya caracteres residuales. Por ejemplo al borrar el símbolo de comentario "//" y no borramos "--> otros caracteres"  entonces nos desaparece el proyecto de la "Gradle Tasks"

dependencies {
    // Use JUnit Jupiter for testing.
    testImplementation libs.junit.jupiter
        
    
    //api(project(":A000-Basic"))  --> otros caracteres

    api(project(":A000-Basic"))  --> otros caracteres

    api(project(":A004-PDF"))
}  

3. Test que dan "Entry properties/alba.properties is a duplicate but no duplicate handling strategy has been set"

Parece ser que es un error de gradle, veamos una clase en src/test/java que lo genera. Una referencia a unas propiedades que se encuentran en src/main/resources/properties, provoca el error

@Test void isnullClassLoaderReturnFalse() throws Exception {
	Properties props = PropertyUtilsEdu.getProperties(ExecutionTypeEnum.NO_JAR, "alba");
	assertTrue(props!=null, "1. Properties are null");
}

Para solucionar esto, se ha añadido la línea

duplicatestrategy = DuplicateStrategy.EXCLUDE dentro de la tarea JAR

jar {
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
    manifest {
        //attributes 'Main-Class': 'com.foo.bar.MainClass'
        attributes(
         	'Main-Class': 'Execute',
         	'Class-Path': configurations.runtimeClasspath.files.collect { 'lib/'+it.getName() }.join(' ')
        ) 
    }
    
    from {
   		sourceSets.main.allSource  //Include java sources
   	}
    
}

4. Resultados distintos al ejecutar test en un "terminal" que con la ventana "Gradle Tasks" de Eclipse.

Parece ser que la opción "build" de la carpeta "build" de la ventana "Gradle Tasks", a parte de hacer un build, realiza los tests.

Para ejecutar los tests des de un terminal, ejecutamos "./gradlew clean test". Si en eclipse, los test van bien, pero no en el terminal, hay que comprobar la versión de java que toma el terminal con "java -version".

En mi caso, en Eclipse tenia java 17 y en el terminal la versión 13. Para solucionarlo, hay que consultar este link de askubuntu , y he hecho

sudo nano /etc/enviroment

y el fichero ha quedado así:

JAVA_HOME=/home/ximo/MyPrograms/jdk-17.0.2+8.OpenJ9/bin
PATH=/home/ximo/MyPrograms/jdk-17.0.2+8.OpenJ9/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Y parece  ser que los resultados son los mismos.