Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 23 September 2008 01:27 -0400 Chris Hyzer <> 
wrote:

> 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.
I don't have anything fancy set up for Grouper right now - I'm not 
routinely building for dev, beta and production. I agree I can add 
something later if I want, so, for the API we can do without the 
substitution.
> > > - 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)
I'm still not convinced we want to replicate the jars and config. Most 
users will work with the distributions on the Wiki. I'm happy to have a UI 
dist which includes the (binary?) API, but that can be assembled at release 
time - a variation on the QuickStart builder.

Any non core developer checking out from CVS should be working with a 
specific version - we make no guarantees that HEAD will work, and, quite 
often, the UI and API will be out of synch. We only guarantee that 
equivalent versions of UI and API work together, though it is possible, for 
minor revs, that most or all of the features will work together.
> > > - 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.



----------------------
GW Brown, Information Systems and Computing