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: Chris Hyzer <>, "Michael R. Gettes" <>, Kathryn Huxtable <>
  • Cc: Grouper Users <>, Signet Users <>
  • Subject: RE: [grouper-users] ldappc build question
  • Date: Mon, 7 Apr 2008 01:02:42 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

Ok, Im not getting much (well, none at all) support for bundled jars, so I
removed the axisBundle.jar from the grouper web services to use all the
individual jars instead... fyi.

Kind regards,
Chris

> -----Original Message-----
> From: Chris Hyzer
> Sent: Thursday, April 03, 2008 1:28 AM
> To: 'Michael R. Gettes'; Kathryn Huxtable
> Cc: Grouper Users; Signet Users
> Subject: RE: [grouper-users] ldappc build question
>
> 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/?root=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-
> bundle/?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




Archive powered by MHonArc 2.6.16.

Top of Page