Skip to Content.
Sympa Menu

grouper-users - Re: [signet-users] Re: [grouper-users] ldappc build question

Subject: Grouper Users - Open Discussion List

List archive

Re: [signet-users] Re: [grouper-users] ldappc build question

Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: Chris Hyzer <>
  • Cc: "Michael R. Gettes" <>, "GW Brown, Information Systems and Computing" <>, Grouper Users <>, Signet Users <>
  • Subject: Re: [signet-users] Re: [grouper-users] ldappc build question
  • Date: Thu, 3 Apr 2008 14:36:32 -0500

We certainly *do* have a decision. We're using ant.

But any decision can be revisited and I would propose that we study this over time and in the background. I wouldn't expect anything to happen for months.

And we still might decide to continue using ant.

I'm aware that Maven is not without its problems, but I consider the advantages to outweigh the disadvantages.

It took about three weeks of work to convert the IdMS system at KU, which consisted of about fifteen different projects, from ant to Maven.

-K, who also prefers subversion to CVS

On Apr 3, 2008, at 2:12 PM, Chris Hyzer wrote:
My understanding of why we aren't using Maven is that it isn't a silver bullet over ant (there are pros and cons), and we would rather spend a few resources standardizing some build files / tasks / dir structure than completely reimplementing a build tool (which I would think would be a larger task). When I google maven vs ant it seems like not everyone prefers maven... if we were starting from scratch we might have a different direction, but we already have an install base with ant.

Either way, I think we need to make a final decision and we can all go in that direction for a while (I thought we had a decision the last time we discussed it with the grouper team, but maybe not).


-----Original Message-----
From: Kathryn Huxtable
Sent: Thursday, April 03, 2008 2:52 PM
To: Michael R. Gettes
Cc: GW Brown, Information Systems and Computing; Chris Hyzer; Grouper
Users; Signet Users
Subject: Re: [signet-users] Re: [grouper-users] ldappc build question

We're not using Maven because I'm not an evangelist and haven't
seriously tried to push it.

The Apache project uses it and we used it at KU for many projects, but
not for all. Identity Management used it, when that unit existed.

There are people in I2 such as Chad LaJoie (for instance) who can't
stand Maven.

Okay, I'm not an evangelist, but I'll put together something by the
time of the I2 meeting that I can share about the benefits of Maven
and also some of its less nice features.

And to be fair to Chad, he hasn't looked at version 2, which is
considerably different from version 1.

-K, a pragmatist, not an idealist

On Apr 3, 2008, at 1:42 PM, Michael R. Gettes wrote:
Okay, I'll bite - then why aren't we using Maven? And should we
not be using the same tools across all the projects?


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.


--On 03 April 2008 01:28 -0400 Chris Hyzer

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
would want to upgrade individually or care to look at. So, the
(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
package, and then put a newer version of the jar in the lib dir.
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
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
idea and can ditch it no problem...

I think the bigger problem of the bundle is knowing what jars you
If you think you need to add a new jar and it is already in the
that can be a problem. So #1 is for people to know there is a
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
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
where jars like subject-api got rolled into a larger jar file
it impossible to try different versions (or test versions) of
jar files as part of the development process for creating a
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
with the grouper-api, signet-api, and other assorted jars?

Currently, it just generates a class directory.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page