Forgot to add onto this... In some cases (org.dspace.provider.CacheProvider) it could just be that the class needs to eventually move into the "core" API. So, in that case, the package path may just be caused by lack of a full acceptance of the Services Framework. But, I just wanted to note my concerns about potential conflicts (mostly with the Constants class -- the others could likely be explained away)
- Tim On 6/8/2010 12:01 PM, 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 > ------------------------------------------------------------------------------ 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
