Tim,
+1 on a good topic.
I also think that classes called "Constants" are horribly constricting and
promote monolithic programming practices. I for one never saw the need for a
"Constants" class and would like to see it go away completely.
Per "org.dspace.providers", we also have "org.dspace.exceptions" and should
consider naming convention. the original intent was to have service, provider
and exception interfaces/classes consolidated under functional packages. But
that is certainly open to refactoring.
Mark
On Jun 8, 2010, at 10:01 AM, Tim Donohue wrote:
> Hi All,
>
> Digging into the Services Framework, I came across a couple Java classes
> whose packages I'm concerned about.
>
> I'm a little concerned that the DSpace Services API
> (dspace-services-api) and DSpace Services Utils (dspace-services-utils)
> both use several packages which do not begin with either
> "org.dspace.kernel", "org.dspace.services" or "org.dspace.servicemanager"
>
> Specifically, I'm looking at these classes:
> org.dspace.constants.Constants
> org.dspace.providers.CacheProvider
> org.dspace.utils.*
>
> I'm worried that as we continue to modularize DSpace, we have the
> potential to accidentally create class conflicts if we are not careful.
> Currently, no conflicts exist, but we need to be careful which packages
> we are using in each DSpace modules.
>
> In particular, I'm most concerned with "org.dspace.constants.Constants",
> which is eerily similar to "org.dspace.core.Constants".
>
> Obviously, they serve entirely different purposes. But, by just looking
> at the full class package, you would not be able to tell them apart
> (i.e. at a glance, it'd be unclear which one held Constants for
> dspace-api versus dspace-services-api).
>
> I'm wondering if we should recommend that all modules define their own
> set of "package paths", and only add classes under those package(s)?
> So, the valid package paths for Services Framework may include
> "org.dspace.kernel.*", "org.dspace.services.*", and
> "org.dspace.servicemanager.*"
>
> Separate services modules could add onto those package paths, but would
> attempt to avoid reusing them. So, for example, a Storage Service may
> use the package "org.dspace.services.storage.*" -- but we'd recommend
> *against* the Storage Service placing any classes under the package
> "org.dspace.services" (as that package is reserved by the Service
> Framework itself).
>
> Thoughts? Is anyone else concerned about potential class conflicts
> going forward?
>
> (I thought about entering this as a JIRA issue -- but, I thought I'd
> bring it up here first for additional discussion.)
>
> - Tim
>
> --
> Tim Donohue
> Technical Lead for DSpace Project
> DuraSpace.org
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
