-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks, Ate. Changing over the service implementation is easy enough. Some additional jars (also used in Apache Airavata incubator) will be required. I'll start out in the sandbox, and then we can see if my changes are appropriate for some place in trunk.
Marlon On 8/5/11 8:51 AM, Ate Douma wrote: > On 08/04/2011 11:32 PM, Marlon Pierce wrote: > I like the sandbox idea--this would be rave/sandbox in SVN? >> Yup, just create it. > >> I like having an svn sandbox too, as Ross said it is common practice. >> You usually see then either user "owned" folders or feature specific >> folders, e.g. rave/sandbox/mpierce or rave/sandbox/xyzuserservice > >> So while I like sandboxes, I'm not sure if it would be good for your >> use-case, but I don't know enough about it. > >> The downside of using the sandbox is that it pretty much is off everyone's >> radar, so it will be less likely for you to get much support and attention >> from the other team members as well as from the community. Keeping your >> feature "in line" with the current development will be more difficult, as >> well as the other way around: considering possible breakage of your sandbox >> feature is more difficult for the others. > >> But using a sandbox is great to prototype/experiment with possible future >> use-cases while still providing everyone access/visibility. > >> Concerning your use-case, non-default service implementation in general: IMO >> this should be a core/intrinsic supported "feature" of Rave, and be easily >> doable with the least possible hassle (maybe even runtime). > >> For Jetspeed Portal this was a key "feature" as well (replaceable >> components/services through configuration *only*), whereas we several >> implementations live and maintained side-by-side within one component (for >> instance LDAP or DB security) and always deployed/packaged them together in >> one jar (Maven module) and used only Spring configuration (overlapping >> configurations) to enable/disable which implementation was used at runtime. > >> Alternatively, if the "service" contract can be abstracted away properly >> through interfaces only (preferably), then it should be possible to split >> each implementation off in its own implementation Maven module and let the >> deployment configuration pick which to bundle. Such separation would fit >> well with adding a rave-extensions (pom) module underneath than individual >> extension modules can be added. > >> Anyway, it all depends on your current use-case, and starting out in the >> sandbox might be good enough for now. But if it covers a general use-case >> I'd prefer it being integrated within the project itself at some time :) > >> Regards, > >> Ate > > > > On 8/4/11 5:29 PM, Ross Gardler wrote: >>>> On 4 August 2011 21:59, Franklin, Matthew B.<[email protected]> wrote: >>>>>> -----Original Message----- >>>>>> From: Marlon Pierce [mailto:[email protected]] >>>>>> Sent: Thursday, August 04, 2011 3:17 PM >>>>>> To: [email protected] >>>>>> Subject: [discuss] non-default service implementations in svn >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> I'd like to extend the DefaultUserService.java for some upcoming >>>>>> Rave-based >>>>>> projects. Would there be objections to putting such things in the Apache >>>>>> SVN, under rave/trunk/rave-extensions, for example? >>>>> >>>>> Maybe not under trunk. But a different directory all together? >>>>> >>>>>> >>>>>> >>>>>> Pro: would provide examples for customizing and extending Rave, >>>>>> especially >>>>>> for those not familiar with Spring; would be applicable to a defined >>>>>> developer >>>>>> community (XSEDE Science Gateways) I'd like to attract to the project. >>>>>> >>>>>> >>>>>> Con: "extensions" are a slippery slope, could become a mess of disjointed >>>>>> code fragments out of sync with the main code base. >>>>> >>>>> I think it depends on how complete the solution is. If you are going to >>>>> have an entire set of classes that override/extend default Rave >>>>> implementations, but are all in support of the same purpose (science >>>>> gateways), then I could see making the case that there is a science >>>>> gateway extension. Otherwise, it would just be example code, IMO. >>>>> >>>> >>>> A fairly common practice is to have a "sandbox" area in SVN. It's >>>> ideal to do work like this that may or may not be a good idea >>>> depending on how it progresses. If someone asks "how do I do foo" we >>>> can respond "one way would be like that in the sandbox, but we're not >>>> convinced it's the best approach, your help is welcome" >>>> >>>> Ross -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOO+mAAAoJEEfVXEODPFIDr6YH+wY8ZvL3FdW3Ea+6hOEV14eP JyFxNDgBeXTVMCwDWHX9KQ8lIO49qN+nk+9Wngw+AknEW0c0N/+80toqc774ZjDY W4hRX08MwLXYuN0a/cdmStQLXwVM8Okw8JpqicUbYbvTqpF0VUKlAojTSoxwBQH6 fpqfAldfs1+1cL146jQUYNVSmdUcSYan7pd4/94qn1PsV+0HFQNaUvS05JCviJba u2/VbkUwZHS2oTFwjN70I75p6OX9f+VEWnzwXB5HgGhnoAtcznKVdg/iY3uqLMZP La2vjWOassLGRhSHy0X57BuyF4rBm5MsN/jbRTLeZYvjBWJHVmo7h48xiBcqbOE= =oEWL -----END PGP SIGNATURE-----
