On 08/04/2011 11:32 PM, Marlon Pierce wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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/
iQEcBAEBAgAGBQJOOxABAAoJEEfVXEODPFIDBXkH/0rG4vGSmvJx/dqNoyDcHvOT
y0Ik89lIIsLezGHdaPD/9btZuh7GHZ6D/jiU7YLGWwGAad58Qb/dBaDHHtd07IjN
qsJY4I6J+O+ugFp/zdtIw2n1lm63cZOsBRESHxZKcFlOu7blpMC9uBgqtWXRvVMI
fbXND4KGj8gQgPbMIHqcltuXgj5bMtMQ0MAM8NoUHZTjyxwctvedM7lAankkoTe9
Dwuajlg/e847jF1rbajRTa57Dhy5k6YG6N0KFCdFC5wg3nNvuxKqVZhr3eOmFjFH
ep0YosXKEu1rbVECDVzuCWXF8zK5hjolfFcAib8OhK4LZn86sOgkpivgqSfRxW4=
=Rt1q
-----END PGP SIGNATURE-----
