Grouper Developers Forum

[Tom Barton <>]

Sounds like upsides outweigh downsides. Go for it. -Tom

Chris Hyzer wrote:
> 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
>
>