Grouper Developers Forum

[Tom Barton <>]

Thanks Chris. One clarification: with the designations grouper-ui for 
the UI project and grouper-ws for the WS project, are options 1-3 below 
meant to be

1. grouper-ws is its own cvs project with its own libs & config.

2. grouper-ws is its own cvs project sharing libs and config with 
grouper-ui, ie, union of UI and WS needs.

3. grouper-ws is a part of the grouper-ui project, with configuration & 
build options to stand up the UI alone, the WS alone, or both.

I'm currently leaning towards #1, but keeping in mind that we really 
need to adopt Spring or the like across the i2mi wares (grouper-*, 
signet-*, subject api, ldappc) which promises to remove the additional 
complexity of managing separate grouper-ws config and libs.

Tom

Chris Hyzer wrote:
> 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