Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] standardizing build procedures

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] standardizing build procedures

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "GW Brown, Information Systems and Computing" <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] standardizing build procedures
  • Date: Tue, 23 Sep 2008 01:27:51 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

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,


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.

> > - 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.

Archive powered by MHonArc 2.6.16.

Top of Page