Grouper Developers Forum

["Tom Zeller" <>]

I like the idea of further package organization, although we'll probably need to agree on the details.

Perhaps while were changing lots of things, we should change even more, such as bringing gsh and usdu (and the loader ?) into the API ?

On Wed, Jul 9, 2008 at 1:33 PM, Chris Hyzer <> wrote:

Hey,

 

Im just thinking that once we roll out hooks, organizations will need to start navigating the grouper API.  Right now the base package has 135 java classes in it.  I think it would be a good idea to organize these into sub-packages.

 

e.g.

edu.internet2.middleware.grouper.beans (e.g. Group, Member)

edu.internet2.middleware.grouper.config (e.g. GrouperConfig)

edu.internet2.middleware.grouper.beans.finder (e.g. GroupFinder)

edu.internet2.middleware.grouper.exception (e.g. GrantPrivilegeException)

edu.internet2.middleware.grouper.filter (e.g. GroupAttributeFilter)

edu.internet2.middleware.grouper.log (e.g. EventLog)

edu.internet2.middleware.grouper.registry (e.g. RegistryInstall)

edu.internet2.middleware.grouper.validator (e.g. BaseQueryValidator)

edu.internet2.middleware.grouper.xml (e.g. XmlReader)

 

The upsides are:

1.       Grouper will be easier to maintain for the Grouper team

2.       Grouper hooks will be easier to use

3.       This is more in line with industry standard

 

The downsides are:

 

1.       CVS diffs harder (I was waiting for 1.4 to do major changes… plus there are so many diffs in files from the rework lately its less of a concern)

2.       Java security (package level wont protect methods as well, more public methods… I think this is ok since it is good hook implementers have more access, they will just need to be prepared to recompile every once and a while, we can help them with what to change as methods are changed or deprecated)

Again, after we roll out hooks, changes like this are harder to make.  So I suggest we do this for 1.4.  Any other API simplifications to make for 1.4?  Thoughts on this one?

 

Thanks,

Chris