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: "Michael R. Gettes" <>
  • To: Kathryn Huxtable <>
  • Cc: "GW Brown, Information Systems and Computing" <>, Chris Hyzer <>, Grouper Users <>, Signet Users <>
  • Subject: Re: [grouper-users] ldappc build question
  • Date: Thu, 3 Apr 2008 14:42:37 -0400

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







Archive powered by MHonArc 2.6.16.

Top of Page