¿Cómo puedo evitar usar mi propio nombre en los identificadores, paquetes o espacios de nombres de proyectos de código abierto que creo?


15

Hago mucho desarrollo en mi propio tiempo. Estos proyectos en los que trabajo son solo para divertirse y aprender (hasta ahora). Comúnmente desarrollo Java con Maven, pero también se me conoce por incursionar en .NET y Python. Todos los proyectos en los que trabajo utilizan licencias de código abierto, aunque la mayoría de ellos no se encuentran en ningún repositorio de código público.

El desarrollo de Java / Maven requiere que use una estructura única groupId(por ejemplo, "com.mydomain") y una packageestructura única (directorio), que generalmente contiene el groupIddesarrollo .NET mientras que fomenta un namespacesuso único en convenciones similares al packageconcepto de Java . Para garantizar la unicidad, usualmente solo uso uno de mis nombres de dominio con las partes invertidas (por ejemplo, "ca.jessewebb"); Creo que esta es una práctica muy común.

Estoy en las etapas iniciales de crear un nuevo proyecto Java / Maven de código abierto (llamémoslo "newproj") y me gustaría ponerlo en GitHub. Mi nombre de usuario en GitHub es "jessewebb" por lo que esto le dará una URL como: https://github.com/jessewebb/newproj. No quiero molestarme en registrar el nombre de dominio "newproj.com", así que decidí usar "ca.jessewebb" y "ca.jessewebb.newproj" como groupIdy package, respectivamente.

Se me ocurrió que la presencia de mi identidad personal en el código y como parte de la casa del proyecto (en la URL de GitHub) probablemente hará que un contribuyente potencial piense dos veces antes de involucrarse en mi proyecto. Esto es un problema, no quiero que sea mi proyecto. Preferiría si pudiera, en cambio, transmitir el mensaje de que no soy dueño del proyecto. Ahora, con toda honestidad, realmente no es un gran problema porque dudo que mis proyectos obtengan mucha participación de la comunidad, pero también veo esto como una razón aún más para evitar cualquier posibilidad de disuadir a los posibles contribuyentes.

Para otro ejemplo, creé un proyecto de Google Code hace unos años (llamémoslo "oldproj"). Cuando creé el proyecto, sabía que iba a alojarlo en Google Code, así que utilicé el groupIdnombre del paquete "com.googlecode.oldproj", que es el reverso del nombre de dominio predeterminado que Google Code proporciona en cada nuevo proyecto. Esto resultó ser una idea no tan genial; Un año más tarde, moví el código a un repositorio diferente y tuve que cambiar el nombre de estos identificadores (bueno, no teníaa pero ...). En ese momento, no poseía ningún nombre de dominio y terminé comprando el nombre de dominio "oldproj.com" y lo usé. Me gustó esto porque le dio al proyecto su propia identidad y no estaba estampando mi nombre en el código en todas partes. Podría haber registrado con la misma facilidad el nombre de dominio "jessewebb.ca" y haber usado "ca.jessewebb.oldproj" como el nombre del paquete, pero no lo hice porque tenía las mismas preocupaciones en ese entonces también.

Entonces mi pregunta es ...

¿Cómo puedo evitar usar mis propios nombres (de dominio) al crear proyectos de código abierto y al mismo tiempo mantener la unicidad de los paquetes / espacios de nombres?

A medida que los proyectos ganan más impulso, tiene sentido registrar los nombres de dominio, pero parece una tontería y una pérdida de dinero hacer esto antes. Me doy cuenta de que en realidad no tengo que tener el nombre de dominio para usarlo en el código, pero eso se siente mal y puede hacer que un okupa te lo arrebata mientras tanto. ¿Qué hacen otras personas sobre este dilema? ¿Hay ejemplos de proyectos de código abierto populares (ampliamente utilizados, de gran comunidad, etc.) que contengan la identidad del desarrollador original como parte de sus propios identificadores?


2
Whoa, bastante largo, pero sigue siendo una buena pregunta!
Marcel

1
¿Utiliza un UUID en sus paquetes / espacios de nombres? ;-)
Jeroen

Respuestas:


5

