Dan,
I favor the two sub project approach for the advantage of emphasizing
that there's a great majority of GAP that is independent of uPortal.
Since the new project will deliver .jars usable elsewhere regardless of
how the project build is factored, I don't feel tremendously strongly in
my opinion. There's an argument to be made that SplatProject ought not
to care whether the GAP project build depends on uPortal, so long as the
resulting .jars that SplatProject will consume don't depend on uPortal.
Andrew
Dan Ellentuck wrote:
Hi Eric, et. al.,
I've spent quite a few hours experimenting with various maven project
structures for GAP and have come up with 2 options:
. a single project containing all the code, with a custom packaging
phase to create the individual jars we want:
gap-full.jar (does not contain uportal2 api)
gap-common.jar
gap-groupsCore.jar
gap-groupServices.jar
gap-permissions.jar
gap-uportal2-api.jar
. a parent project with 2 sub-projects, one for all of the
org.jasig.gap code (with a custom packaging phase) and one for the
uPortal2 api:
gap
gap-core
gap-uPortal2-api
I'd like your opinion. I suspect that a single project is clearest
and easiest to work with, but using a parent project with 2
sub-projects removes the uPortal2 dependency from GAP, and this seems
desirable.
Thanks for your help,
Dan
--
Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The
Community Source Way!"
April 27th - 30th, 2008 in St. Paul, Minnesota USA
Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and
more!
Information/Registration at:
http://www.ja-sig.org/conferences/08spring/index.html
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
