I'll toss in that these naming conventions arose prior to the initiative to
backport the services api into DSpace 1.x and so we were not concerned with the
package naming conventions colliding that early on. Now that we see it, it can
be easily addressed.
cheers,
Mark
On Jun 8, 2010, at 10:11 AM, Tim Donohue wrote:
> 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
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
