Grouper Developers Forum

[Chris Hyzer <>]

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

 

- 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?)

 

- rename jars to be the name of the jar without version, and make sure the version is in the manifest (so cvs can version)

 

- 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 stamp)

 

- 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 eclipse)

 

- 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

 

- build file should be in base dir, and should be named build.properties (or build.example.properties).  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

 

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

 

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

 

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

 

- "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?

 

  e.g. http://viewvc.internet2.edu/viewvc.py/grouper-ws/grouper-ws/doc/api/index.html?root=I2MI&view=co&pathrev=HEAD

 

- 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 place?)

 

- 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

 

- "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 [mailto:]
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**

 *Attending*

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

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

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

Discussion

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

https://mail.internet2.edu/wws/arc/grouper-dev/2008-08/msg00058.html

Documentation for 1.3.1

Shilen welcomes feedback on his Bad Membership Finder utility documentation at:  https://wiki.internet2.edu/confluence/display/GrouperWG/Bad+Membership+Finder+Utility

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

Encrypting passwords in config files

(https://bugs.internet2.edu/jira/browse/GRP-122)

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 3^rd 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 Grouper.

Indexes

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

https://bugs.internet2.edu/jira/browse/GRP-146

https://mail.internet2.edu/wws/arc/grouper-dev/2008-09/msg00013.html

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

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.