Как я могу избежать использования моего собственного имени в идентификаторах, пакетах или пространствах имен проектов с открытым исходным кодом, которые я создаю?

15

Я много занимаюсь разработкой в ​​свое время. Эти проекты, над которыми я работаю, предназначены только для развлечения и обучения (пока). Я обычно занимаюсь разработкой Java с Maven, но я также знаю, что увлекаюсь .NET и Python. Все проекты, над которыми я работаю, используют лицензии с открытым исходным кодом, хотя большинство из них не включены ни в какие общедоступные репозитории кода.

Разработка Java / Maven требует, чтобы я использовал уникальную groupId(например, «com.mydomain») и уникальную package(каталог) структуру, обычно содержащую в groupIdто время, как разработка .NET поощряет уникальность, namespacesв которой я использую соглашения, аналогичные packageконцепции Java . Чтобы гарантировать уникальность, я обычно просто использую одно из своих доменных имен с переставленными частями (например, «ca.jessewebb»); Я считаю, что это очень распространенная практика.

Я нахожусь на начальных этапах создания нового проекта Java / Maven с открытым исходным кодом (назовем его «newproj»), и я хотел бы разместить его на GitHub. Мое имя пользователя на GitHub является «jessewebb» , так что это даст ему URL , как: https://github.com/jessewebb/newproj. Я не хочу беспокоиться о регистрации доменного имени "newproj.com", поэтому я решил использовать "ca.jessewebb" и "ca.jessewebb.newproj" в качестве groupIdи package, соответственно.

Мне пришло в голову, что присутствие моей личной личности в коде и как части дома проекта (в URL GitHub), вероятно, заставит потенциального участника дважды подумать о том, чтобы принять участие в моем проекте. Это проблема, я не хочу, чтобы это был мой проект. Я бы предпочел, если бы я мог вместо этого передать сообщение, что я не являюсь владельцем проекта. Теперь, честно говоря, это действительно не так уж важно, потому что я сомневаюсь, что мои проекты привлекут большое участие сообщества, но я также считаю это еще большей причиной, чтобы избежать какой-либо возможности удержать потенциальных участников.

В качестве другого примера я создал проект Google Code несколько лет назад (назовем его «oldproj»). Когда я создавал проект, я знал, что собираюсь разместить его в Google Code, поэтому я использовал groupIdимя пакета и com.googlecode.oldproj, которое противоположно имени домена по умолчанию, которое Google Code предоставляет каждому новому проекту. Это оказалось не очень хорошей идеей; Примерно через год я переместил код в другое хранилище и мне пришлось переименовать эти идентификаторы (ну, у меня не былоно ...). В то время у меня не было никаких доменных имен, и в итоге я купил доменное имя «oldproj.com» и использовал его. Мне понравилось это, потому что это дало проекту собственную идентичность, и я не везде отмечал свое имя в коде. Я мог бы так же легко зарегистрировать доменное имя «jessewebb.ca» и использовать «ca.jessewebb.oldproj» в качестве имени пакета, но я этого не сделал, потому что тогда у меня были те же проблемы.

Итак, мой вопрос ...

Как я могу избежать использования моих собственных (доменных) имен при создании проектов с открытым исходным кодом при сохранении уникальности пакетов / пространств имен?

По мере того, как проекты набирают обороты, имеет смысл регистрировать доменные имена, но это кажется глупостью и пустой тратой денег, чтобы сделать это раньше. Я понимаю, что на самом деле мне не нужно владеть доменным именем, чтобы использовать его в коде, но это неправильно и может привести к тому, что скваттер вырвет его из-под вас. Что другие люди делают с этой дилеммой? Существуют ли примеры популярных (широко используемых, крупных сообществ и т. Д.) Проектов с открытым исходным кодом, которые содержат идентификационные данные оригинального разработчика как часть его собственных идентификаторов?

Джесси Уэбб
источник
2
Ого, довольно длинный, но все же хороший вопрос!
Марсель
1
Использовать UUID в ваших пакетах / пространствах имен? ;-)
Jeroen

Ответы:

5

В своих проектах я даю им имя, но не обязательно домен. Таким образом, мои имена пакетов (и пространства имен) обычно просто "имя_проекта.libraryname", независимо от того, где размещен код.

