java - ejecutar - Integrar el generador de Ant en Eclipse: rutas relativas para actualizar el conjunto de trabajo del ámbito

compilacion con ant

Question

Esta pregunta es similar a Integrar el constructor Ant en Eclipse: error "La variable hace referencia a la selección vacía" , pero solicita algo diferente.

En mi proyecto JDT de Eclipse, tengo algunas tareas ant que quiero ejecutar antes de la compilación, así que agregué un constructor de ant a mi configuración del constructor de Eclipse. Ahora quiero configurar las dos opciones "actualizar recursos al finalizar" y "grupo de trabajo de recursos relevantes" para este constructor para que contengan un directorio específico en mi proyecto.

Ambos me permiten especificar un "conjunto de trabajo" con este dialogue . El problema es que esto pondrá las rutas en el archivo de configuración del constructor de Eclipse que son relevantes para el área de trabajo y, por lo tanto, las rutas incluirán los nombres de los proyectos.

El problema es que todo el proyecto se gestiona en un repositorio de subversion. La configuración de Eclipse es parte del repositorio, y otros usuarios lo comprueban con diferentes diseños de sistemas de archivos y posiblemente con diferentes nombres de proyectos de Eclipse. Por ejemplo, normalmente tengo varias copias de trabajo del mismo proyecto en mi área de trabajo de Eclipse, cada una con un nombre de proyecto diferente.

Por eso busco una forma de especificar un conjunto de trabajo en Eclipse en relación con el directorio del proyecto (no el directorio del área de trabajo), o alguna otra manera de definir el alcance de actualización de un constructor de manera que incluya un solo directorio en mi proyecto .

Estoy usando Eclipse 3.7 (Indigo).

Si configuro el conjunto de trabajo en el diálogo y luego miro en el archivo de configuración, la siguiente cadena es el valor de la opción ATTR_REFRESH_SCOPE :

${working_set:
<?xml version="1.0" encoding="UTF-8"?>

<resources>

<item path="/MyProject" type="4"/>

</resources>}

Desinfectado esto se ve como:

${working_set:
  <?xml version="1.0" encoding="UTF-8"?>
  <resources><item path="/MyProject/lib" type="2"/></resources>
}

Así que quiero sacar la parte "MyProject" de esto. ${build_project:/lib} la solución de la pregunta mencionada anteriormente y reemplacé la ruta con ${build_project:/lib} . Esto no da ningún mensaje de error, pero parece no tener ningún efecto (Eclipse no actualizará el directorio mencionado).

También intenté reemplazar toda la definición del conjunto de trabajo con ${build_project:/lib} , pero ${build_project:/lib} un mensaje de error Unable to restore resource memento .

Sé que podría decirle a Eclipse que actualice todo el proyecto después de ejecutar el generador, pero esto no es lo que quiero (es bastante lento). También para la opción de configuración de "recursos relevantes", esto significaría que el constructor se ejecuta innecesariamente después de cada cambio en el proyecto.

Answer 1

¿Qué hay de agregar una carpeta de nivel en el repositorio? Permite agregar el proyecto en una carpeta en el repositorio. de modo que cada vez que se retira el proyecto, se crea una carpeta con el nombre del proyecto.
Actualmente si está checkout proyecto en la carpeta workspace1. Debe verse como

workspace_1/lib

Si agrega un nivel de carpeta en el repositorio, es decir, el nombre del proyecto (por ejemplo, MyProject aquí), todos los que revisen el proyecto obtendrán el mismo nombre de proyecto. y varias copias del proyecto se verán como

workspace_1/MyProject/lib
workspace_2/MyProject/lib

De esta manera, puede crear múltiples copias del proyecto siempre con el mismo nombre de proyecto y su script puede aprovechar esta singularidad del nombre del proyecto siempre.

Answer 2

Desafortunadamente, Eclipse no es bueno con los directorios relativos.

Rutas relativas en Eclipse

Sin embargo puedes hacer lo siguiente:

• Crear un nuevo espacio de trabajo.
• Importe archivos desde una ubicación conocida que será la misma en todas las máquinas.
• Configure todo dentro de ese directorio conocido.
• Proporcione el espacio de trabajo y las instrucciones de configuración a otros desarrolladores para que usen este mismo ''directorio conocido''.

Usted podría tener algo como

C:/YourKnownDir/
    /workspace/
    /src/
    /build/

e inicie eclipse con un archivo por lotes:

start %ECLIPSE_DIR%/eclipse.exe -data ./workspace

Si va a incluir archivos .project en SVN, realmente debería haber una ruta completa predeterminada. P.EJ:

C:/svn

Espero que eso ayude, pero no conozco ninguna otra forma de abordar este problema.

Answer 3

En una situación similar, he elegido actualizar "El proyecto que contiene el recurso seleccionado" (como ya dijo, no depende del nombre del proyecto) y marcarlo con "Recurso derivado" en la mayor cantidad de carpetas posible (Propiedades de la carpeta -> Recurso -> casilla de verificación "Derivado"). Eclipse actualizará los recursos derivados, pero no intentará validar / reconstruir / etc.

Answer 4

Enfoque completamente diferente:

Creo que las limitaciones de los archivos de configuración de Eclipse compartidos (es decir, los archivos de configuración comprometidos con SVN) son bastante grandes; algunas personas prefieren tener sus bibliotecas dependientes como fuente en el disco, otras prefieren las referencias JAR; Los nombres de proyectos de cada usuario y las ubicaciones relativas al espacio de trabajo son diferentes, y así sucesivamente. Y como vio, muchas opciones son relativas a la ubicación del proyecto (es decir, no se puede referir a otros proyectos) o la ubicación del área de trabajo.

Como, por lo general, tengo los archivos de compilación de Maven de todos modos, uso el complemento maven-eclipse-plugin para generar archivos de configuración de Eclipse. Hay varias opciones para elegir en el tiempo de ejecución, y casi todo se puede personalizar en el archivo de compilación (y si no, simplemente conecte un complemento a ese complemento que hace lo que usted quiere, y envíelo con su compilación. Maven lo compilará automáticamente. complemento si es necesario para los usuarios que lo utilizan). Y también se comparten algunas configuraciones más abstractas entre los complementos, por lo que si alguien insiste en usar Netbeans en lugar de Eclipse, al menos obtendrá un proyecto configurado de forma rudimentaria (dependencias, versiones de JRE, conjuntos de caracteres, etc.) sin que yo haya usado ni siquiera Netbeans configurados.

Efecto secundario positivo: al agregar o actualizar una dependencia de biblioteca, solo se necesita actualizar un lugar (Maven POM), el resto se puede regenerar fácilmente.

Estoy seguro de que este no es el enfoque de todos (especialmente si usa Eclipse no solo para el desarrollo, sino también para construir sus artefactos finales, usar otro sistema de compilación puede parecer excesivo).