Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] organize the grouper java package structure

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] organize the grouper java package structure


Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-dev] organize the grouper java package structure
  • Date: Wed, 9 Jul 2008 13:56:29 -0500

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




Archive powered by MHonArc 2.6.16.

Top of Page