I've taken this proposal and stretched it a bit further :)
Please review the comment I added here:
http://issues.apache.org/jira/secure/EditComment!default.jspa?id=12518501&commentId=13106190
As a summary, what I propose is to split up the rave-portal such that only a
pom.xml remains to build it.
That then will allow for truly and proper customization for any custom portal
project you like, as well as allow embedding rave-portal within another/existing
project if you want.
The most important element (to me) is: splitting off code from (web)
resources/configurations as combining those in a "final" war module makes it
very difficult and problematic to extend and/or embed elsewhere.
If this proposal is acceptable, I'd volunteering to "implement" it.
This will require quite some code/file shuffling, and potentially might hit some
snags concerning keeping the tests working or working again.
But other than that, it should not require real code/configuration changes
(other than for tests and poms).
WDYT?
Ate
On 08/16/2011 04:03 PM, Franklin, Matthew B. wrote:
I think we agreed on the following:
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
-----Original Message-----
From: Marlon Pierce [mailto:[email protected]]
Sent: Tuesday, August 16, 2011 9:03 AM
To: [email protected]
Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
create a jar as well as a war and deploy this jar to the local repository.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Do we have consensus on this code reorganization?
Marlon
On 8/12/11 10:02 AM, Ate Douma wrote:
On 08/12/2011 02:59 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: Ate Douma [mailto:[email protected]]
Sent: Friday, August 12, 2011 5:57 AM
To: [email protected]
Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
should
create a jar as well as a war and deploy this jar to the local repository.
On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
-----Original Message-----
From: Marlon Pierce [mailto:[email protected]]
Sent: Thursday, August 11, 2011 4:53 PM
To: [email protected]
Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
should
create a jar as well as a war and deploy this jar to the local repository.
I tried a quick and dirty separation that worked (that is, code compiled and
portal ran as expected): I moved all of rave-portal java code except
org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
new
module, rave-components (with a 'jar' target) and made rave-portal
dependent on rave-components.jar.
If we do have need to expose the subcomponents (sounds like we
do),
then I think the following structure would better fit the intent of
modularity:
Rave Project:
|
|__rave-modules/components/whatever
| |
| |__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
I think this would give us the best breakup of functionality. The biggest
question in my mind is the providers. I feel like they should be
separable from
everything with the exception of the javascript. If someone has a good
strategy for managing this, I think this model would work well.
I like this.
Not sure though if we need a two level separation for rave-
modules/components.
Wouldn't it be easier to either use only rave-components as root
module?
The only reason I can think of why that wouldn't be good enough if we
ever
end
up needed "non-module" components, whatever that would be.
So you would want to keep rave-commons, core& security under rave-
project directly? Just to be clear what I meant by
modules/components/whatever is that I wasn't sure about the name of that
first level sub-module under rave-project.
Ah, sorry my misunderstanding: I took your example too literal :)
So, I'm fine with using either rave-modules/ or rave-components.
Thanks,
Ate
Concerning the rave-portal, ideally (from my POV at least) that shouldn't
need
to have any classes/resources left which might want/need to be
extendable
or
I could see this making sense at some point
overridable, including even webapp specific features like the controller
logic
etc. That's maybe a bit far fetched right now, but eventually I'd like to be
able to "assembly" my own custom portal including customizing the
frontend.
I am hoping you have a strategy for allowing extension (customization) of
the base UI to fit your needs :)
It would be nice if for instance Shindig already were more "modular" in
that
respect so that instead of needing a war overlay with "hacking" our
custom
usage
on top. Right now that's still a minor annoyance, but I expect it'll become
more
so when we need to "push" more features and/or customization within
the
rave-shindig build. We probably will need to "help" the Shindig project a
bit to
support us better in this respect.
Anyway, all in due time and in general I prefer to pick a "battle" when
there is
a concrete use-case for it :) For the rave-components separation that
seems
to
start now, further modularization of rave-portal itself (as webapp) can
wait
until we hit the wall there.
Regards,
Ate
I don't think we have enough use cases yet to decide on finer grained rave
component jars, but making one comprehensive rave-components jar
from
our current code organization is straightforward.
Marlon
On 8/11/11 10:37 AM, Ate Douma wrote:
On 08/11/2011 03:57 PM, Marlon Pierce wrote:
Considering the case at hand, I need to extend
DefaultUserService.java
(and UserService.java), which are in
rave-portal/src/main/java/org/apache/rave/portal/service/.
So, you'll at least need these in your classpath to be able to extend
and
build, right?
Using a war overlay like we do with rave-shindig then won't help
you: a
maven dependency on a war artifact won't expose its classpath.
This is why I think you'll need a proper separated module to do
this.
Other than that and I think also mentioned some time before, I'd
prefer
minimizing usage of war overlays, actually eventually even get rid of the
rave-
shindig war overlay. They are just too cumbersome to work with, an easy
cause of "duplicate jar" hell, and have little or no support at all within IDEs.
These will
have a dependency on the UserRepository, so this will need to be
wired
up. Other services (including unwritten ones) could also depend on
the
UserRepository. This could be avoided by just extending the
UserService
interface, but for my case this is not ideal--I only need to override
one method in DefaultUserService.
So we may not have enough use cases yet to decide on the optimal
reorganization of the code.
I'm happy to try Matt's recommended Spring magic in the short
term.
Marlon
On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
-----Original Message----- From: Ate Douma
[mailto:[email protected]]
Sent: Thursday, August 11, 2011 8:38 AM To:
[email protected] Subject: [DISCUSS] (RAVE-
171) The
maven install for rave-portal should create a jar as well as a war
and deploy this jar to the local repository.
IMO this is not the way how we should solve extensibility of
the
functionality currently within the rave-portal module.
+1
Producing multiple artifacts from a single Maven module (pom)
is a
bad pattern in general, as additional artifacts won't have any
meta-data context attached. For example, this additional
rave-portal jar artifact from the rave-portal war pom won't
have
any transitive dependencies meta-data, nor will you have
(from
maven) any "reference" back to its source origin, etc.
I think that if we want to be able to make the functionality
within
rave-portal extendable/customizable, we better start factoring
these out into real "component" or "service" modules. And
add and
isolate interfaces and APIs so they can become "pluggable" by
themselves. The rave-commons module already represents
one
type
of
such modularization, but I think we'll need to go much further.
Possibly, but I think there might be a simpler way to handle it for
now.
My proposal would be to create a new rave pom module called
something like "rave-components" or "rave-services" and a)
move
rave-commons under it as a sub module b) initiate a new sub
module
(rave-security?) isolating the functionality currently within
rave-portal to be extended upon like by the science-gateway
in the
sandbox
I would recommend having the science gateway use an overlay
like
we
do with rave-shindig. This way, you can override
implementations in
rave-portal by injecting beans marked primary in the Spring
application context. This shouldn't be too difficult to setup.
WDYT?
Regards,
Ate
On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
The maven install for rave-portal should create a jar as well as
a war and
deploy this jar to the local repository.
---------------------------------------------------------------------------
------
----
--------
-----------------------
Key: RAVE-171 URL:
https://issues.apache.org/jira/browse/RAVE-171 Project:
Rave
Issue Type: Sub-task Reporter: Marlon Pierce
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
-- This message is automatically generated by JIRA. For more
information on JIRA, see:
http://www.atlassian.com/software/jira
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOSmqEAAoJEEfVXEODPFIDGuoH/RtHsy6PcGnKF/bHpYtMY
5iE
VIAXFnlDRUKisGkP2/cnW4joBSOFMha9qnkfkUKj5yf161pKl40ZVIvMxVs8NnIi
d6PDkcwytE4MX8VVH6dHLzM/L/s3IUHqK6MGhFX1fh0J6uk4q2x65QopyeRESF
ou
EodwWBUuCxpJGrMpVhxayVcT2DrW98mYk2c5IE+lJFh0G0C8FaQXboWMrd83
/xcZ
WZZVBpHUc0vjv7qsdyaZfadkrO3BhJp2sCKk5FO2N2gjJkEyI1xkDg9YhF8Zonjk
UjF3lYeYsTb4wEdq8LX+N79QzmZ4Qyg9DEuE8Fm6qXPXEyF2A/hXab4CkSuBnl
w=
=Vm4H
-----END PGP SIGNATURE-----
