-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duh, I used http instead of https in svn commands. Mystery solved.
Marlon On 8/8/11 6:35 PM, Franklin, Matthew B. wrote: >> -----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 >> > 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/ iQEcBAEBAgAGBQJOQSK6AAoJEEfVXEODPFID7hcH/0DNHynU6nj4he+bfS8edI00 AMaP5+uNK/P8pIdfDLm/lq0CuFMyqUUpFmp9Qd9G8RLkVZ9qJO9nFCaJIWrXRziv 9FY2pvv9ObLg2129k0ZQtVi4vqLc09mzQLu0M1mMrci8JoiaBXSa0uNF2/n6xIEl RY894eaNJ+PDcUDcZ4dk6huw4zUhxTS085uk7jvJnjdUS7ElHfKLe87Abt7CkJDG F7GIsrI6a+1LMituiQ/PP72INphTE9jEj0v01sySsjhYGmJ+hH188Dd9v2WndGUU jf+LCZS0+YfEMzfSXGTbAxOWkfOnWIGqyQHInFMz7RjwCmXNsa2L/BG8QR1UU+8= =lBSL -----END PGP SIGNATURE-----
