Hi Craig, The trunk commits were a lot smaller than the 1.3.x commit so it's easy to miss in the JIRA issue. The revisions are #738555 and #740101.
Regards, -mike On Fri, Feb 6, 2009 at 3:41 PM, Craig L Russell <[email protected]>wrote: > When I looked at the JIRA issue, I didn't find the svn trunk commit > references. Were they applied without the JIRA issue number or did something > go wrong? > > Thanks, > > Craig > > Begin forwarded message: > > From: "Donald Woods (JIRA)" <[email protected]> >> Date: February 6, 2009 11:05:00 AM PST >> To: [email protected] >> Subject: [jira] Updated: (OPENJPA-876) Better test profiles for >> proprietary databases (DB2, Oracle) and continuous build >> Reply-To: [email protected] >> >> >> >> [ >> https://issues.apache.org/jira/browse/OPENJPA-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Donald Woods updated OPENJPA-876: >> --------------------------------- >> >> Fix Version/s: 2.0.0 >> 1.3.0 >> >> Updating Fix Versions, as code has been checked into 1.3.x and trunk. >> >> Better test profiles for proprietary databases (DB2, Oracle) and >>> continuous build >>> >>> --------------------------------------------------------------------------------- >>> >>> Key: OPENJPA-876 >>> URL: https://issues.apache.org/jira/browse/OPENJPA-876 >>> Project: OpenJPA >>> Issue Type: Improvement >>> Affects Versions: 1.0.3, 1.1.0, 1.2.0, 1.3.0, 2.0.0 >>> Reporter: Michael Dick >>> Assignee: Michael Dick >>> Fix For: 1.3.0, 2.0.0 >>> >>> >>> Currently we use the test-custom and test-custom2 profiles in >>> openjpa-persistence-jdbc/pom.xml to enable testing of a variety of >>> databases. Basically anything that does not have a publicly available JDBC >>> drivers. >>> This support works well if you run the build manually, but isn't always >>> perfect when using a continuous build system. >>> In many continuous build systems you want to have a single build >>> definition which can be run on any number of machines. Ideally each machine >>> could store the database settings in ${user.home}/.m2/settings.xml. Where >>> this becomes a problem is if a single machine wants to use our test-custom >>> profile in conjuction with another one. For example mvn >>> -Ptest-custom,test-custom-oracle clean install. In order to make this work >>> Maven would have to set variables in test-custom-oracle and then read them >>> in the test-custom profile. Ensuring that the properties are handled in the >>> correct order is cumbersome and doesn't seem to work in recent versions of >>> maven / surefire. >>> To resolve the problem I propose creating specific profiles for testing >>> with various proprietary databases. These profiles rely on the user running >>> mvn install:install-file ${maven args} to install a copy of the jdbc drivers >>> in a local repository prior to running, but after that one time setup step >>> it's a lot easier to run tests on various databases (manually or on a build >>> system). >>> >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> > Craig L Russell > Architect, Sun Java Enterprise System http://db.apache.org/jdo > 408 276-5638 mailto:[email protected] > P.S. A good JDO? O, Gasp! > >
