Grouper Developers Forum

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

Comments below.

Gary

--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
> stamp)
OK
> - all jars should have source files inside if possible
OK
> - dont have source dirs inside other source dirs.  label all source dirs
> explicitly, not in
OK
> - dont have source dirs under libraries (cant see them as easily in
> eclipse)
OK
> - 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
OK
> - project names should be lower case
OK
> - 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 build.properties
> (or build.example.properties).  The build file is not available at
> runtime, only at build time.
OK
> - 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)
OK

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,
> src/test/resources
OK
> - result should go to "dist", and subdirs for whatever.  e.g.
> dist/grouper.jar
OK
> - "bin" dir for executable batch and shell scripts
OK
> - "contrib" dir for contributions that live in the source repository
> (e.g. UI)
OK
> - 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
>   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"
OK
> - 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.

> - ant scripts should have a menu which defaults to the previous choice
> (like UI)
OK
> - "build/eclipse" should be used by eclipse to compile java/resources
OK

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
OK
> - 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)
OK
> 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+Fi
> nder+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 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
> 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.



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