Я привык к .NET, где это происходит достаточно свободно.

завивать волосы щипцами
источник
Я думаю, что это хорошее решение, когда у меня нет или (сразу) требуется домен, зарегистрированный для проекта. Я мог бы даже сделать это, когда у меня есть домен. Это даже помогло бы убедиться, что я использую уникальные имена проектов, что никогда не является плохой вещью. Я, вероятно, скоро приму этот ответ, если только не придут лучшие. Благодарность!
Джесси Уэбб
Да, программисты .NET делают это, но это не очень хорошая идея. Если название проекта - выдуманное слово, оно может сработать, но я бы хотел, чтобы у меня был доллар за каждый проект «Загрузчик» или «Браузер», который я видел.
Росс Паттерсон
1
Я начал использовать эту стратегию для всех своих проектов. Я придумываю уникальное имя для проектов, почти кодовое имя (простите за каламбур), и использую его для своих пакетов / пространств имен. Это избавляет меня от необходимости беспокоиться о доменных именах, по крайней мере, пока не наступит время, когда я захочу.
Джесси Уэбб
2

Я не могу вспомнить, где я видел это, но я видел, что он предложил использовать такую ​​структуру:

YourIdentifier.YourProduct.YourComponent

YourIdentifier может быть чем-то вроде принадлежащего вам домена, вашего (довольно уникального) интернет-псевдонима и т. Д. И т. Д. Имя компонента не используется для «основного» кода вашего продукта. Например, у меня есть небольшая инфраструктура MVC с именем BarelyMVC, поэтому у меня есть такие пространства имен:

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

и т. д. и т. д. Ваш сетевой псевдоним в большинстве случаев достаточно уникален, чтобы избежать конфликтов между другими разработчиками

Если вы боитесь использовать собственный онлайн-псевдоним, создайте «ярлык» для себя. Он не должен быть официально зарегистрирован как компания или что-либо (или даже домен). Например, популярная Json.Netбиблиотека использует пространство имен Newtonsoft.Json. Это очевидно основано на фамилии авторов "ньютон", но я не думаю, что кто-то действительно заботится об этом. И если у вас есть официально зарегистрированная компания, то вы, конечно, можете это использовать. Например, большинство общедоступных API, созданных моей компанией, имеют пространства имен, начинающиеся с PreEmptiveSolutionsназвания компании.

Earlz
источник
1
Очень часто встречается в мире .NET, где вещь обратного доменного имени никогда не завоевывала популярность. И пока «YourIdentifier» серьезно уникален, он работает. Но даже Newtonsoft уникальна лишь случайно - Джеймс Ньютон-Кинг фактически не управляет такой компанией, и его торговая марка существовала бы только в Новой Зеландии, если бы он это сделал.
Росс Паттерсон
1

Нет правила, что имена пакетов Java или пространства имен .NET являются именами доменов. Нет даже требования, чтобы они были уникальными, хотя это, безусловно, хорошая идея. Я действительно думаю, что вы были правы в использовании com.googlecode.oldproj, и на вашем месте я бы не переключился, com.oldprojесли бы не попытался получить рекламу нового доменного имени.

Росс Паттерсон
источник
Я понимаю, что нет правила, по которому вы должны использовать доменные имена, но я думаю, что это очень распространенная практика, по крайней мере, в мире Java и .NET, просто потому, что она помогает обеспечить уникальность. Кроме того, вы сказали, что думаете, что я был прав com.googlecode.oldproj, почему вы думаете, что это хорошая идея? Оглядываясь назад, я думал, что глупо привязывать код к хостинг-провайдеру.
Джесси Уэбб
1
Дело не в том, что это связывает вас с каким-то хостинг-провайдером, а в том, что это условно-уникальный идентификатор, свойственный этому проекту. Который все "com.jesseweb.oldproj", технически. Так как вы не хотели, чтобы ваше имя было прикреплено к нему, это было хорошее решение. Пакеты Java и пространства имен .NET не должны быть указателями, направляющими вас на сайт загрузки и т. Д. , А просто идентификатором, который по соглашению является уникальным.
Росс Паттерсон