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. > > > ______________________________________________________________________ > Von: Edwin Shin [mailto:[email protected]] > Gesendet: Sa 21.11.2009 02:27 > An: FC Developers List > Betreff: [Fedora-commons-developers] call for vote on package renaming > > > Now that we've actually grabbed the fcrepo com & org domains, I think > we can call for a vote. > > At issue is renaming the Java package name used by Fedora. Currently > it's just "fedora", e.g. > fedora.server.Module.java > > Part of mavenizing Fedora includes publishing our artifacts to Maven > Central which requires that the package name match a domain under our > control. So this renaming directly relates to our artifact naming as > well. Options that meet that requirement include: > 1) info.fedora > 2) org.fedora-commons > 3) org.fedoracommons > 4) org.duraspace > 5) org.fedorarepo > 6) org.fcrepo > > We've distanced ourselves from fedora.info since the creation of > Fedora Commons. I don't sense a lot of will to move back in that > direction. That and no one seems to like .info domains. > > 2, 3, and 4 all include more than just the repository software, and so > beyond the base package name change, we'd probably have to add > something to further distinguish, e.g. org.fedora-commons.repository. > > In its favor, 5 has > a) the name "fedora" included > > In its favor, 6 has > a) brevity > b) consistency. We already use the name fcrepo in our issue > tracker (JIRA) to refer to Fedora and hence in our svn commit logs, > our committer calls, etc. > c) fedorarepo is redundant: fedorarepo expands to "Flexible > Extensible Digital Repository Architecture Repository" > > Since 3.3 is imminent, I'm calling for a vote between org.fedorarepo > and org.fcrepo by the next committer call, Tuesday 24 November. > > > > On 20 Nov 2009, at 7:30 AM, Chris Wilper wrote: > > > On Thu, Nov 19, 2009 at 7:01 PM, Edwin Shin > <[email protected]> wrote: > >> I generally like the new naming, although Chris & Dan > >> see my email off-list for a alternative prefix for the project as a > whole. > > > > I think it'd be good to call a vote (and soon) on your new suggested > > prefix, since 1) we already came to a rough consensus on the current > > one with the committer group, and 2) we really would need closure on > > that soon. Changing groupIds after 3.3 would be a real hassle.. > > > >> For the localservice renaming, another option is to use the > fedora-webapp module > >> (now fedorarepo-webapp) as a pom with child modules fedora, fop, > saxon, and imagemanip. > > > > I kinda like that. Others? > > > > BTW, I'm willing to drop the idea of flattening the existing > modules, > > since I don't hear any support for that idea. > > > > So here's the updated proposal: > > > > 1) Rename fedorarepo-admin-client to fedorarepo-client-admin > > 2) Rename fedorarepo-messaging-client to fedorarepo-client-messaging > > > > (the above seem to be agreed on at this point and I'll do them if no > > one complains) > > > > 3) Get rid of the fedora-localservices module and instead have > > fedorarepo-webapp as a module with the following children: > > a) fedorarepo-webapp-fedora > > b) fedorarepo-webapp-fop > > c) fedorarepo-webapp-saxon > > d) fedorarepo-webapp-imagemanip > > > > Note that I haven't figured out ultimately what to do about > > fedorarepo-webadmin, which uses flexmojos to build the web admin > > interface (currently needs to be copied manually into > > fedorarepo-webadmin-fedora). > > > > - Chris > > > >> > >> On 19 Nov 2009, at 9:58 PM, Chris Wilper wrote: > >> > >>> Scott, > >>> > >>> I see your point on the demo prefix... although these are used by > the > >>> demo objects, people do depend on them in production. > Particularly > >>> the saxon one. > >>> > >>> "localservices" still bothers me, though. The fact that they're > >>> "local" (in the same webapp container as Fedora) really has to do > with > >>> how we happen to package the out-of-box Fedora; in production, you > >>> could make the choice to deploy them wherever you want (e.g., for > >>> performance reasons) > >>> > >>> - Chris > >>> > >>> On Thu, Nov 19, 2009 at 3:01 PM, Scott Prater <[email protected]> > wrote: > >>>> Chris, > >>>> > >>>> My only concern is with the "demo"" prefix: many people make use > of these > >>>> external web services in production environments, when suitable > and useful; > >>>> giving them the name "demo"" may lead to unnecessary confusion > if they can > >>>> be used for purposes other than demonstration and testing. > >>>> > >>>> -- Scott > >>>> > >>>> Chris Wilper wrote: > >>>>> > >>>>> I have a proposal for maven module/artifactId renaming that I'd > like > >>>>> to get reactions on. > >>>>> > >>>>> Take a look at our current hierarchy: > >>>>> > >>>>> > >>>>> > https://fedora-commons.svn.sourceforge.net/svnroot/fedora-commons/fedora/trunk/ > >>>>> > >>>>> Here's what I'm proposing we change, in a nutshell: > >>>>> > >>>>> fedorarepo-admin-client -> fedorarepo-client-admin > >>>>> fedorarepo-messaging-client -> fedorarepo-client-messaging > >>>>> > >>>>> fedorarepo-localservices -> fedorarepo-demoservice > >>>>> fedorarepo-fop -> fedorarepo-demoservice-fop > >>>>> fedorarepo-saxon -> fedorarepo-demoservice-saxon > >>>>> fedorarepo-imagemanip -> fedorarepo-demoservice-imagemanip > >>>>> > >>>>> This renaming offers two improvements over what we've got today. > It: > >>>>> 1) Consistently names the submodules according to the same > hierarchy > >>>>> implied by the module structure > >>>>> 2) Renames "localservices" to "demoservice". This makes this > >>>>> container module's name > >>>>> a) singular, to be consistent with the fedorarepo-client > container > >>>>> module naming, and > >>>>> b) start with "demo" instead of "local", which I think is a more > >>>>> meaningful name, and lines up nicely with the related module, > >>>>> fedorarepo-democontent > >>>>> > >>>>> On a separate note, I'm starting to question whether a "module > >>>>> hierarchy" is really useful for the two modules we're currently > doing > >>>>> it in...they're bare-bones poms at the moment, and if the name > already > >>>>> implies the hierarchy, I'm not seeing the value. That's not to > say a > >>>>> 3-or-more-level hierarchy of modules doesn't make sense in some > cases, > >>>>> but I'm just not seeing it here. Anyone else have thoughts on > that? > >>>>> > >>>>> Thanks, > >>>>> Chris > >>>>> > >>>>> P.S. Thanks again to Andrew and Dan for doing the heavy lifting > in the > >>>>> maven migration so far. I really think we're in a better place > now, > >>>>> and it will be very gratifying to do a non-ant release soon. > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------------------ > >>>>> 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 > >>>> > >>>> > >>>> -- > >>>> Scott Prater > >>>> Library, Instructional, and Research Applications (LIRA) > >>>> Division of Information Technology (DoIT) > >>>> University of Wisconsin - Madison > >>>> [email protected] > >>>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> 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 > >> > > > ------------------------------------------------------------------------------ > 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 > > > > > ------------------------------------------------------- > > Fachinformationszentrum Karlsruhe, Gesellschaft für > wissenschaftlich-technische Information mbH. > Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB > 101892. > Geschäftsführerin: Sabine Brünger-Weilandt. > Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. > -- Kåre Fiedler Christiansen - It-udvikler STATSBIBLIOTEKET, Universitetsparken, 8000 Århus C. Tlf. 89462036 http://statsbiblioteket.dk CVR/SE 10100682 - EAN 5798000791084 ------------------------------------------------------------------------------ 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
