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