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-----
