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. -----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 anewmodule, 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 manydifferent contexts, modules and projects)| | | |__rave-core (Core Model, Service& Repository classes that are usedby 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 biggestquestion 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 orI could see this making sense at some pointoverridable, 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, AteI don't think we have enough use cases yet to decide on finer grained rave component jars, but making one comprehensive rave-components jarfromour 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 andbuild, right?Using a war overlay like we do with rave-shindig then won't help you: amaven 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 preferminimizing usage of war overlays, actually eventually even get rid of therave-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.+1Producing 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 onetypeofsuch 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 submodule(rave-security?) isolating the functionality currently within rave-portal to be extended upon like by the science-gateway in the sandboxI would recommend having the science gateway use an overlay likewedo 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 anddeploy 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 compileagainst 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+XYjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBiirzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMzki1PxlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekzBLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1knhdo/gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk==oD3n -----END PGP SIGNATURE-----
