gradle multi project example
1.0.0
El trozo genérico único/multiproyecto creemos que representa el mejor gradle que tiene para ofrecer.
| Nombre | Preguntas | CI | Codecov | Documento | Liberar |
|---|---|---|---|---|---|
| usos comunes |
Se puede obtener de artefactorios/bintray así:
<dependency>
<groupId>com.aries</groupId>
<artifactId>project-name</artifactId>
<version>X.Y.Z</version>
<classifier>sources|tests|docs|all</classifier> (Optional)
</dependency>
Para los proyectos independientes, puede crear el directorio típico de src/main/<language> en la raíz de este proyecto y las cosas funcionarán como se esperaba. En este modelo está bien eliminar el directorio projects una vez que tenga las cosas en su lugar.
Para los proyectos múltiples, debe crear/colocar dichos proyectos en el directorio projects . Colocar los proyectos aquí los hará construir automáticamente como parte de esta construcción de proyectos múltiples.
Para cualquier caso, es posible que deba girar las perillas un poco dentro del gradle/projects.gradle Archivo de adoración dependiendo del tipo de proyecto que desee crear.
La estructura del paquete de su proyecto debe comenzar con su group de Gradle seguido del nombre de los proyectos. Como parte de la construcción de su proyecto, escanearemos a través de sus fuentes y nos aseguraremos de que se cumpla este patrón. Por ejemplo: si su grupo es com.github.gradle y está agregando un proyecto llamado calamari entonces la estructura del paquete de ese proyecto debe verse como com/github/gradle/calamari .
Si está agregando un proyecto cuyo nombre contiene caracteres no alfabéticos, esos caracteres se convertirán en aberturas hacia adelante cuando ejecute la verificación mencionada anteriormente. Por ejemplo: si su proyecto se llama tuna-casserole , su estructura de paquete se vería como `com/github/gradle/tuna/cacerola.
JACOCO : es una herramienta que asegura que el nuevo código tenga una cobertura de prueba adecuada.
ErrorPraon : es una herramienta de análisis estático para Java que captura errores de programación comunes en el tiempo de compilación y sugiere correcciones.
CheckStyle : es una herramienta de desarrollo que obliga a los programadores a escribir código que se adhiere a un estándar común.
PMD : es un analizador de código fuente que encuentra fallas de programación comunes como variables no utilizadas, bloques de captura vacíos, creación innecesaria de objetos, etc.
FindBugs : es una herramienta que utiliza un análisis estático para buscar y detectar posibles errores en el código Java.
Actualmente definimos junit y assertj como dependencias testCompile para que todos los proyectos los usen. Intentemos centrarnos en usar solo estos, y si es necesario traer y usar algo más, primero tengamos una discusión antes de que vayamos a agregar n número de dependencias a este proyecto y rompa el aspecto y la sensación que estamos tratando de establecer.
El código se considera hecho cuando se han aprobado todas las verificaciones, el código se puede compilar y, al menos, se han agregado pruebas de unidad y integración para abordar el nuevo código.
