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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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
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.
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/
iQEcBAEBAgAGBQJOREFHAAoJEEfVXEODPFIDZ5IH/Rr6pt2CzwwhtULz1TXYsx+
X
YjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBii
rzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMz
ki1P
xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz
BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1k
nhdo
/gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk=
=oD3n
-----END PGP SIGNATURE-----
