[jira] [Resolved] (ISIS-833) Break out applib and JDO services into modules

["Dan Haywood (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ISIS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Haywood resolved ISIS-833.
------------------------------

    Resolution: Fixed

> Break out applib and JDO services into modules
> ----------------------------------------------
>
>                 Key: ISIS-833
>                 URL: https://issues.apache.org/jira/browse/ISIS-833
>             Project: Isis
>          Issue Type: Improvement
>    Affects Versions: objectstore-jdo-1.5.0, core-1.5.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>             Fix For: objectstore-jdo-1.6.0, core-1.6.0
>
>
> ... so that in future these can be released independently of core; and to reduce configuration (isis.properties file).
> Some principles:
> * minimize the amount of configuration required;  by exploiting @DomainService annotation, in many cases it should be sufficient to simply add the appropriate module to the classpath, and let the service be auto-reigstered.
> * "on the other hand", don't (without some safety checks) want to start automatically registering services that might substantially change behaviour of the system.  For example, the JDO services - audit, command, publishing - all require explicit configuration in isis.properties.  Automatically registering these might be "too much, too soon".
> Thus:
> * In services containing only programmatic or hidden services ("system services, repos") then these should be annotated with @DomainService; thus they are configured and registered automatically if added to the classpath.
> * In services containing only "contributions" can (probably safely enough) be annotated with @DomainService; thus they are configured and registered automatically if added to the classpath.
> * any menu UI services should NOT be annotated with @DomainService, because the developer may want to have more fine-grained control on how the UI appears.
> ~~~~~~
> No change for the following services:
> core request-scoped services; already annotated with @DomainService, and so always available
> - CommandContext                   (no UI; applib implementation; populated by runtime if available)  - UPDATED JAVADOC
> - Bulk.InteractionContext          (no UI; applib implementation; not used by runtime)  - UPDATED JAVADOC
> - Scratchpad                       (no UI; applib implementation; not used by runtime)  - UPDATED JAVADOC
> - QueryResultsCache                (no UI; applib implementation; not used by runtime)  - UPDATED JAVADOC
> core singleton services; already annotated with @DomainService, and so always available
> - MementoServiceDefault                  (no UI; runtime implementation; used implicitly by runtime for commands)  - UPDATED JAVADOC
> - BookmarkServiceDefault                 (no UI; runtime implementation; used implicitly by runtime for commands) - UPDATED JAVADOC, now non UI, separated out out contributions
> - XmlSnapshotServiceDefault              (no UI; runtime implementation; not used by runtime) - UPDATED JAVADOC
> - ClassDiscoveryServiceUsingReflections  (no UI; applib implementation; not used by runtime) - UPDATED JAVADOC
> - ClockService                     (no UI; applib implementation; not used by runtime) - UPDATED JAVADOC
> ~~~
> These services should changed to be annotated annotated with @DomainService (because JDO is now core):
> - IsisJdoSupportImpl               (no UI; not used by runtime)  - NOW ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for integ tests
> - EventBusServiceJdo            (no UI, used by runtime if available)  - NOW ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for integ tests
> ~~~
> IsisJdoSupport API should move from the jdo-applib to applib; - DONE. 
> ~~~~~~
> The following are new (Maven) modules.  
> Some notes:
> * If a service can be used by runtime, then its API is defined in applib; the module therefore contains only the impl.  Most of the modules below fall into this category.
> * If a service is completely standalone from the framework, then it defines its own API (in an "applib" submodule) and its own impl.  An example of this is isis-module-settings, which defines AppSettings and UserSettings.
> isis-module-wrapper                (used by integtestsupport)
> - WrapperFactoryDefault            (no UI; already @DomainService; rename core-wrapper implementation); DONE, UPDATED pom.xml in example apps; 
> isis-module-command-jdo   - MOVED, UPDATED.  
> - CommandServiceJdo                (used by runtime if available, so API in applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW.
> - CommandServiceJdoContributions   (UI, not used by runtime)
> - CommandServiceJdoRepository      (no UI, supporting service for ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> - BackgroundCommandServiceJdo               (UI visible, not used by runtime but prereq for background service) - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> - BackgroundCommandServiceJdoContributions  (UI visible, not used by runtime)
> - BackgroundCommandServiceJdoRepository     (not visible, supporting service for ...Contributions);  - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> isis-module-audit-jdo   - MOVED, UPDATED.
> - AuditingServiceJdo                (used by runtime if available, so API in applib)  - DECIDED NOT TO MAKE INTO @DomainService FOR NOW
> - AuditingServiceJdoContributions   (UI, not used by runtime)
> - AuditingServiceJdoRepository      (not visible, supporting service for ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> isis-module-background
> - BackgroundServiceDefault         (used by runtime if available, so API in applib; requires BackgroundCommandService); CAN'T SAFELY BE A @DomainService BECAUSE OF DEPENDENCY ON impl. of BackgroundCommandService
> isis-module-publishing-jdo
> - PublishingServiceJdo              (used by runtime if available, so API in applib)
> - PublishingServiceJdoContributions (UI, not used by runtime) 
> - PublishingServiceJdoRepository    (not visible, supporting service for ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> isis-module-publishingeventserializer-ro
> - RestfulObjectsSpecEventSerializer  (not visible, used by publishing service); - NOW ANNOTED AS @DomainService; UPDATED EXAMPLES
> isis-module-devutils               (not used by runtime, standalone); DONE
> - applib
>         > DeveloperUtilitiesService
> - impl
>         > DeveloperUtilitiesServiceDefault    (metamodel impl)
> isis-module-settings  (not used by runtime, standalone); DONE
> - applib
>         > ApplicationSettingsServiceRW
>         > UserSettingsServiceRW        
> - impl-jdo
>         > ApplicationSettingsServiceJdo     (UI, not used by runtime)
>         > ApplicationSettingsServiceHidden  (not UI, not used by runtime)
>         > UserSettingsServiceJdo            (UI, not used by runtime)
>         > UserSettingsServiceHidden         (not UI, not used by runtime)
> in addition:
> * move IsisJdoSupport APi into core-applib *;  DONE; HAVE REMOVED jdo-applib completely... updated pom.xml for example apps.
> * EventBusServiceDefault   can be deprecated, since its subclass EventBusServiceJdo is always available; DONE
> - have decided to leave ExceptionRecognizerCompositeForJdoObjectStore to be explicitly registered; likelihood that this will require customisation in some cases.  (used by runtime if available)



--
This message was sent by Atlassian JIRA
(v6.2#6252)