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: Thu, 18 Sep 2008 09:06:28 +0100

Comments below.


--On 14 September 2008 23:28 -0400 Chris Hyzer <> wrote:

I have some ideas (hopefully the best of each project), and we can do to
make all the projects more similar. Some of these are action items, some
are just best practices going forward... we should probably discuss so I
can clarify the ones that don't speak for themselves...

- projects be named by what branch they are in so that multiple branches
can be opened at once. the HEAD branch should be _HEAD?

- e.g. grouper_HEAD, grouper_v2_3
OK (this is for Eclipse?)

- projects should have .project files and .classpath files that are
complete and dont need to be edited (drivers? can we commit them in
different dir?)
Not sure you can do this unless you reference a separate project e.g. grouper_HEAD_local, which a user has to set up with the JARs they want. Goes beyond database drivers - source adapter implementations, hooks...

As it happens I tend to create a single project that has both the UI and API together.

- rename jars to be the name of the jar without version, and make sure
the version is in the manifest (so cvs can version)
OK - would then be good if a script could generate a readme.txt with the concatenation of all the manifests so we don't need to maintain by hand

- grouper build lib shouldnt keep putting old libs in same dir, only
grouper.jar. We can backup grouper jars to a different dir (with date

- all jars should have source files inside if possible

- dont have source dirs inside other source dirs. label all source dirs
explicitly, not in

- dont have source dirs under libraries (cant see them as easily in

- files that need changing should be .example.ext files, where ext is the
files extension. the ant script should copy to the right place and
rename if not there

- project names should be lower case

- config resources should be like ldappc (maven) in the "conf" dir, or
the resources dir for that src listing, e.g. src/main/resources. Note,
is "conf" a maven standard, why is conf != resources
As per Dave's thoughts I think conf and resources are separate. The Grouper API may not have resources just now, but at some point we may need to localize error messages and prompts, so it should be clear where future resources go

- build file should be in base dir, and should be named
(or The build file is not available at
runtime, only at build time.

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

- there should be directories under lib, with libs in there, to keep
things organized (see ws). In grouper we have lib, and libAnt, but it
should be lib/grouper and lib/ant. (see WS for example)

Do we want a lib/custom or similar where site specific jars go?

- source dir should look like maven (see ldappc): e.g. src/main/java,

- result should go to "dist", and subdirs for whatever. e.g.

- "bin" dir for executable batch and shell scripts

- "contrib" dir for contributions that live in the source repository
(e.g. UI)

- javadoc goes to "doc/api" dir. Should we keep this in CVS so it will
be real time, versioned, and branched?
Could do though not absolutely necessary - if you get a tagged version and run the javadoc task it should be reproducible.

We should include the javadoc in a binary release.

If we switch to subversion at some point a lot of links might break


- if j2ee web app, keep web files in "webapp"

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

- ant scripts should have a menu which defaults to the previous choice
(like UI)

- "build/eclipse" should be used by eclipse to compile java/resources

I think ant eclipse integration has come a long way since I first set up the UI. In principle I would like to ensure that targets be callable in Eclipse

- "build/ant" dir should be used by ant to compile stuff, or do whatever.
should have subdirs to organize

- projects should have a README.txt in the base dir which explains what
the project is and how to get up and running, and anything else important
(wiki links, etc)

From: Emily Eisbruch
Sent: Friday, September 05, 2008 9:16 AM
To: Grouper Dev
Subject: [grouper-dev] Draft minutes: Grouper Call 3-Sep-08

**Grouper Call 3-Sep-08**


Tom Barton, Chair

Gary Brown, Bristol U.

Shilen Patel, Duke

Chris Hyzer, U. Penn

Bill Kasenchar, U. Penn

Tom Zeller, U. Memphis

Dave Donnelly, Stanford

Joy Veronneau, Cornell U.

RL "Bob" Morgan, U. Washington

Steve Olshansky, Internet2

Emily Eisbruch, Internet2 (scribe)

New Action Items

[AI] {Chris} will make the encrypted password function external to

[AI] {TomZ} will create a JIRA issue summarizing today's discussion on
handling of utilities by gsh.

Carry Over Action Items

[AI] {Chris} will create a proposal for using a shell script to make

[AI] {Chris} will develop guidelines for standardizing build script
procedures across the I2 middleware products.

[AI] {Kathryn} will do background research on a messaging system to be
used as a test/example case for hooks.


Grouper Release 1.3.1.

Grouper Release 1.3.1 is ready for final testing and packaging, with all
JIRA items having been marked completed. Chris will test web services;
Chris, TomZ, and Shilen will do unit testing. Chris will tag the code for
the 1.3.1 release in CVS and inform TomB.

Binary Format for Grouper 1.4

Binary format will be considered for Grouper 1.4, not for this 1.3.1

Documentation for 1.3.1

Shilen welcomes feedback on his Bad Membership Finder utility
documentation at:

Gary will edit the documentation on the Grouper wiki for API
configuration changes in Grouper 1.3.1.

Encrypting passwords in config files


Encrypting passwords in config files was deferred, to be reconsidered
along with the release of Subject 1.0. This deferral decision was based
on concern about creating a need for Grouper customized versions of 3rd
party source, such as JDBC source files. However, it makes sense now to
proceed with putting encrypted passwords in a separate JAR.

[AI] {Chris} will make the encrypted password function external to


What are the potential impacts of cleaning up and removing some indexes,
as suggested in GRP-146?

There is a risk that indexes that we consider redundant are not actually
redundant in all cases. Making some indexes optional through a
configuration file was discussed. There is a need to understand how
various databases use indexes. The decision was not to make changes to
indexes for 1.4. Soon after 1.4, it might make sense to develop
test/benchmark databases to be able to make a future determination on
this issue.

Packaging of Utilities

The consensus was to use gsh for storing utilities.

Utilities for 1.4 will include those needed to replace Apache Ant (Scheme
export, run test, export import, XML, etc.), Bad Membership Finder, and

TomB noted it will be important to maintain a wiki page or interactive,
built-in help so people know what utilities are in gsh.

[AI] {TomZ} will create a JIRA issue summarizing today's discussion on
handling of utilities by gsh.

Next call: Wed 17-Sep-08 Noon EDT.

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page