Hi Brad I would like to refer you to http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.7
It suggest the following: You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as sun.com. You then reverse this name, component by component, to obtain, in this example, com.sun, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names. And true, this is just a suggestion, not a demand for java. There are components to this. It requires that you have the corresponding domain, in order to use the namespace. It suggest that you use the namespace of your organization, not just some domain you own. I am unclear if fedora-commons is an organisation, or fedora is a project under the duraspace organisation. This, to me, is the deciding factor about which namespace we should use. In short, we should use the primary organisational domain name as the namespace. At the moment this is probably fedora-commons.org and we should thus use org.fedora_commons Regards On Mon, 2009-11-23 at 15:37 +0100, Bradley McLean wrote: > Excuse me, please, for jumping in with a non-voting opinion. > > I'm not sure I see direct value in inserting 'duraspace' into each > individual project's naming schemes. I'd like to hear more, or see an > example of projects using different domain names for code and "official > information" where it becomes a problem. Similarly, I'd like to hear > more about how changing the naming scheme is going to help code sharing > without creating many issues related to release scheduling, packaging, etc. > > There is a distinction to be made between the Duraspace organization, > and the projects that are currently under it's banner. Projects can and > do move across organizational boundaries (DSpace has done so twice now > in three years). While we certainly hope that we'll continue to hold > the projects together, the projects are independent from each other, and > have separate governance models, so the future isn't guaranteed. > > Achieving a consensus on a uniform set of org.duraspace prefixes > involves at least four distinct groups (fedora committers, dspace > committers, mulgara committers, duraspace organization) coming to > internal and external agreement. There is a similar issue with merging > websites together, or to go farther, wiki sites, mailing lists, and the > like. > > So my opinion is that it is premature to start carving up and allocating > duraspace.org namespace, especially on the timeframe required for the > fedora package renaming vote. > > I've changed the Subject so as not to pollute the vote with this > discussion, and I very much do want to hear those examples of projects > for which separated names are an issue - we may have something to > learn. Also, I applaud attempts to encourage code sharing, but I'd like > some debate on whether renaming helps in this case. > > Thanks for allowing the intrusion. I'll completely identify myself for > clarity below, but let me emphasize that this is a non-voting personal > opinion, and not any sort of official (or officious!) mandate. > > -Brad > > Bradley McLean, CTO, DuraSpace. > > Kåre Fiedler Christiansen wrote: > > Hi list, > > > > +1 on org.duraspace. > > > > We currently have a majority among non-committers for this one :-) > > > > Especially, I agree with Matthias about obscure abbreviations, and I > > _really_ like the idea about using existing well-known domain names. > > Also, code sharing seems like a good reason for this naming scheme. > > > > I know of a few project using different domain names for their code and > > their "official information", and it always confuses me where I need to > > go look for code and information. Fedora already has far too many > > different websites and domain names. With the death of fedora.info it > > seems we got a new situation with fedora-commons.org and duraspace.org. > > Perhaps it would be a good idea to merge the websites on > > "http://fedora.duraspace.org";, "http://dspace.duraspace.org"; etc.? Or at > > least start planning for it. > > > > My second choice would be "org.fedora-commons.repository", if agreement > > can't be reached with the rest of duraspace. > > > > Best, > > Kåre > > > > On Sat, 2009-11-21 at 18:26 +0100, Razum, Matthias wrote: > > > >> g_baseurl="http://excluster.fiz-karlsruhe.de/exchange/Matthias.Razum/Entw%C3%BCrfe/AW:%20[Fedora-commons-developers]%20call%20for%20vote%20on%20package%20renaming.EML/1_text.htm";; > >> > >> org.duraspace.fedora > >> org.duraspace.dspace > >> org.duraspace.duracloud > >> org.duraspace.mulgara > >> ... > >> > >> A bit verbose, but has a clear association with the new > >> organization, allows for shared code packages, and has no ugly and > >> misleading abbreviations in it. > >> > >> But as I am not a committer, my vote won't count ;-) > >> > >> Matthias. > >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
