Grouper Developers Forum

[Chris Hyzer <>]

Regarding Kathryn’s response:

The history is still in CVS, its just not in that file’s history, its in the Attic.  If you don’t want to compare with a particular Attic version, you could checkout the project from the tag we use before making the change (or any tag or date), and have the same experience as what you describe (without the copy of the repository)…  if it didn’t work that way, moving a file would destroy other branches…  sound good?

 

Regarding TomZ’s response:

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

I think this would be useful.  I think GSH would require one more jar added to grouper, and the loader would too; usdu no more jars.  I think it would make everything more stable.  (i.e. have we tested that GSH 1.3.4 works with API 1.3.0?  Maybe we used a method in GSH 1.3.4 that was added in the API v1.3.2 and we don’t know until it fails for someone)…  also it would make refactoring and releases easier…  fewer build scripts to maintain, fewer binary zip files in cvs (gsh.zip), easier to run all unit tests at once, etc

 

For the UI and WS there are many more jars to add, so I can see why those would be separate…

 

Thanks,

Chris

 

From: Kathryn Huxtable [mailto:]
Sent: Wednesday, July 09, 2008 2:56 PM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-dev] organize the grouper java package structure

 

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