Yes, that was the question I was asking, whether we want to
have local developers do a mvn install when they are working
on a specific module. I'll document this.
Dan
Eric Dalquist wrote:
When you're working on the project locally maven should automatically
resolve that dependency to the other gap-api project module. If you're
trying to run mvn commands on the specific modules you may have to run
'mvn install' on the gap-api module first. This will move that artifact
into your local repository on your machine. Any mvn commands you run
from the root of the project should work without any of the gap
artifacts in your local repository.
-Eric
Dan Ellentuck wrote:
Hi Eric,
Both the gap-impl and gap-uportal2-api projects need the gap-api.
Should this just be handled locally in all cases?
Dan
Eric Dalquist wrote:
This sounds great, I'll see if I can find some time this week to take
a look at it.
The GAP project should be locally build-able without adding anything
to a central repository.
-Eric
Dan Ellentuck wrote:
Hi Eric, et. al.,
I've divided the gap project into the structure Eric describes in
his email. This turned out to be good for reasons beyond just
following convention, since it forced a code cleanup that I think
better emphasizes the difference between api and impl.
Eric, I'm looking now at what you've done with person-directory and
thinking I should go ahead and follow this model, i.e., alter the
trunk so that it contains a parent and 3 child projects, and declare
a module in the parent pom for each one.
In order to make the projects build-able, I have to install the
gap-api jar into the jasig maven repository. How do I go about
doing this?
Thanks,
Dan
Eric Dalquist wrote:
Any thoughts on these suggestions Dan?
-Eric
Eric Dalquist wrote:
I'd actually like to suggest a 3rd arrangement. The maven project
structure I think would work best initially would be:
gap-parent
+-gap-api
+-gap-impl
+-gap-uPortal2-api
I'm actually working on doing the api/impl split on person
directory right now and I think that will open up some more
options for making these services available to portlets and other
applications. For GAP the -api module would contain all of the
public APIs a GAPs client would need to use to access the system.
Hopefully it would completely or mostly be interfaces and all of
the implementation code and group service code ends up in -impl.
I can provide some direct help doing this via the IRC channel, do
you have a branch in SVN where this work is happening?
-Eric
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 uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
