Re: [uportal-dev] maven project structure for GAP

[Eric Dalquist]

Dan,




I did have a few questions about other ideas for the project.







-Eric






Eric Dalquist wrote:

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. -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). 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.

Sounds good, I'll let you know when I get it in.



-Eric

Dan Ellentuck wrote:

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.

Hi Eric,

That sounds fine.  Why don't you just commit those changes.



   Dan

Eric Dalquist wrote:

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

Dan Ellentuck wrote:

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?

Hi Eric, et. al.,





  Maven -> Enable Nested Modules
  Maven -> Update Source Folders



   Dan


Eric Dalquist wrote:

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: It should now be possible to build via maven from within eclipse, as well as compile and debug individual classes.

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.


that, since I'm the only one working presently in this
project, and then commit the changes on the trunk.

Dan

Eric Dalquist wrote:

I figured I would tag the current gap_trunk "pre-divide-into-modules-20080305" or something like

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

 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

dependency from GAP, and this seems
desirable.

Thanks for your help,

Dan

api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar work with, but using a parent project with 2 sub-projects removes the uPortal2

smime.p7s
Description: S/MIME Cryptographic Signature