Grouper Developers Forum

[Chris Hyzer <>]

Im trying to live in reality here, the only part of Grouper that uses resources is the UI.

 

The point of this is to organize the CVS project directory structure.

 

Grouper’s CVS project is the API.

 

Signet’s CVS project is the API and UI.

 

That is not apples to apples.

 

So if Signet changes its structure to the standards we are discussing, it will have directories that the Grouper API will not have (e.g. the UI dirs and resources)

 

In general though the conf or resources dir is stuff on the classpath that isn’t a java class.  Actually grouper/signet keeps hbms in the source dir (perhaps shouldn’t).  If Grouper’s API had resources (or stuff on the classpath which isn’t a config file, and isn’t a java class), I don’t think that it is a no brainer to not put it in the conf dir (or whatever we call it)… (enough negatives there for you?   translated: we might still use the conf dir for the API if there is a one-off, but the Grouper UI has so many resources I see them staying in the separate dir)

 

Kind regards,

Chris

 

From: Dave Donnelly [mailto:]
Sent: Tuesday, September 16, 2008 4:22 PM
To: Chris Hyzer
Cc: Grouper Dev
Subject: Re: [grouper-dev] standardizing build procedures

 

"... isolated to UI's..."
Not necessarily. If you want locale-specific logging
output from the API (for instance, German error messages)
then you'll want to use resources. (Unless you've hard-
coded your error messages, then it's a moot point ;-)

"... apples to apples..."
Actually Signet does distinguish API and UI with two
separate resource files: signetResApp.properties and
signetResUi.properties.
I'm not sure what you mean by "API and UI all in one."
They are separate jars, but they are generated from a
single project/build.

--Dave



Chris Hyzer wrote:

So resources are generally isolated to UI’s… (im sure there are outliers)

 

In ldappc there is a conf and a resources dir, and both are used for config stuff.

 

Comparing signet and grouper is not apples to apples since signet has the API and UI all in one.

 

So Grouper API would generally not have resources, only conf.  Grouper UI, and signet, would have conf and resources.  As long as there is not something in maven that requires us to have a conf and resources dir…

 

Thanks,

Chris

 

From: Dave Donnelly []
Sent: Tuesday, September 16, 2008 3:48 PM
To: Chris Hyzer
Cc: Tom Zeller; Grouper Dev
Subject: Re: [grouper-dev] standardizing build procedures

 

There is a distinct difference (in my mind, anyway) between
configuration settings and resources. Config stuff is used
by the application(s) to get configured: what DB to use,
timeout settings, what resources to load, etc.
Resources, on the other hand, are typically locale-specific:
error messages in multiple languages, graphics, etc.

If you take a look at the JavaDoc for ResourceBundle
you'll see what I mean.

Having said all that, we should definitely keep both
config and resources, and keep them in separate directories.

--Dave




Chris Hyzer wrote:

We have /conf, and /src/conf… I think we only need one, and it should be the maven convention (if this is the maven convention J )…    /conf    (though I don’t know how /conf differs from /src/main/resources)…

 

When I said “get rid of /src/conf”, I meant delete it, and move any non redundant files to /conf

 

I wasn’t suggesting collocating grouper and ldappc or signet.

 

As far as relocating the hsql configs, if we want the binary to work when it starts, maybe they should be in the /conf dir… hmm

 

Chris

 

 

 

From: [] On Behalf Of Tom Zeller
Sent: Monday, September 15, 2008 4:54 PM
To: Chris Hyzer
Cc: Grouper Dev
Subject: Re: [grouper-dev] standardizing build procedures

 

Agreed, we (of course) shouldn't need a build tool (ant, maven, whatever) to run a binary release.

 

I wasn't sure what you meant by "get rid of" src/conf, and I think I'll understand that as "remove src/conf from the build process" :)

 

I also thought maybe you were suggesting colocating ldappc and grouper conf directories, maybe even signet. I'll admit to not being a grouper-expert, but I have spent some time there, and I often become confused running grouper+ui+ldappc and making sure all the various configs are correct and consistent when working with different test setups, database backends, and code versions. I'm not sure what magic can correct my confusion, though.

 

It would be nice to relocate the hsql configs (server.properties, sqltool.rc) out of the way, maybe to a 'quickstart' or 'test' directory.

 

TomZ

 

On Mon, Sep 15, 2008 at 3:26 PM, Chris Hyzer <> wrote:

Btw, it's a less valuable binary release if we have to search and replace config files, right?  Would be better if they were just ready…

 

Chris

 

From: Chris Hyzer
Sent: Monday, September 15, 2008 1:51 PM
To: 'Tom Zeller'

Cc: Emily Eisbruch; Grouper Dev

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

 

I was hoping we could just get rid of that process, and for things that did need replacing, finding workarounds.  Like for absolute paths in files, just use relative paths.  It will work for logs, but will this work for the hsqldb url?  Anything else in there that is replaced that prevents us from getting rid of it?

 

Chris

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Monday, September 15, 2008 12:49 PM
To: Chris Hyzer
Cc: Emily Eisbruch; Grouper Dev
Subject: Re: [grouper-dev] standardizing build procedures

 

On Sun, Sep 14, 2008 at 10:28 PM, Chris Hyzer <> wrote:

- 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

- 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 

Do you have a proposal for replacing the src/conf configs ? What do you have in mind  ?