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
