Grouper Users - Open Discussion List

[Chris Hyzer <>]

My understanding of why we aren't using Maven is that it isn't a silver 
bullet over ant (there are pros and cons), and we would rather spend a few 
resources standardizing some build files / tasks / dir structure than 
completely reimplementing a build tool (which I would think would be a larger 
task).  When I google maven vs ant it seems like not everyone prefers 
maven...  if we were starting from scratch we might have a different 
direction, but we already have an install base with ant.

http://raibledesigns.com/rd/entry/maven_vs_ant

Either way, I think we need to make a final decision and we can all go in 
that direction for a while (I thought we had a decision the last time we 
discussed it with the grouper team, but maybe not).

Thanks!
Chris

> -----Original Message-----
> From: Kathryn Huxtable 
> [mailto:]
> Sent: Thursday, April 03, 2008 2:52 PM
> To: Michael R. Gettes
> Cc: GW Brown, Information Systems and Computing; Chris Hyzer; Grouper
> Users; Signet Users
> Subject: Re: [signet-users] Re: [grouper-users] ldappc build question
>
> We're not using Maven because I'm not an evangelist and haven't
> seriously tried to push it.
>
> The Apache project uses it and we used it at KU for many projects, but
> not for all. Identity Management used it, when that unit existed.
>
> There are people in I2 such as Chad LaJoie (for instance) who can't
> stand Maven.
>
> Okay, I'm not an evangelist, but I'll put together something by the
> time of the I2 meeting that I can share about the benefits of Maven
> and also some of its less nice features.
>
> And to be fair to Chad, he hasn't looked at version 2, which is
> considerably different from version 1.
>
> -K, a pragmatist, not an idealist
>
> On Apr 3, 2008, at 1:42 PM, Michael R. Gettes wrote:
> > Okay, I'll bite - then why aren't we using Maven?  And should we
> > not be using the same tools across all the projects?
> >
> > /mrg
> >
> > On Apr 3, 2008, at 13:06, Kathryn Huxtable wrote:
> >> Neither do I. I like Maven. -K
> >>
> >> On Apr 3, 2008, at 2:54 AM, GW Brown, Information Systems and
> >> Computing wrote:
> >>> In general I don't like merging JARS. blair used to do this for
> >>> the API but came up with a separate ant target, dist-lib, so the
> >>> user could choose.
> >>>
> >>> Gary
> >>>
> >>> --On 03 April 2008 01:28 -0400 Chris Hyzer 
> >>> <>
> >>> wrote:
> >>>
> >>>> This is a good point and I agree that common (or upgradeable)
> >>>> jars inside
> >>>> a jar are annoying (e.g. commons-lang, cglib).  However, for
> >>>> grouper web
> >>>> services, Axis has dozens of jars, many of which I don't think
> >>>> anyone
> >>>> would want to upgrade individually or care to look at.  So, the
> >>>> common
> >>>> (upgradeable) ones from axis are:
> >>>>
> >>>> http://viewvc.internet2.edu/viewvc.py/grouper-ws/grouper-
> ws/lib/axis/?roo
> >>>> t=I2MI
> >>>>
> >>>> I have individually as jars (not bundled).  But the uncommon ones
> >>>> (~40 of
> >>>> them):
> >>>>
> >>>> http://viewvc.internet2.edu/viewvc.py/grouper-ws/grouper-
> ws/lib/axis-bund
> >>>> le/?root=I2MI
> >>>>
> >>>> I have wrapped into one axisBundle.jar via ant.  When you say
> >>>> "impossible", do you mean inconvenient, or do you mean impossible?
> >>>> Because you can just open the bundled jar, delete the files in a
> >>>> certain
> >>>> package, and then put a newer version of the jar in the lib dir.
> >>>> Yes,
> >>>> this is inconvenient and perhaps a little risky, but you will
> >>>> also notice
> >>>> the size of i2mi-common.jar has shrunk in version 1.3 of
> >>>> grouper... :).
> >>>> Anyways, if someone sees a jar in the axis bundle that should be
> >>>> removed,
> >>>> this is easy let me know.  Or if consensus is people would rather
> >>>> see 80
> >>>> jars in grouper web services instead of 40, Im not tied to the
> >>>> bundle
> >>>> idea and can ditch it no problem...
> >>>>
> >>>> I think the bigger problem of the bundle is knowing what jars you
> >>>> have.
> >>>> If you think you need to add a new jar and it is already in the
> >>>> bundle
> >>>> that can be a problem.  So #1 is for people to know there is a
> >>>> bundle,
> >>>> and #2 is having a way to know what is in the bundle.  In grouper-
> >>>> ws this
> >>>> is stored in the above dir in CVS (of course tied to the branch
> >>>> release
> >>>> that you are using)...
> >>>>
> >>>> Kind regards,
> >>>> Chris
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Michael R. Gettes 
> >>>>> [mailto:]
> >>>>> Sent: Wednesday, April 02, 2008 2:14 PM
> >>>>> To: Kathryn Huxtable
> >>>>> Cc: Grouper Users; Signet Users
> >>>>> Subject: Re: [grouper-users] ldappc build question
> >>>>>
> >>>>> Kathryn, as you know, I have long been frustrated by the
> >>>>> "deployment design" of LDAPPC.  ANYTHING you can do to simplify
> >>>>> it and have it actually make sense is a good thing!  But, please,
> >>>>> don't redo the mistake in grouper 120 (i think that was the
> >>>>> version)
> >>>>> where jars like subject-api got rolled into a larger jar file
> >>>>> making
> >>>>> it impossible to try different versions (or test versions) of
> >>>>> various
> >>>>> jar files as part of the development process for creating a
> >>>>> service.
> >>>>> I guess a shorter way of saying this might - please also retain
> >>>>> the flexibility.
> >>>>>
> >>>>> I hope this helps!
> >>>>>
> >>>>> /mrg
> >>>>>
> >>>>> On Apr 2, 2008, at 14:09, Kathryn Huxtable wrote:
> >>>>> > Is there any interest in having the build process for ldappc
> >>>>> > generate a jar, so that can easily be run from a simple
> >>>>> directory
> >>>>> > with the grouper-api, signet-api, and other assorted jars?
> >>>>> >
> >>>>> > Currently, it just generates a class directory.
> >>>>> >
> >>>>> > -K
> >>>>
> >>>
> >>>
> >>>
> >>> ----------------------
> >>> GW Brown, Information Systems and Computing
> >>> 
> >>>
> >>
> >