Grouper Developers Forum

[Chris Hyzer <>]

FORGET THAT LAST EMAIL, Let me do this again, I am mixing up my acronyms (ui 
and ws)...

Hey,

Tom, Gary and I have been discussing where the web services code will live.  
The options are:

1. In its own project with different library versions than grouper-ui
2. In its own project with the same library versions as grouper-ui
3. In the grouper-ui project with a config switch to turn off either the ui 
or ws or run both

If you want to give me your vote, and I will tally them (Tom and Gary, please 
also vote since I added an option), or if you want to give more info to the 
list feel free.  I will tally the votes in 48 hours.

Let me see if I can list the pros and cons in an unbiased fashion (this is 
always the hardest part of my job :)  ):

Flexibility of deployment (can share config, log files, will make quickstart 
all inclusive, etc):
- #2, #3 is better since you can run either the ws, or the ui, or both

Ease of maintenance by grouper team (as far being able to upgrade a jar in 
one project vs another):
- #1 better if completely separate

Ease of maintenance by the grouper team (as far as being able to change code 
in one without affecting the other):
- #1 and #2 are better to change code

Ease of deployment:
- #3 is better since you have one warfile to deploy, and can change the 
config to turn off the ui or ws if you like.

Ease of maintenance by grouper team (as far as duplication of projects, build 
scripts, etc):
- #3 better if shared with grouper-ui

Being able to build the webapp without ws or ui (there are 15 megs of ws jars 
(down to 12 jars) that make the warfile big (granted classes are only loaded 
when accessed, so the memory footprint wouldnt matter):
- #1 and #2 are better

Others?

Thanks,
Chris

> -----Original Message-----
> From: Chris Hyzer 
> [mailto:]
> Sent: Thursday, January 10, 2008 10:44 AM
> To: Grouper Dev
> Subject: [grouper-dev] Where the web services will live
>
> Hey,
>
> Tom, Gary and I have been discussing where the web services code will
> live.  The options are:
>
> 1. In its own project with different library versions than grouper-ws
> 2. In its own project with the same library versions as grouper-ws
> 3. In the grouper-ws project with a config switch to turn off either
> the ui or ws or run both
>
> If you want to give me your vote, and I will tally them (Tom and Gary,
> please also vote since I added an option), or if you want to give more
> info to the list feel free.  I will tally the votes in 48 hours.
>
> Let me see if I can list the pros and cons in an unbiased fashion (this
> is always the hardest part of my job :)  ):
>
> Flexibility of deployment (can share config, log files, will make
> quickstart all inclusive, etc):
> - #2, #3 is better since you can run either the ws, or the ui, or both
>
> Ease of maintenance by grouper team (as far being able to upgrade a jar
> in one project vs another):
> - #1 better if completely separate
>
> Ease of maintenance by the gruoper team (as far as being able to change
> code in one without affecting the other):
> - #1 and #2 are better to change code
>
> Ease of deployment:
> - #3 is better since you have one warfile to deploy, and can change the
> config to turn off the ui or ws if you like.
>
> Ease of maintenance by grouper team (as far as duplication of projects,
> build scripts, etc):
> - #3 better if shared with grouper-ws
>
> Being able to build the webapp without ws or ui (there are 15 megs of
> ws jars (down to 12 jars) that make the warfile big (granted classes
> are only loaded when accessed, so the memory footprint wouldnt matter):
> - #1 and #2 are better
>
> Others?
>
> Thanks,
> Chris