내가 만든 오픈 소스 프로젝트의 식별자, 패키지 또는 네임 스페이스에서 내 이름을 사용하지 않으려면 어떻게해야합니까?


15

나는 내 시간에 많은 발전을합니다. 내가 작업하는이 프로젝트는 모두 재미와 학습을위한 것입니다 (지금까지). 필자는 일반적으로 Maven을 사용하여 Java 개발을 수행하지만 .NET 및 Python에서도 대단한 것으로 알려져 있습니다. 내가 작업하는 모든 프로젝트는 오픈 소스 라이센스를 사용하지만 대부분 공개 코드 리포지토리에는 없습니다.

Java / Maven 개발을 위해서는 고유 한 groupId(예 : "com.mydomain" package) 구조 와 고유 한 (디렉토리) 구조 를 사용해야합니다 . 일반적으로 groupIdwhile .NET 개발 namespaces에는 Java package개념 과 유사한 규칙을 사용 하는 고유 한 .NET 개발이 권장 됩니다. 고유성을 보장하기 위해 보통 도메인 이름 중 하나를 부분이 반전 된 상태로 사용합니다 (예 : "ca.jessewebb"). 나는 이것이 매우 일반적인 관행이라고 믿는다.

저는 새로운 오픈 소스 Java / Maven 프로젝트 ( "newproj"라고 함)를 만드는 초기 단계에 있으며 GitHub에 올려 놓고 싶습니다. GitHub의 사용자 이름은 "jessewebb"이므로 다음과 같은 URL을 제공합니다 https://github.com/jessewebb/newproj. "newproj.com"도메인 이름을 등록하고 싶지 않아서 "ca.jessewebb"및 "ca.jessewebb.newproj"를 각각 groupId및 로 사용하기로 결정했습니다 package.

코드와 프로젝트 홈의 일부 (GitHub URL)에 내 개인 정체성이 존재하면 잠재적 인 기여자가 내 프로젝트에 참여하는 것에 대해 두 번 생각하게 될 가능성이 있습니다. 이것은 문제입니다, 나는 그것이 프로젝트가 되기를 원하지 않습니다 . 대신 프로젝트를 소유하지 않았다는 메시지를 전달할 수 있으면 좋겠습니다. 모든 솔직히 말해서, 내 프로젝트가 많은 지역 사회 참여를 유발할 것이라 의심하기 때문에 그다지 큰 문제는 아닙니다. 그러나 이것은 또한 기여자가 될 수있는 사람들을 막을 가능성을 피할 수있는 더 많은 이유라고 생각합니다.

다른 예로, 몇 년 전에 Google 코드 프로젝트를 만들었습니다 ( "oldproj"라고 함). 프로젝트를 만들 때 Google 코드에서 프로젝트를 호스팅 할 것임을 알았으므로 groupId패키지 이름 인 "com.googlecode.oldproj"를 사용했습니다. 이는 Google 코드가 모든 새 프로젝트를 제공하는 기본 도메인 이름과 반대입니다. 이것은 그리 좋지 않은 아이디어로 판명되었습니다. 년 정도 후, 나는 다른 REPO에 코드를 이동 나는 이러한 식별자의 이름을 변경했다 (물론 나는하지 않았다 하지만 ...). 당시에는 도메인 이름이 없었으며 도메인 이름 "oldproj.com"을 구입하여 사용했습니다. 프로젝트 자체에 정체성을 부여하고 코드에 내 이름을 찍지 않았기 때문에 이것을 좋아했습니다. "jessewebb.ca"도메인 이름을 쉽게 등록하고 "ca.jessewebb.oldproj"를 패키지 이름으로 사용했지만 그 당시에도 같은 문제가 있었기 때문에 그렇게하지 않았습니다.

제 질문은 ...

패키지 / 네임 스페이스의 고유성을 유지하면서 오픈 소스 프로젝트를 만들 때 고유 한 도메인 이름을 사용하지 않으려면 어떻게해야합니까?

프로젝트가 더 많은 추진력을 얻음에 따라 도메인 이름을 등록하는 것이 합리적이지만 초기에이를 수행하는 것은 어리 석고 돈 낭비입니다. 코드에서 도메인 이름을 사용하기 위해 실제로 도메인 이름 을 소유 할 필요는 없지만 잘못된 느낌이 들며 그 동안 스쿼터가 도메인 이름을 빼앗을 수 있습니다. 이 딜레마에 대해 다른 사람들은 무엇을합니까? 고유 한 식별자 (들)의 일부로 원래 개발자의 신원을 포함하는 인기있는 (일반적으로 사용되는 대규모 커뮤니티 등) 오픈 소스 프로젝트의 예가 있습니까?


2
우와, 꽤 길지만 여전히 좋은 질문입니다!
Marcel

1
패키지 / 네임 스페이스에서 UUID를 사용 하시겠습니까? ;-)
Jeroen 2013

