-----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/bHpYtMY5iE VIAXFnlDRUKisGkP2/cnW4joBSOFMha9qnkfkUKj5yf161pKl40ZVIvMxVs8NnIi d6PDkcwytE4MX8VVH6dHLzM/L/s3IUHqK6MGhFX1fh0J6uk4q2x65QopyeRESFou EodwWBUuCxpJGrMpVhxayVcT2DrW98mYk2c5IE+lJFh0G0C8FaQXboWMrd83/xcZ WZZVBpHUc0vjv7qsdyaZfadkrO3BhJp2sCKk5FO2N2gjJkEyI1xkDg9YhF8Zonjk UjF3lYeYsTb4wEdq8LX+N79QzmZ4Qyg9DEuE8Fm6qXPXEyF2A/hXab4CkSuBnlw= =Vm4H -----END PGP SIGNATURE-----
