Grouper Users - Open Discussion List

["GW Brown, Information Systems and Computing" <>]

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