>-----Original Message----- >From: Marlon Pierce [mailto:[email protected]] >Sent: Monday, August 08, 2011 5:30 PM >To: [email protected] >Subject: Re: [discuss] non-default service implementations in svn > >-----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):
Hmm. I was able to... See if you can commit to that directory. > > >[->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+982Yvll0y >jw >sGdAhwzvSYXq+kKzmBPv3Z/DEN8TNqY3yIVY8krT9enNM0aRwyIRPE06D9jDv0 >xK >CquVq75z2e4VuJGwX9HUxDlaWeo3ABoU9kHOPhcN9J1KErHSShwLS5tj7yd5c/i >w >Yt71JDD6sGn+RstzfJWwA6kx180g3zy9I+mdw/Oh3VCgJPQAVKD2s0GtDp5/9JK >w >YzxBqS24Bi4+6TjTfqESxkdnFxX0FgQ4SQ1cdJdpkqOuAX9LUwlxrNOPYgDsyWc= >=DLGw >-----END PGP SIGNATURE-----
