Unable to render {include} The included page could not be found.
Upgrade utility not currently compatible with version 3.4.2 The upgrader utility is not currently compatible with version 3.4.2 of Fedora, due to the Java package renaming in this release. This issue is currently being addressed, see the JIRA issue. We will announce on the mailing lists when a new version of the utility is available. In the meantime, you must upgrade to Fedora 3.3 as described below, then follow the instructions on Upgrading from 3.x. OverviewThis document explains how to migrate your Fedora repository from version 2.x to 3.x. Although it is written assuming 3.3, the same instructions apply if you are upgrading to an older 3.x release. Before continuing, you should familiarize yourself with the new Content Model Architecture. A basic understanding of how the CMA works will be helpful in understanding the migration process. Throughout this guide, NOTE: To reduce confusion during this process, if you have previously ingested the Fedora demo objects, you should purge them from your 2.x repository before starting with the migration process. The demo objects have changed significantly since 2.x, and if you'd like the new versions, we recommend that you ingest them after performing a successful migration of your old repository. 1. Install, Start, and Stop Fedora 3.xFollow the instructions in the Fedora Installation and Configuration Guide. When finished, start the server and verify your installation was successful by visiting the describeRepository page (e.g. http://localhost:8080/fedora/describe 2. Point Fedora 3.x to Existing ObjectsA. Object XML (FOXML)Determine where your old object XML is stored. If you're unsure, consult Edit NOTE: The upgrade process will transform the objects in Warning If you haven't already done so, make a backup of all original object XML files. These will be changed during the transformation part of the migration process, and if something goes wrong, this backup will be your only way of recovering. B. Managed DatastreamsDetermine where your old Fedora Repository's managed Datastreams are stored. Again, you can check your old Edit NOTE: The migration process will not make any changes to these files. 2. Install the Migration UtilitiesThe migration utilities come as a separate download from the Fedora installation. They are all included, with source, in a single download fedora-migration-3.2.zip at sourceforge.net. Once unzipped, you will find the executable jars in the top directory. Although the filename is fedora-migration-3.2.zip, the utilities will also work for migrating to Fedora 3.3 3. Run the AnalyzerThe analyzer examines all of your existing digital objects and looks for similarities. It outputs the following information in a directory you specify.
The analyzer does not make changes to any source objects. A. Configuring the AnalyzerThe analyzer accepts a Java properties file for configuration. Tip In properties files, the "\" character must be escaped. When using Windows, this means paths like Create a file (e.g. # This is the directory where the analyzer's output files should be sent. # If it doesn't already exist, it will be automatically created. # If it already exists, it must be empty (to avoid accidental overwrites) # To disable the above restriction, uncomment clearOutputDir=true below. outputDir=c:\\fedora-migration #clearOutputDir=true # The Fedora 3.x home directory. fedoraHome=c:\\fedora-3.3 # The full path to the JDBC driver Fedora is configured to use. # NOTE: The analyzer only uses the database to aid in looking up # the location of FOXML. It will populate the initial paths in # the database the first time it runs, if the necessary. jdbcJar=c:\\fedora-3.3\\tomcat\\webapps\\fedora\\WEB-INF\\lib\\postgresql-8.3-603.jdbc3.jar # Aspects of the original objects to ignore for the purpose of # classification. This is optional. If unspecified, the generated # content models will be the MOST SPECIFIC POSSIBLE. If # specified, this property must consist of a space-delimited # list of any of the following: # OrigContentModel # If specified, objects that have differing values in the original # contentModel property may be assigned to the same content # model if they are otherwise similar. # DatastreamIDs # If specified, only datastreams bound to disseminators will # be considered important for classification. Objects that have # differing sets of UNUSED datastream IDs may be assigned to # the same content model if they are otherwise similar. # MIMETypes # If specified, the MIMETYPE of each candidate datastream # will be ignored for the purpose of classification. Objects that # have differing MIME types for the same datastream may be # assigned to the same content model if they are otherwise # similar. # FormatURIs # This works exactly the same as MIMETypes, but applies to # the FORMAT_URI of candidate datastreams. #ignoreAspects=OrigContentModel DatastreamIDs MIMETypes FormatURIs # Specific datastream IDs to ignore for the purpose of classification. # This is optional. If specified, this property must consist of a # space-delimited list of datastream IDs to ignore. Note: This configuration # has no effect if DatastreamIDs is already specified as an ignoreAspect # above. ignoreDatastreamIDs=DC RELS-EXT RELS-INT POLICY # Explicitly declare objects to be in the FedoraObject-3.0 content model. # The default is 'false', or implicit. If left implicit, the objects # will not have an explicit basic model, and it will be up to the # system to use a default value at runtime. This option may have # an impact on future upgrades. Future versions of Fedora may adopt a new # basic model that has additional system methods, or require certain # datastreams or formats. Objects that explicitly declare a 3.0 # model should behave exactly the same if Fedora is upgraded to a # post 3.0 version. If left implicit, the objects may be interpreted # in light of the new model, and may inherit new methods, or may # fail validation and require updating if the new model introduces # requirements they do not fulfill. # Uncomment to force explicit basic model declarations in the # upgraded objects. # explicitBasicModel = true B. Analyzer UsageThe analyzer utility is an executable jar and takes the configuration file as a parameter. For example, if your configuration is in the current directory and is named migration.properties, enter the following: java -jar analyzer.jar migration.properties Information If upgrading to Fedora 3.3 with an embedded Derby database (a configuration that is not recommended for production), you may notice an error similar to "java.sql.SQLException: Cannot close a connection". This does NOT indicate that the analyzer failed, and can be safely ignored. C. Reviewing Analyzer OutputThe analyzer will produce several files in the output directory. Generated content models will be in FOXML 1.1 format and will be named Each content model object will contain the following inline XML datastreams:
If the member objects had disseminators:
Three additional files will be created in the output directory:
D. Customizing Content Model PIDsBy default, the PIDs assigned to the generated content models are of the form, To do this, open each
E. Customizing Service Deployment PIDsIf any Warning DO NOT specify the same PID for F. Upgrading Objects Without Content ModelsBy default, the analyzer ensures that every data object is assigned to a content model. If you'd rather avoid assigning an explicit content model to an object, you may do so by a) removing its PID from the Warning In order for migration to work properly, the PID of every object in the source repository must occur exactly once in the set of PID list files. 5. Run the GeneratorThe generator reads the output of the analyzer (along with any customizations you have made) and adds the following to the same directory:
A. Configuring the GeneratorLike the analyzer, the generator accepts a Java properties file for configuration. The configuration file should have the following content, with values filled in appropriate to your environment. Tip Since you already entered # This is the directory containing the analyzer's output, and where the generator's # results should be written. sourceDir=c:\\fedora-migration # The Fedora 3.x home directory fedoraHome=c:\\fedora-3.3 # The full path to the JDBC driver Fedora is configured to use jdbcJar=c:\\fedora-3.3\\tomcat\\webapps\\fedora\\WEB-INF\\lib\\postgresql-8.3-603.jdbc3.jar B. Generator UsageThe generator utility also accepts the configuration file as a parameter. For example: java -jar generator.jar migration.properties C. Reviewing Generator OutputThe generator will produce several files in the output directory. These files, along with those already produced by the analyzer, will be used in the next steps of the migration process. One stylesheet will be written for each PID list: Information The generated stylesheet will cause a new The output will also include a new, generated Service Deployment object ( 6. Run the TransformerThe transformer applies stylesheets to FOXML stored in a Fedora repository. Although it directly accepts the output of the analyzer and generator, it can also be used outside of the migration process for making low-level changes to batches of objects. When running the transformer in this way, the repository should be shut down, and the Here's how the transformer works: It scans a directory for PID list files, ending with .txt. For each, if a .xslt file exists with the same name, that stylesheet is applied to the repository's FOXML for each object in the PID list. Warning The transformer makes changes to object XML in the repository. It is possible to damage some, or all of the objects in the repository by using the transformer, so be sure to make a backup first! A. Configuring the TransformerLike the analyzer and generator, the transformer accepts a Java properties file for configuration. The transformer is configured with the same properties that the generator is configured with (see above), and also takes the following: # Whether to run the transformer in "dry run" mode or not. # In dry run mode, transformation will be tested but no changes will be written dryRun=true Although not required, it is strongly recommended that you run the transformer with B. Transformer UsageThe transformer utility also takes the configuration file as a parameter. For example: java -jar transformer.jar migration.properties 7. Run the RebuilderNow that all of your existing objects have been upgraded, you need to run the Information You MUST rebuild the SQL database. Rebuilding the Resource Index is required only if your Fedora 3.x Repository has been configured to enable the Resource Index. Rebuilding the SQL database will take around double the time that the transformer took. Rebuilding the Resource Index may take significantly longer. 8. Ingest Generated ObjectsAfter the rebuilder has run successfully, you should restart your Fedora 3.x instance and visit the describe page (e.g. http://localhost:8080/fedora/describe Now you'll need to ingest all the new Content Model and Service Deployment objects created during the analyzer and generator steps. To do this:
10. Verify Success and Clean UpYou should now verify that the upgraded objects are behaving as expected. Pick a few from each
If you had Disseminators in your original repository, you are now making use of a NEW set of Service Deployment objects. You may now want to purge the original BMechs, since they are no longer in use. The simplest way to do this is with the Unable to render {include} The included page could not be found.
|