Hi Tim, Well spotted. Seems a no-brainer to me now you point it out.
Cheers. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 > -----Original Message----- > From: Tim Donohue [mailto:[email protected]] > Sent: 08 June 2010 18:02 > To: dspace-devel > Subject: [Dspace-devel] Concerns about Java packages used by > Services Framework API > > 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 > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ 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
