...

uPortal now has an export/import system using xml files generated by Cernunnos export scripts.  Basically, you will run an export command on your existing portal project to generate a number of xml data files.  You then run import in your uPortal3 project to import the data from these xml files into your uPortal3 database.  Take a look at the Cernunnos overview to get a better understanding of this process.  After that, move on to reading about Exporting and Importing.

TIP: Never export/import a database with portals actively connected to it.  Don't assume edits to a database will persist or take affect if portals are connected to it.  The portal does some advanced caching and may overwrite your change when it shuts down or never see a new change because it's using a cached copy of the row.

These scripts still have a few bugs.  Familiarize yourself with the known export/import bugs in JIRA and post any new bugs you find.

Default Database

The default database is populated by the db-import task in build.xml. This task is called by ant initdb, which in turn is called by ant initportal.  The db-import task actually uses crn-import to create the database:

...

As you can see, it simply calls crn-import on the entities directory.  Take a look at this directory to see the xml format for groups, layouts, channels, etc.

Exporting

The export procedure for uPortal versions <3.0 is different than those >=3.0.  Read the appropriate section for the portal you are exporting from.

 uPortal >= 3.0

 To export simply run:

 ant crn-export -Dtype=<type> -Ddir=<export_directory>

This will generate a number of xml files in the specified directory. The available types are printed if you call crn-export without a type, or can be examined in the export_internal.crn file.  Some types take a sysid parameter, for example, to export a single layout, run:

 ant crn-export -Dtype=layout -Ddir=<export_directory> -Dsysid=<username>

uPortal < 3.0

Exporting from an earlier version of uPortal is a bit of an adventure.  Some of the branches have had the export system backported.  However, Eric Dalquist made a major commit to uPortal/trunk with r44591 on 1/13/2009.  Any improvements with this commit probably have yet to be backported.  For example, 2.5-patches had the export system committed with r42716 on 12/12/2007 and is way out of date.  The backports have an import-export.xml file that you call ant on.  For example:

 ant -f import-export.xml export -Ddir=<export_dir> -Dtype=all

You could use this file, or else just add a crn-export task to your build.xml file.

When CalPoly performed it's migration the cernunnos scripts were under heavy development, I first applied the 2.5-patches branch export commit to our portal, then merged in some of the newer scripts from uPortal/trunk.  Presently, it may be cleaner to simply work off uPortal/trunk.

 Recommended Procedure

Here is what I would recommend doing:

...

 Your Default Database

I highly recommend setting up an entities directory for your team once you've had a successful export.  This is completely optional, but it's easy to setup and allows developers on your team to populate their development databases with the groups, channels, permissions, fragment-layouts, etc that your production portal uses.  After you've completed your export copy your export folder under: uportal-impl/src/main/resources/properties/db

In my case, I called the folder calpoly_entities

The contents should look something like this (note that I've omitted the contents of the larger directories):

Modify build.xml

Now in your build.xml you should add a import task for your entities and change initdb to not call the default entities.

     <target name="db-import-calpoly" description="Imports the CalPoly groups, channels, memberships, permissions from a snapshot of prod Nov 2008">
        <echo message="Importing CalPoly groups, channels, memberships, permissions data" />
        <antcall target="crn-import">
            <param name="dir" value="${basedir}/uportal-impl/src/main/resources

...

/properties/db/calpoly_entities" />
        </antcall>
    </target>

In initdb remove the call to db-import.  I also printed a message here:

 <echo message="You now need to run db-import-default, or db-import-calpoly to populate a working database." />

 Note that I renamed db-import to db-import-default in my build.xml