En mis proyectos, les doy un nombre pero no necesariamente un dominio. Por lo tanto, los nombres de mis paquetes (y los espacios de nombres) generalmente son solo "projectname.libraryname", independientemente de dónde esté alojado el código.

Estoy acostumbrado a .NET donde esto se maneja con bastante libertad.


Creo que esta es una buena solución cuando no tengo o (de inmediato) quiero un dominio registrado para el proyecto. Incluso podría hacer esto cuando tengo un dominio. Incluso ayudaría a asegurarme de que use nombres de proyecto únicos, lo que nunca es malo. Probablemente aceptaré esta respuesta pronto, a menos que surjan otras mejores. ¡Gracias!
Jesse Webb

Sí, los programadores .NET hacen esto, pero no es una buena idea. Si el nombre del proyecto es una palabra inventada, puede funcionar bien, pero desearía tener un dólar por cada proyecto de "Descargador" o "Navegador" que he visto.
Ross Patterson

1
Empecé a usar esta estrategia para todos mis proyectos. Se me ocurre un nombre único para los proyectos, casi un nombre en clave (perdón por el juego de palabras), y lo uso para mis paquetes / espacios de nombres. Me ahorra tener que preocuparme por los nombres de dominio, al menos hasta que llegue el momento en que quiera uno.
Jesse Webb

2

No recuerdo dónde lo he visto, pero he visto que sugirió usar una estructura como esta:

YourIdentifier.YourProduct.YourComponent

YourIdentifier puede ser algo así como un dominio que posee, su alias de Internet (bastante único), etc. El nombre del componente se deja para el código "central" de su producto. Por ejemplo, tengo un pequeño marco MVC llamado BarelyMVC, así que tengo espacios de nombres como estos en él:

Earlz.BarelyMVC
Earlz.BarelyMVC.Authentication
Earlz.BarelyMVC.Caching

etc. Su alias en línea en la mayoría de los casos es único para evitar conflictos entre otros desarrolladores.

Si tiene miedo de usar su propio alias en línea, cree una "etiqueta" para usted. No tiene que estar registrado formalmente como una empresa ni nada (o incluso un dominio). Por ejemplo, la Json.Netbiblioteca popular usa el espacio de nombres Newtonsoft.Json. Obviamente se basa en el apellido de los autores "newton", pero no creo que a nadie realmente le importe eso. Y si tiene una empresa formal registrada, entonces, por supuesto, puede usarla. La mayoría de las API públicas producidas por mi empresa, por ejemplo, tienen espacios de nombres que comienzan con PreEmptiveSolutionsel nombre de la empresa.


1
Muy común en el mundo .NET, donde la cosa del nombre de dominio hacia atrás realmente nunca se dio cuenta. Y mientras "YourIdentifier" sea realmente único, funciona. Pero incluso Newtonsoft solo es accidentalmente único: James Newton-King en realidad no dirige una compañía así, y su marca registrada solo existiría en Nueva Zelanda si lo hiciera.
Ross Patterson

1

No existe una regla para que los nombres de paquetes Java o los espacios de nombres .NET sean nombres de dominio. Ni siquiera hay un requisito de que sean únicos, aunque sin duda es una buena idea. De hecho, creo que tenías razón para usar com.googlecode.oldproj, y en tu lugar no habría cambiado a com.oldprojmenos que intentara hacer publicidad para el nuevo nombre de dominio.


Me doy cuenta de que no hay una regla para usar los nombres de dominio, pero creo que es una práctica muy común, al menos en el mundo de Java y .NET, solo porque ayuda a garantizar la unicidad. Además, dijiste que creías que era correcto usarlo com.googlecode.oldproj, ¿por qué crees que fue una buena idea? En retrospectiva, pensé que era un poco tonto vincular el código al proveedor de alojamiento.
Jesse Webb

1
El punto no es que lo vincule con algún proveedor de hosting, el punto es que es un identificador único convencional que es peculiar de este proyecto. Que es todo "com.jesseweb.oldproj" es, técnicamente. Entonces, como no querías que tu nombre se adjunte, fue una buena decisión. Se supone que los paquetes Java y los espacios de nombres .NET no son señales que lo dirijan a un sitio de descarga, etc. , solo un identificador que es único por convención.
Ross Patterson
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.