2010-05-22 12 views
8

En Java si empaqueta los archivos de código fuente (.java) en el contenedor junto con las clases ( .class), la mayoría de los IDE como eclipse mostrarán los comentarios de javadoc para la finalización del código.¿Hay alguna desventaja al poner el código API en un JAR junto con las clases?

IIRC hay algunos proyectos de código abierto que hacen esto como JMock.

Digamos que he separado limpiamente mi código API del código de implementación para que tenga algo como myproject-api.jar y myproject-impl.jar ¿Hay alguna razón por la que no debería poner el código fuente en myproject-api? .jar?

¿Por rendimiento? ¿Tamaño?

¿Por qué otros proyectos no lo hacen?

EDITAR: Aparte del problema de descarga de Maven, ¿afectará cualquier cosa poner mis fuentes en el jar de clases para admitir tantos desarrolladores como sea posible (maven o no)?

+0

Tuve una secuencia de comandos groovy que asociaría los tarros de código con los jar de fuentes de maven al editar el .classpath de Eclipse. No uso el plugin Maven pero tengo que imaginar que hace esta asociación automáticamente. –

Respuesta

6

En general, debido a razones de distribución:

si mantiene los binarios y fuentes separadas, se puede descargar sólo lo que necesita.
Por ejemplo:

  • myproject-api.jar y myproject-impl.jar
  • myproject-api-src.jar y myproject-impl-src.jar
  • myproject-api-docs.zip y myproject-impl-docs.zip

Ahora, m2eclipse - Maven for Eclipse puede download sources automáticamente así

mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true 

Ahora, también puede generate the right pom evitar la distribución de la fuente o javadoc jar cuando alguien declara una dependencia en su jar.
La OP comentarios:

tampoco pueden imaginar el tamaño de descarga siendo un problema (me refiero a que es el año 2010 un par de 100k no debería ser un problema).

Bueno, en realidad (es decir, "el tamaño) es un problema.
Maven sufre ya desde el '' síndrome de la descarga de la mitad de la Internet en la primera construcción.
Si eso descargas también fuentes y/o javadocs , que comienza a ser muy tedioso

Además, el aspecto de "distribución" incluye el despliegue :.. en un webapp server, there is no real advantage to deploy a jar with sources in it

por último, si realmente necesita para asociar fuentes con binarios, esto SO question on Maven could help.

+0

Claro que puedo ver eso. Pero es un dolor en el trasero para luego asociar myproject-api.jar myproject-api-src.jar para que pueda ver el javadoc a través de la finalización del código. ¿El complemento Maven Eclipse hace esto? –

+0

Tampoco me puedo imaginar que el tamaño de la descarga sea un problema (me refiero a que es 2010 un par de 100k no debería ser un problema). Así que crea las jarras separadas, pero haz que * -api.jar también tenga la fuente. –

+0

@ Adam: acaba de completar mi respuesta. – VonC

1

Usando experto, conecte las fuentes de forma automática la siguiente manera:

http://maven.apache.org/plugins/maven-source-plugin/usage.html

y los javadocs como este:

http://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html

De esta manera serán recogidos automáticamente por

mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true 

o por m2eclipse

+0

Sí, pensé que Maven lo hizo porque podría haber jurado que lo hice la última vez que lo usé. El único problema es que muchas compañías/grupos (tristemente incluido el mío) no usan Maven pero usan Apache Ivy o simplemente tienen su propio repositorio de archivos jar. –

+0

realmente? No he tenido clientes no maven en aproximadamente 3 años. pero como la hiedra es "compatible con Maven", debe haber una manera de imitar este comportamiento en ivy –

+0

Debe trabajar con algunas personas inteligentes :) Sí, ojalá fuera ese el caso para mí, pero tanto nuestros clientes/clientes como el código interno utilizan Apache Hormiga. A mí me han gustado las secuencias de comandos Ant debido a la incoherencia de un proyecto a otro. –

Cuestiones relacionadas