Grouper Developers Forum

[Kathryn Huxtable <>]

Well, I don't want any project to mavenize that doesn't want to  
mavenize, but thanks for the nice comments.

I assume when you mention foreign-looking directories that you are  
either referring to the i2mi-repository directory or to the assembly,  
checkstyle, and site directories in the src directory. The former are  
a simple in-file Maven repository containing some jars we need that  
aren't in the standard Maven repository. The latter are files that  
configure the packaging for the deployment, binary, source, and site  
assemblies, configures the checkstyle format, and contains the wiki- 
like format for site documentation.

I'm not entirely happy with Maven/Apache's APT wiki-like format. I'd  
much rather use something else, but I haven't found anything I like  
better, except docbook, which is intensively complicated. And Apache  
is using APT, which means there's a lot of it out there and it will be  
well supported.

As far as maintenance goes, it's not much different than anything else.

-K

On Aug 8, 2008, at 6:37 PM, Neil Matatall wrote:

> I just checked out the Mavenized ldappc code and I have to say that  
> I am quite impressed.  I had never used Maven before.  I only knew  
> what it did on the surface.  And I love it already.
>
> I can imagine there is quite a bit of overhead when initially  
> mavenizing a project and I know nothing about the upkeep.  But from  
> a developers standpoint, I have had a much better experience setting  
> up the ldappc project than any other.
>
> Checkout->Download and add Maven to the PATH->mvn->done.  Easy.  I  
> literally did nothing else.
>
> Although it does take a long time to download the dependencies.   
> This is a one time cost that I am fine with.  My only other  
> complaint is that there are few files/directories that I'm assuming  
> are maven-related that look very foreign to me.  Count one vote for  
> mavenizing everything :)
>
>
> Kathryn Huxtable wrote:
> > Yep. I agree 100%.
> > BTW, I have renamed the CVS projects. The old 1.1.1 version is now  
> > ldappc-old and the new 1.2.0 version is ldappc. I have added  
> > information to this effect in the wiki.
> > -K
> > On Aug 7, 2008, at 9:59 AM, Tom Barton wrote:
> > > I agree that the overriding issue from the deployer's perspective  
> > > is lack of sufficient integration among grouper, signet, subject,  
> > > and ldappc. It's not how they each are built, it's their combined  
> > > deployment footprint and configuration. Fixing this is one of the  
> > > hardest items remaining on the combined signet & grouper roadmap.
> > >
> > > So I too don't wish to add complexity from the deployer's  
> > > perspective. I hope that Ldappc, like Subject API, being delivered  
> > > as a binary (with source available) will avoid the need for most  
> > > deployers to use an additional build tool.
> > >
> > > Tom
> > >
> > > Michael R. Gettes wrote:
> > > > Dave, I agree change for the sake of change is not
> > > > desirable.  I just don't buy the consistency argument.
> > > > Especially, from my experiences with COmanage,
> > > > things are already not consistent, by any stretch.
> > > > /mrg
> > > > On Aug 7, 2008, at 1:59 AM, Dave Donnelly wrote:
> > > > > Shibboleth may be mavenized, but Ldappc is being *used*
> > > > > with Grouper and Signet, both of which use Ant. So I
> > > > > would have to agree with Mike O. regarding consistency.
> > > <tbarton.vcf>