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: Kathryn Huxtable <>
  • To: Chris Hyzer <>
  • Cc: "Michael R. Gettes" <>, Grouper Users <>, Signet Users <>
  • Subject: Re: [grouper-users] ldappc build question
  • Date: Thu, 3 Apr 2008 12:06:21 -0500

This is part of the problem that Maven addresses.


On Apr 3, 2008, at 12:28 AM, 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:

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

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,

-----Original Message-----
From: Michael R. Gettes
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!


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.


Archive powered by MHonArc 2.6.16.

Top of Page