답변:


5

내 프로젝트에서 나는 그들에게 이름을 주지만 반드시 도메인은 아니다. 따라서 패키지 이름과 네임 스페이스는 일반적으로 코드가 호스팅되는 위치에 관계없이 "projectname.libraryname"입니다.

나는 이것이 매우 자유롭게 다루어지는 .NET에 익숙합니다.


프로젝트에 도메인을 등록하지 않았거나 (즉시) 등록하고 싶을 때 이것이 좋은 해결책이라고 생각합니다. 도메인이 있으면이 작업을 수행 할 수도 있습니다. 심지어 고유 한 프로젝트 이름을 사용하는 데 도움이 될 것입니다. 더 나은 답변이 나오지 않는 한이 답변을 곧 받아 들일 것입니다. 감사!
Jesse Webb

예, .NET 프로그래머는 이것을하지만 좋은 생각은 아닙니다. 프로젝트 이름이 완성 된 단어라면 문제가 해결 될 수 있지만, 내가 본 모든 "Downloader"또는 "Browser"프로젝트에 대해 1 달러가 필요합니다.
로스 패터슨

1
모든 프로젝트에이 전략을 사용하기 시작했습니다. 나는 프로젝트의 고유 한 이름, 거의 코드 이름 (펑크를 용서함)을 생각해 내 패키지 / 네임 스페이스에 사용합니다. 최소한 도메인 이름이 필요할 때까지 도메인 이름에 대해 걱정할 필요가 없습니다.
Jesse Webb

2

내가 본 곳을 기억할 수 없지만 다음과 같은 구조를 사용하는 것이 좋습니다.

YourIdentifier.YourProduct.YourComponent

YourIdentifier는 소유 한 도메인, (고유 한) 인터넷 별명 등과 같은 것일 수 있습니다. 구성 요소 이름은 제품의 "핵심"코드에 대해 생략되어 있습니다. 예를 들어 BarelyMVC라는 작은 MVC 프레임 워크가 있으므로 다음과 같은 네임 스페이스가 있습니다.

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

대부분의 경우 온라인 별칭은 다른 개발자 간의 충돌을 피하기 위해 독특합니다.

자신의 온라인 별칭을 사용하기를 두려워하는 경우 "라벨"을 직접 만드십시오. 회사 나 다른 것 (또는 도메인)으로 공식적으로 등록 할 필요는 없습니다. 예를 들어, 인기있는 Json.Net라이브러리는 네임 스페이스를 사용합니다 Newtonsoft.Json. 분명히 저자의 성 "newton"에 기반을두고 있지만, 아무도 그것에 대해 신경 쓰지 않는다고 생각합니다. 공식 회사가 등록되어 있다면 물론 사용할 수 있습니다. 예를 들어 회사에서 제작 한 대부분의 공개 API PreEmptiveSolutions에는 회사 이름 인으로 시작하는 네임 스페이스가 있습니다.


1
.NET 세계에서 매우 흔합니다. 하위 도메인 이름이 실제로 붙 잡히지 않았습니다. "YourIdentifier"가 매우 독창적 인 한 작동합니다. 그러나 Newtonsoft조차도 우연히 독특합니다. James Newton-King은 실제로 그러한 회사를 운영하지 않으며, 상표는 뉴질랜드에서만 존재합니다.
로스 패터슨

1

Java 패키지 이름 또는 .NET 네임 스페이스가 도메인 이름이라는 규칙은 없습니다. 비록 그것이 좋은 생각 임에도 불구하고 그것들이 유일해야한다는 요구 사항조차 없습니다. 나는 실제로 당신이을 사용하는 것이 옳다고 생각 com.googlecode.oldproj하고, 당신의 신발 com.oldproj에 새 도메인 이름에 대한 홍보를 시도하지 않으면 전환하지 않았을 것 입니다.


도메인 이름을 사용해야한다는 규칙은 없지만 적어도 Java 및 .NET 세계에서는 고유성을 보장하는 데 도움이된다는 것이 일반적인 관례라고 생각합니다. 또한 당신은 내가 옳다고 생각한다고 말 com.googlecode.oldproj했는데 왜 이것이 좋은 생각이라고 생각합니까? 돌이켜 보면 코드를 호스팅 제공 업체에 묶는 것이 어리석은 일이라고 생각했습니다.
Jesse Webb 2013

1
요점은 그것이 당신을 일부 호스팅 제공 업체와 연결시키는 것이 아니라 요점은이 프로젝트에 고유 한 기존의 고유 식별자라는 것입니다. 기술적으로 "com.jesseweb.oldproj"는 모두입니다. 이름을 붙이고 싶지 않았기 때문에 좋은 결정이었습니다. Java 패키지 및 .NET 네임 스페이스는 다운로드 사이트 등을 알려주는 푯말이 아니며 규칙에 따라 고유 한 식별자 일뿐입니다.
로스 패터슨
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.