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