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: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] standardizing build procedures
  • Date: Wed, 24 Sep 2008 16:15:01 +0100

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


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
> 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
that for a binary release - but that is a special case. The binary
itself would be constructed by an ant task. If that can take a
which determines additional properties / tokens files then one base
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
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
> info from somewhere else? Or like UI where grouper is not there, and
> 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
to what we should have in a UI distribution, but for development I like
things are.

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page