[
https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106190#comment-13106190
]
Ate Douma commented on RAVE-171:
--------------------------------
While I agree with Jasha that at some time (soon?) we might need to split off
(some) interfaces into an separate api module, I'd like to postpone that as
long as possible :)
Having interfaces separated will especially be useful for modules which provide
a specific and separate implementation which makes no sense to extend. Most
likely candidate for these are providers and persistence modules (like using a
noSQL or JCR backend instead of JPA). The current JPA annotations in the
rave/shindig model beans might give us some problems in this regard, but that
has already been discussed before.
As long as we don't have a concrete use-case for this though, I don't want to
deal with this upfront.
Site note: I expect we (Hippo) very likely will be the first to "hit" on this
issue ourselves :)
For commonly used services and alike, having access to the API *and* a default
(or abstract) base implementation to easily extend, I'd rather keep them
together as long as possible.
What I strongly agree with though is that we should cleanly separate our
"components" such that portal extensions like currently in the sandbox can
properly depend on these components and *not* rely on a custom jar produced
from the main portal war pom. That solution is IMO fundamentally broken and a
bad (Maven) pattern.
Instead, I'd actually would like to see the current rave-portal (and possibly
rave-shindig as well) be "broken up" such that *no* java code remains ...
(except for integration tests etc.)
One new component I therefore propose is: rave-portal-web, pulling out all
o.a.r.portal.web.* classes (note: I propose this rave-portal-web and not
rave-web for obvious reasons)
Which then only leaves (currently) the o.a.r.portal.util.LocalizationUtils
class and related o.a.r.portal.module.util classes which I propose to move to
the rave-commons module
What remains then only concerns the war resources: web.xml, Spring assemblies,
css, jsp, etc. and test classes and configurations...
And then I'd like to stretch this proposal one bit further for truly and proper
customization:
- split off a new rave-portal-dependencies pom module (under components) which
aggregates all (default) portal dependencies
- split off all remaining test code and configurations in a new war module
called rave-portal-test, which will use the above rave-portal-dependencies as
dependencies,
optionally adding some additional test only dependencies, and finally
*extend* the below specified rave-portal-resources war module as war overlay
(see next),
so it will by itself will become a proper (test only) rave-portal instance
- move the remaining "shallow" rave-portal war module also under components,
renaming it to rave-portal-resources and having *no* dependencies (meaining a
shallow/abstract war module which cannot be deployed)
- finally, create a new rave-portal war module which:
a) extends (without further ado) the rave-portal-resources war
b) depends *only* on rave-portal-dependencies
The end result of the above restructuring proposal then will look something
like:
Rave Project:
|
|__rave-components:pom
| |
| |__rave-commons:jar (Generic & common code that is usable in many different
contexts, modules and projects)
| |
| |__rave-core:jar (Core Model, Service& Repository classes that are used by
multiple applications) [Widget, Person& related Classes]
| |
| |__rave-security:jar (Security related classes) [User extends Person,
Security Utilities, etc]
| |
| |__rave-portal-web:jar (Portal web/frontend related classes) [rest/rpc api,
controller, renderer, etc]
| |
| |__rave-portal-dependencies:pom (aggregates all and only the rave-portal
runtime dependencies)
| |
| |__rave-portal-resources:war (shallow war having zero dependencies and all
and only needed web resources for the rave-portal)
| |
| |__rave-portal-test:war (rave test portal containing all the portal level
test code and configurations)
|
|__rave-providers:pom
| |
| |__rave-opensocial:jar (OpenSocial provider classes)
| |
| |__rave-w3c:jar (W3C provider classes)
|
|__rave-portal:war (pom.xml which only merges/overlays
rave-portal-resources.war and depends on rave-portal-dependencies)
|
|__rave-shindig:war
WDYT?
> Reorganize project to support better extension
> ----------------------------------------------
>
> Key: RAVE-171
> URL: https://issues.apache.org/jira/browse/RAVE-171
> Project: Rave
> Issue Type: Sub-task
> Reporter: Marlon Pierce
> Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile
> against that code. This can be done by modifying rave-portal/pom.xml so that
> it makes both a war and a jar and installs both in the local repository. The
> extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension
> by downstream integrators:
> Rave Project:
> |
> |__rave- components
> | |
> | |__rave-commons (Generic & common code that is usable in many
> different contexts, modules and projects)
> | |
> | |__rave-core (Core Model, Service& Repository classes that are used
> by multiple applications) [Widget, Person& related Classes]
> | |
> | |__rave-security (Security related classes) [User extends Person,
> Security Utilities, etc]
> |
> |__rave-providers
> | |
> | |__rave-opensocial (OpenSocial provider classes)
> | |
> | |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal& webapp related features) [Regions, Pages,
> controllers, etc]
> |
> |__rave-shindig
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
