-----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.
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+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMzki1P xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1knhdo /gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk= =oD3n -----END PGP SIGNATURE-----
