Grouper Developers Forum

[Kathryn Huxtable <>]

If we're willing to have a flag day where we copy the grouper CVS repository to an "old" repository, you can move the files around on the actual CVS system, preserving change

history. It just means that old versions will have to be checked out of the old repository, since they won't be in the correct locations in the new one.

That's what I'd do, because I like preserving change history more than I like preserving repository integrity, and since it's easy to make an old copy.

Of course, if we were using subversion, this wouldn't be an issue since it handles moves.

-K

On 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