Grouper Developers Forum

["Michael R. Gettes" <>]

All,

I have been putting up grouper for a new collaborative org environment.

As compared to my experience with grouper 1.0 - this time around went
much easier.  Yes, i am more experienced with grouper but I did try to
come at it from an "idiot" perspective - and I know many of you will
agree I am aptly suited to play the role of the idiot.

I did NOT use the quickstart.  I did all this from scratch and with the
downloaded tarball.  Here are some observations...

the relationship between the grouper-ui and grouper was a little  
confusing.
I think some documentation to explain this might be more helpful -  
you need
to build the UI (dist) in order to finally see the combined environment.
Before, if i recall correctly, you built the api and put in some "dist"
location.  You then built the UI and combined it with the api.  For the
future, it would be nice to see a cleaner separation of the two.  Why?
I still need to think this thru a bit - but I am wanting to have  
multiple
grouper installations on the same box.  This way, I could a single api
build with hopefully a single dist... then have a single UI build with
multiple dist locations - each with the appropriate config for the  
differences.
For me, the perspective would be a UI is configured to go against an API
and the UI tells the API about the database/etc config.  The API is  
just a pivot
point (if that makes sense).  This allows for multiple UI to against  
a single
API dist but still have multiple databases for N presences of grouper  
on a box.
If you buy all this - then the grouper-ui needs some easier knobs to  
control
where the dist is placed and to maintain its own copy of the conf,  
for the api
and that conf goes into the UI dist as well.

The grouper shell appears to be bound in the build dir for API - the  
grouper shell
really is, at least to me, just a simple UI.  So, the grouper shell,  
which is an important
core aspect of grouper, needs to be part of the api dist but, executable
from the UI dist to pick up the conf differences (if you buy  
everything I have
said above).

tomcat - tomcat5 on redhat5 installed by rpm (yum) - don't use it.   
just go get
the tomcat from apache, install it and go.  it would be nice if  
tomcat would
respect "include" files (does it?) and then just tell it to include  
the context.xml
instead of having to copy it in - again, i am thinking of many  
grouper on the same
box.

I really like the "act as admin" ability if you are in etc:wheel -  
this made my
life MUCH easier from the 1.0 build.  THANK YOU!  I can see where the  
future
signet integration will fit now.  I look forward to it!

it should be noted that much of what i write here is about future  
stuff - this
shows things went pretty well this time around.  This is good!

We need to pay attention in the wiki doc - there are still some  
references to archived
pages as part of the production version - not clear to me if these  
should be changed.
gsh doc is on google and it should be on the internet2 wiki since  
this is part of
the base product.  this confused me a bit.

I suggest adding some doc around making sure ANT is sane.  As I  
learned from Tom Scavo,
if "ant -diagnostics" doesn't return a bunch of valid jars in the  
"jar listing"
section - then you need to go get the latest ant from  
ant.apache.org.  Simple to
install - just put that untar'd directory somewhere and prepend it to  
your path and
make sure ANT_HOME is set to the new ant dir and your done (the ant  
doc is not
clear on HOW to install - hence these notes).

and if you read this far - does anyone have an init.d script for  
tomcat running
under an arbitrary user I can use without assumptions of the normal  
tomcat5 rpm being
installed?

I hope this helps.

Now on to ldappc....  this i know has not been made easier.  :-(

/mrg