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
