Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] ldappc build question

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] ldappc build question

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "Michael R. Gettes" <>, Kathryn Huxtable <>
  • Cc: Grouper Users <>, Signet Users <>
  • Subject: RE: [grouper-users] ldappc build question
  • Date: Thu, 3 Apr 2008 01:28:17 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

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:

I have individually as jars (not bundled). But the uncommon ones (~40 of

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

Kind regards,

> -----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

Archive powered by MHonArc 2.6.16.

Top of Page