Hi Eric,
Thanks for doing those changes.
I think you're right about org.jasig.gap.db not being
appropriate for the gap api, and I'll move it to the impl
module.
I'm less sure about the org.jasig.gap.services.sequence
package and the other non-core interfaces. I've thought of
the api module as not merely being for GAP clients but also
for developers who may want to write alternate
implementations of the impl packages. Let me think on it a
bit.
We could certainly move the gap-uportal2 code back into the
uPortal project, though I was thinking of it as a temporary
expedient rather than something that we want to maintain
long-term.
The custom jar packaging in the gap-impl module was just a
stab I took at coming up with substitutable units of code
that someone might want to re-implement. I'm not really
sure if creating more modules is helpful or just
complicating. I'd rather hold off on it for now.
I think creating a branch for the gap integration work is a
good idea.
Dan
Eric Dalquist wrote:
Dan,
I just committed my changes to the GAP poms. I updated them to follow
more what other JASIG projects are doing by declaring artifact versions
in a <properties> block in the parent pom and then referring to those in
the child poms when declaring dependencies. I also removed a bunch of
meta-data that was duplicated from the jasig-parent pom and between the
poms in the project which should help make maintenance easier.
I did have a few questions about other ideas for the project.
-Do the org.jasig.gap.db and org.jasig.gap.services.sequence packages
need to be in the gap-api module? I'm not sure these (and there may be
some others) are things that would want to be exposed to some code that
is a client of GAP.
-When we actually start integrating this code back into uPortal perhaps
we should look at moving the gap-uportal2-impl code into the uPortal
project. It seems that this is a bit out of the scope of GAP and could
be nice for GAP development to not have to worry about it where as it is
under the scope of uPortal especially in the view of adopting the
stand-alone GAP project.
-What is the intent of doing the custom jar packaging with Ant in the
gap-impl module? If the goal is to split those into further sub-modules
that shouldn't be too difficult (as long as there aren't any cycles in
the code).
-Eric
PS: Note that this is to gaps-dev and uportal-dev is just CCd on it.
Perhaps those interested in following the conversation can subcribe on
gaps-dev.
Eric Dalquist wrote:
Sounds good, I'll let you know when I get it in.
As for the uPortal integration work, should we create a branch for
you? We aren't going to want to commit any GAP related changes until
after the 3.0 GA release.
-Eric
Dan Ellentuck wrote:
Hi Eric,
That sounds fine. Why don't you just commit those changes.
I'm starting now on the actual integration work and will keep you
posted. As much as possible, the first round will involve
subtracting gap classes from uportal-impl and using instead the
gap-uportal2 api. This will not be possible in all cases, so I will
have to change some code in uportal-impl that refers to gap classes
other than those in o.j.p.services.
Dan
Eric Dalquist wrote:
Dan,
I just pulled the code and the restructuring looks good. I have a
few suggestions around the organization of the POMs, namely moving
the dependency declarations to the child POMs and just declaring
dependency versions in the parent pom. Is it ok if I just make the
changes and commit or would you like me to post a patch to run by
you first?
-Eric
Dan Ellentuck wrote:
Hi Eric, et. al.,
I've committed the restructured, mavenized gap project, divided
into modules for gap-api, gap-impl and gap-uPortal2-api. The next
step is integration with up3.
If you want to build it in eclipse with the maven plugin, I've
found the quickest way is to check out the gap project from the
trunk, and from the project context menu:
Maven -> Enable Nested Modules
Maven -> Update Source Folders
It should now be possible to build via maven from within eclipse,
as well as compile and debug individual classes.
Dan
Eric Dalquist wrote:
Sounds good! I hope I can find time to take a peak soon
:)
-Eric
Dan Ellentuck wrote:
Hi Eric,
Thanks, the builds are working fine now.
I figured I would tag the current gap_trunk
"pre-divide-into-modules-20080305" or something like
that, since I'm the only one working presently in this
project, and then commit the changes on the trunk.
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
Subscribe to the conference blog, The Community Source Way
http://jasig2008.blogspot.com, for news and updates about the event.
Join the Conference networking site at http://ja-sigspring08.crowdvine.com/
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
