Grouper Developers Forum

[Chris Hyzer <>]

I think there are two main issues here:

I would like to err on the side of keeping things simple, especially for new 
users / developers.

Let me know your thoughts,

Thanks!
Chris

##############################
First issue is getting rid of grouper build substitution.  (discussion 
follows).  I think this is an example of Gary having a useful and cool 
feature, but that most other people don't use and don't even know exists.  
This is confusing for users who don't know how / where files come from / when 
they get generated (in this case only if file isn't there I believe) / etc.  
I think it wouldn't be hard for Gary to have his own build script which does 
it for him (and share this so other people can do this if they like), but to 
keep things simple for most users and not have this in the Grouper build file 
or directory structure. I think there might be other ways to handle multiple 
envs anyways, without substitution, to have general and specific (override) 
config files.  If we want to go down that path, we should discuss maybe for 
1.5.  If there is substitution in the UI, that is not what I am talking about 
right now.

> > - there are too many config files out there, lets get rid of the
> Grouper
> > src/conf config files, and not have build process which substitutes
> > stuff.  Too many things to keep up to date
> Mmm. I like build processes which substitute stuff. I know we don't
> want
> that for a binary release - but that is a special case. The binary
> release
> itself would be constructed by an ant task. If that can take a
> parameter*
> which determines additional properties / tokens files then one base
> Grouper
> install can be used to generate multiple binary builds - release, prod,
> test, dev. 'release' would ensure relative paths
>
> *I routinely do this at Bristol with the ant script prompting for a
> build
> name (if not set as a system property) and loading a
> deploy.<name>.properties file - which is loaded first.

##################################################
The second issues is whether the grouper jar (and supporting jars and 
configs) should live with the ui/ws project or not.  Currently for WS and 
ldappc the jars live in the project, and for the UI it does not.  I think 
there are pros and cons.  As Gary mentions below, the grouper team will need 
to make sure the default config files get copied to the UI/WS project, as 
well as jars.  I think this puts the onus on the experienced Grouper team 
members, and makes it easier for a newbie to checkout a build one project 
without having to worry about dependencies.  The targets should be there to 
build from the grouper project instead (so you could keep working the way you 
do).  There is another advantage too, once we are branched on a stable 
release, we should probably keep the grouper jar as base of the branch.  This 
way if people mix and match the release numbers (e.g. 1.3.1 of UI with 1.3.0 
of the API), it will still work.  But if we always have both at tip of 
branch, then it is more chaotic what will happen if a rolled back API is 
used.  Speaking of chaos, when the UI or WS unit tests are run, and 
committed, then those test will be reproducible by the next person to check 
out the code.  If they are not tied together, then a change in the API could 
break the UI inadvertently.  I will not check the UI each time I commit API 
code, but without jars committed, I could be breaking something...  I think 
the loose coupling can be done with directory structure (e.g. 
lib/grouper/*.jar)


> > - should we do like web services/ldappc where grouper jar is in the
> > project, and there is a build script to build it in again, or get
> config
> > info from somewhere else?  Or like UI where grouper is not there, and
> to
> > build you need a grouper dir, and UI, and it will build one into the
> > other.  It gets config from the grouper dir (or I think an external
> > place?)
> The UI gets its config from the grouper dir.
>
> Early on we wanted loose coupling between the UI and the API. We also
> wanted to avoid conflicts with JARS, so common JARS go to the API. When
> working with CVS it is straightforward to set a grouper dir - and saves
> having too many conf files to maintain and duplication of files. I'm
> open
> to what we should have in a UI distribution, but for development I like
> how
> things are.