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