org.fcrepo +1 Reasons, by order of importance to me: A) distinctiveness (googling for fedorarepo gets you lots of redhat stuff) B) brevity C) consistency (jira tracker, development space, mailing list name, website name, etc)
Although the hosting organization is now DuraSpace, I think people will continue to identify this as the "Fedora Commons Repository" for quite a while. At least, as long as DuraSpace does: see duraspace.org, under "Projects". My 2cents... - Chris On Fri, Nov 20, 2009 at 9:55 PM, Bill Branan <[email protected]> wrote: > Hi Eddie, > For all of the reasons you mentioned, I don't think any of 1-4 are the best > options. I feel like fcrepo is nice for its shortness, but it seems a bit > cryptic to me. This is particularly true considering that "fc" is short for > fedora commons, which is the old organization name. Granted, the concept of > a fedora "commons" is still around to some extent, but the name itself may > fade into the background over time. Another drawback to fcrepo, as Andrew > pointed out a while back, is the possibility of it being pronounced f-crepo > rather than fc-repo. > I like how fedorarepo is clearly associated with the known name of the > Fedora project. We've also been referring to the software as the Fedora > Repository for some time now, despite the unfortunate affliction of RAS > syndrome. > org.fedorarepo +1 > Bill > > On Fri, Nov 20, 2009 at 8:27 PM, Edwin Shin <[email protected]> > wrote: >> >> 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 > > > ------------------------------------------------------------------------------ > 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
