-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks like I don't have write permission to add the sandbox directory to rave (that is, can't create http://svn.apache.org/repos/asf/incubator/rave/sandbox):
[->svn commit sandbox/ -m "(RAVE-161) Import sandbox" subversion/libsvn_client/commit.c:873: (apr_err=175002) svn: Commit failed (details follow): subversion/libsvn_ra_dav/util.c:296: (apr_err=175002) svn: MKACTIVITY of '/repos/asf/!svn/act/852c1c1e-05aa-0410-8ab8-e59c61b1489b': 403 Forbidden (http://svn.apache.org) 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/ iQEcBAEBAgAGBQJOQFU6AAoJEEfVXEODPFIDg0oH/iZqtQ1ZnY0p8gji8o96KY1g cPzcf8t95P/eNOYoE7Zho3mVWG0NMUZDH6GoGkFy0Z7YYfGqWv3j+982Yvll0yjw sGdAhwzvSYXq+kKzmBPv3Z/DEN8TNqY3yIVY8krT9enNM0aRwyIRPE06D9jDv0xK CquVq75z2e4VuJGwX9HUxDlaWeo3ABoU9kHOPhcN9J1KErHSShwLS5tj7yd5c/iw Yt71JDD6sGn+RstzfJWwA6kx180g3zy9I+mdw/Oh3VCgJPQAVKD2s0GtDp5/9JKw YzxBqS24Bi4+6TjTfqESxkdnFxX0FgQ4SQ1cdJdpkqOuAX9LUwlxrNOPYgDsyWc= =DLGw -----END PGP SIGNATURE-----
