0. Descripción del problema
Cuando se empaqueta el proyecto, se encuentra que la ejecución de maven install informará un error: no se puede encontrar el símbolo
[ERROR] /Library/project/work/fantu_java/digitalenterprise_business/bladex-biz/blade-service-api/blade-fleet-basic-api/src/main/java/org/springblade/fleetbasic/feign/IBasicGoldMedalDriverAreaFeign.java:[18,38] 找不到符号
符号: 变量 APPLICATION_FLEET_BASIC_PROVIDER_NAME
位置: 接口 org.springblade.common.constant.LauncherConstant
[ERROR] /Library/project/work/fantu_java/digitalenterprise_business/bladex-biz/blade-service-api/blade-fleet-basic-api/src/main/java/org/springblade/fleetbasic/feign/IBasicFileFeign.java:[20,38] 找不到符号
符号: 变量 APPLICATION_FLEET_BASIC_PROVIDER_NAME
位置: 接口 org.springblade.common.constant.LauncherConstant
1. Soluciones
En primer lugar, debemos aclarar las posibles razones de este problema:
- El formato de codificación del proyecto no es uniforme
- La versión de JDK utilizada por la codificación del proyecto es inconsistente
- La dependencia de pom no se agrega o no se puede leer, que generalmente es el problema de los números de versión inconsistentes
- Los errores de la herramienta de desarrollo generalmente se resuelven reiniciando o actualizando la versión
La primera razón por la que descarté es el problema de la dependencia pom, porque se han agregado las dependencias correspondientes al proyecto, y es normal que se ejecute en idea, es decir, maven install informará un error
En segundo lugar comprobé que la versión jdk del proyecto es la 1.8, por lo que también se descarta el segundo motivo
Así que traté de especificar el formato de codificación en el pom nuevamente, pero aún así reportó un error después de reinstalar.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
Descubrí que no podía pasar por aquí, así que sospeché que era un problema con el entorno local, así que lo instalé nuevamente después de reiniciar. Encontrado todavía mal. Intente dejar que otros colegas maven instalen, esta vez hay un fenómeno más mágico, algunos colegas pueden instalar normalmente y algunos colegas informan el mismo error que yo.
Cuando ves esto, ¿puedes pensar en qué lo causó?
2. Solución Final
De hecho, a veces necesitamos ver la esencia de resolver problemas y fortalecer nuestro conocimiento. Al igual que esta pregunta, las razones que aprendí son las cuatro mencionadas anteriormente, y he buscado información relevante, y solo hay estas cuatro.
Y algunos colegas pueden empacar y otros no, lo que significa que no es un problema del medio ambiente. Así que volví a verificar las dependencias de pom, centrándome en el paquete jar donde se encuentra la clase de interfaz LauncherConstant, que se encuentra en nuestro módulo común personalizado. Cuando verifiqué dos veces el pom de este común encontré el problema
El método de empaquetado en commons, no sé qué colega lo configuró como pom, lo que lleva al hecho de que commons no se ha empaquetado en jar, por lo que no se puede hacer referencia a él. Algunos colegas pueden empaquetar normalmente porque el módulo de bienes comunes no se ha reinstalado y todavía hay paquetes jar del módulo de bienes comunes en el repositorio maven local.
La solución también es muy simple, es decir, cambiar el paquete a frasco o eliminar esta etiqueta directamente, porque el método de empaque predeterminado es el frasco si el método de empaque no se completa en el pom
<packaging>jar</packaging>
También nos recuerda que debemos prestar atención a los detalles en el desarrollo del proyecto.Si algunos pequeños puntos de conocimiento no se captan con firmeza, es probable que causen problemas que son difíciles de solucionar.