org.duraspace.fedora
org.duraspace.dspace
org.duraspace.duracloud
org.duraspace.mulgara
...
 
A bit verbose, but has a clear association with the new organization, allows 
for shared code packages, and has no ugly and misleading abbreviations in it.
  
But as I am not a committer, my vote won't count ;-)
 
Matthias.

________________________________

Von: Edwin Shin [mailto:[email protected]]
Gesendet: Sa 21.11.2009 02:27
An: FC Developers List
Betreff: [Fedora-commons-developers] call for vote on package renaming



Now that we've actually grabbed the fcrepo com & org domains, I think we can 
call for a vote.

At issue is renaming the Java package name used by Fedora. Currently it's just 
"fedora", e.g.
        fedora.server.Module.java

Part of mavenizing Fedora includes publishing our artifacts to Maven Central 
which requires that the package name match a domain under our control. So this 
renaming directly relates to our artifact naming as well. Options that meet 
that requirement include:
        1) info.fedora
        2) org.fedora-commons
        3) org.fedoracommons
        4) org.duraspace
        5) org.fedorarepo
        6) org.fcrepo

We've distanced ourselves from fedora.info since the creation of Fedora 
Commons. I don't sense a lot of will to move back in that direction. That and 
no one seems to like .info domains.

2, 3, and 4 all include more than just the repository software, and so beyond 
the base package name change, we'd probably have to add something to further 
distinguish, e.g. org.fedora-commons.repository.

In its favor, 5 has
        a) the name "fedora" included

In its favor, 6 has
        a) brevity
        b) consistency. We already use the name fcrepo in our issue tracker 
(JIRA) to refer to Fedora and hence in our svn commit logs, our committer 
calls, etc.
        c) fedorarepo is redundant: fedorarepo expands to "Flexible Extensible 
Digital Repository Architecture Repository"

Since 3.3 is imminent, I'm calling for a vote between org.fedorarepo and 
org.fcrepo by the next committer call, Tuesday 24 November.



On 20 Nov 2009, at 7:30 AM, Chris Wilper wrote:

> On Thu, Nov 19, 2009 at 7:01 PM, Edwin Shin <[email protected]> wrote:
>> I generally like the new naming, although Chris & Dan
>> see my email off-list for a alternative prefix for the project as a whole.
>
> I think it'd be good to call a vote (and soon) on your new suggested
> prefix, since 1) we already came to a rough consensus on the current
> one with the committer group, and 2) we really would need closure on
> that soon.  Changing groupIds after 3.3 would be a real hassle..
>
>> For the localservice renaming, another option is to use the fedora-webapp 
>> module
>> (now fedorarepo-webapp) as a pom with child modules fedora, fop,  saxon, and 
>> imagemanip.
>
> I kinda like that. Others?
>
> BTW, I'm willing to drop the idea of flattening the existing modules,
> since I don't hear any support for that idea.
>
> So here's the updated proposal:
>
> 1) Rename fedorarepo-admin-client to fedorarepo-client-admin
> 2) Rename fedorarepo-messaging-client to fedorarepo-client-messaging
>
> (the above seem to be agreed on at this point and I'll do them if no
> one complains)
>
> 3) Get rid of the fedora-localservices module and instead have
> fedorarepo-webapp as a module with the following children:
> a) fedorarepo-webapp-fedora
> b) fedorarepo-webapp-fop
> c) fedorarepo-webapp-saxon
> d) fedorarepo-webapp-imagemanip
>
> Note that I haven't figured out ultimately what to do about
> fedorarepo-webadmin, which uses flexmojos to build the web admin
> interface (currently needs to be copied manually into
> fedorarepo-webadmin-fedora).
>
> - Chris
>
>>
>> On 19 Nov 2009, at 9:58 PM, Chris Wilper wrote:
>>
>>> 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/
>>>>>  
>>>>> <https://remote.fiz-karlsruhe.de/svnroot/fedora-commons/fedora/trunk/,DanaInfo=fedora-commons.svn.sourceforge.net,SSL+>
>>>>>  
>>>>>
>>>>> 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 
>>>>> <https://remote.fiz-karlsruhe.de/sfu/,DanaInfo=p.sf.net+bobj-july> 
>>>>> _______________________________________________
>>>>> Fedora-commons-developers mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers 
>>>>> <https://remote.fiz-karlsruhe.de/lists/listinfo/,DanaInfo=lists.sourceforge.net,SSL+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 
>>> <https://remote.fiz-karlsruhe.de/sfu/,DanaInfo=p.sf.net+bobj-july> 
>>> _______________________________________________
>>> Fedora-commons-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers 
>>> <https://remote.fiz-karlsruhe.de/lists/listinfo/,DanaInfo=lists.sourceforge.net,SSL+fedora-commons-developers>
>>>  
>>
>>
>> ------------------------------------------------------------------------------
>> 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 
>> <https://remote.fiz-karlsruhe.de/sfu/,DanaInfo=p.sf.net+bobj-july> 
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers 
>> <https://remote.fiz-karlsruhe.de/lists/listinfo/,DanaInfo=lists.sourceforge.net,SSL+fedora-commons-developers>
>>  
>>


------------------------------------------------------------------------------
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 
<https://remote.fiz-karlsruhe.de/sfu/,DanaInfo=p.sf.net+bobj-july> 
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers 
<https://remote.fiz-karlsruhe.de/lists/listinfo/,DanaInfo=lists.sourceforge.net,SSL+fedora-commons-developers>
 




-------------------------------------------------------

Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische 
Information mbH. 
Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 
101892. 
Geschäftsführerin: Sabine Brünger-Weilandt. 
Vorsitzender des Aufsichtsrats: MinR Hermann Riehl.

------------------------------------------------------------------------------
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

Reply via email to