You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Marlon Pierce <mp...@cs.indiana.edu> on 2011/08/04 21:16:30 UTC
[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?
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.
Marlon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOOvAOAAoJEEfVXEODPFIDgE4H/3d37ptn48zT3sP9NxLz8AfV
u8jPVKQ9TWevieCgTlI9cbgGrfIrdu/aX1sQBdZiUCulCwp0Vd1fGvJWbFuNfYzY
mNvnb7f4WrxM6uqqs8FpLUyek6SBrVc3ZJfyjV1Aq9ejqWDShQJhNkVNd1qdEyEn
9OVm7aEnTjNroxO1hKUF7fzDktsdghBUlDkIxRT6M2V66sOYNNb61jbD0SoBDmZP
V1PV5ueK0Yu6S4LD0Y3YspWlUo7q50ktx3LCb/pCZyIG+nh9Q9ADB3bggllmn+T+
0VswKgTqd0ASI3WGEqokQTJ0+Uh0rpKIHqTMeb+CY0W72ch9op655TNxVf4fIOg=
=0IkE
-----END PGP SIGNATURE-----
Re: [discuss] non-default service implementations in svn
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks, Ate. Changing over the service implementation is easy enough. Some additional jars (also used in Apache Airavata incubator) will be required. I'll start out in the sandbox, and then we can see if my changes are appropriate for some place in trunk.
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.<mf...@mitre.org> wrote:
>>>>>> -----Original Message-----
>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>> Sent: Thursday, August 04, 2011 3:17 PM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> 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/
iQEcBAEBAgAGBQJOO+mAAAoJEEfVXEODPFIDr6YH+wY8ZvL3FdW3Ea+6hOEV14eP
JyFxNDgBeXTVMCwDWHX9KQ8lIO49qN+nk+9Wngw+AknEW0c0N/+80toqc774ZjDY
W4hRX08MwLXYuN0a/cdmStQLXwVM8Okw8JpqicUbYbvTqpF0VUKlAojTSoxwBQH6
fpqfAldfs1+1cL146jQUYNVSmdUcSYan7pd4/94qn1PsV+0HFQNaUvS05JCviJba
u2/VbkUwZHS2oTFwjN70I75p6OX9f+VEWnzwXB5HgGhnoAtcznKVdg/iY3uqLMZP
La2vjWOassLGRhSHy0X57BuyF4rBm5MsN/jbRTLeZYvjBWJHVmo7h48xiBcqbOE=
=oEWL
-----END PGP SIGNATURE-----
Re: [discuss] non-default service implementations in svn
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----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:mpierce@cs.indiana.edu]
>> Sent: Monday, August 08, 2011 5:30 PM
>> To: rave-dev@incubator.apache.org
>> 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.<mf...@mitre.org>
> wrote:
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>>>>> Sent: Thursday, August 04, 2011 3:17 PM
>>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>>> 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-----
RE: [discuss] non-default service implementations in svn
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>Sent: Monday, August 08, 2011 5:30 PM
>To: rave-dev@incubator.apache.org
>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.<mf...@mitre.org>
>wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>>> Sent: Thursday, August 04, 2011 3:17 PM
>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>> 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-----
Re: [discuss] non-default service implementations in svn
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----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.<mf...@mitre.org> wrote:
>>>>>> -----Original Message-----
>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>> Sent: Thursday, August 04, 2011 3:17 PM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> 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-----
Re: [discuss] non-default service implementations in svn
Posted by Ate Douma <at...@douma.nu>.
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.<mf...@mitre.org> wrote:
>>>> -----Original Message-----
>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>> Sent: Thursday, August 04, 2011 3:17 PM
>>>> To: rave-dev@incubator.apache.org
>>>> 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-----
Re: [discuss] non-default service implementations in svn
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I like the sandbox idea--this would be rave/sandbox in SVN?
On 8/4/11 5:29 PM, Ross Gardler wrote:
> On 4 August 2011 21:59, Franklin, Matthew B. <mf...@mitre.org> wrote:
>>> -----Original Message-----
>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>> Sent: Thursday, August 04, 2011 3:17 PM
>>> To: rave-dev@incubator.apache.org
>>> 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-----
Re: [discuss] non-default service implementations in svn
Posted by Ross Gardler <rg...@opendirective.com>.
On 4 August 2011 21:59, Franklin, Matthew B. <mf...@mitre.org> wrote:
>>-----Original Message-----
>>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>Sent: Thursday, August 04, 2011 3:17 PM
>>To: rave-dev@incubator.apache.org
>>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
RE: [discuss] non-default service implementations in svn
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>Sent: Thursday, August 04, 2011 3:17 PM
>To: rave-dev@incubator.apache.org
>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.
>
>
>Marlon
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJOOvAOAAoJEEfVXEODPFIDgE4H/3d37ptn48zT3sP9NxLz8Af
>V
>u8jPVKQ9TWevieCgTlI9cbgGrfIrdu/aX1sQBdZiUCulCwp0Vd1fGvJWbFuNfYzY
>mNvnb7f4WrxM6uqqs8FpLUyek6SBrVc3ZJfyjV1Aq9ejqWDShQJhNkVNd1qdE
>yEn
>9OVm7aEnTjNroxO1hKUF7fzDktsdghBUlDkIxRT6M2V66sOYNNb61jbD0SoBDm
>ZP
>V1PV5ueK0Yu6S4LD0Y3YspWlUo7q50ktx3LCb/pCZyIG+nh9Q9ADB3bggllmn+T
>+
>0VswKgTqd0ASI3WGEqokQTJ0+Uh0rpKIHqTMeb+CY0W72ch9op655TNxVf4fI
>Og=
>=0IkE
>-----END PGP SIGNATURE-----