2011-10-25 8 views
11

¿Existe una regla general sobre cómo nombrar espacios de nombres de paquetes para proyectos de código abierto sin dominio propio?Espacio de nombres de paquetes Java para proyectos sin dominio propio

Los espacios de nombre deben ser únicos, por lo que se eligieron dominios para encargarse de eso, pero al final no importa, siempre que sean únicos.

Ahora, si tengo un proyecto que solamente está alojado en GitHub, es bien tomar

com.github.username.projectname 

o está mal visto que en lugar, porque el uso de un dominio que realmente no posee?

+0

No creo que sea un problema. Los proyectos Apache y Codehaus parecen hacerlo de esa manera. –

+0

el nombre de su paquete no debe ser único, sino que debe ser algo que usted posea. supongamos que tiene un correo electrónico [email protected], puede usar el paquete como com.email.name, como si ocurriera algún conflicto, debe ganar porque es el propietario del correo electrónico. En resumen, el nombre de tu paquete debe ser único y deberías poder probar que es tuyo –

Respuesta

8

Hay un número de com.google.code y proyectos con sourceforge en el nombre del paquete, por lo que el espacio de nombres tiene mucho precedente.

+2

Será divertido cuando Google cierre sus actividades y todos esos proyectos se muden a otro lugar ... como Lycos. – Perception

+5

@Perception No realmente rompe cualquier cosa, sin embargo. No es como, por ejemplo, mover todos los sitios de Sun a Oracle y hacer que las especificaciones y las publicaciones en el foro sean prácticamente imposibles de encontrar. –

3

Está bien. En general, elija algo "probable" como único y específico para el proyecto.

Los paquetes generalmente solo colisionan cuando son una biblioteca diseñada para el consumo; si los paquetes se usan solo dentro del proyecto, importa mucho menos.

+0

La preocupación es más acerca de usar el nombre de dominio de otra persona en lugar de nombrar las colisiones, creo. –

+1

@G_H De ahí la primera oración de la respuesta. –

8

En su ejemplo com.github no tiene una relación directa con su código. Dónde está almacenado este código (también conocido como alojado) no importa y podría cambiar en el futuro. Por tanto, propongo un nombre específico puramente proyecto como

org.projectname 

o incluso

projectname 

desde un nombre de paquete no tiene que ser un nombre de dominio.

Ah, dicho sea de paso: encontrará la prioridad para casi todo y todo lo relacionado con las convenciones de nombres, no solo para los nombres de los paquetes de Java. Pero drásticamente hablando: en la historia también puedes encontrar precedencia para cada tipo de asesinato. ¿Eso de alguna manera lo hace aceptable solo porque alguien más lo haya hecho antes? No lo creo.

+0

Probablemente evitaría org.projectname; la premisa de la pregunta pregunta sobre "no tener un nombre de dominio". Dado que "projectname.org" no es propiedad del proyecto, parece bastante engañoso y podría terminar siendo un desagradable campo de batalla legal o una posible fuente de confusión. – user314104

+0

supongamos que alguien más posee el dominio projectname.org, él puede luchar con usted legalmente –

Cuestiones relacionadas