What I didn't get is why the 1.3.x changes seem to affect lots more
than the pom.xml. Change #738557 affects a bunch of jdbc/kernel test
cases. These changes are not reflected in the trunk.
Maybe the problem is that #738557 doesn't really change files, just
some oops...svn chatter?
Craig
On Feb 9, 2009, at 6:05 AM, Michael Dick wrote:
> 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
> <Craig.Russell@sun.com>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)" <jira@apache.org>
>>> Date: February 6, 2009 11:05:00 AM PST
>>> To: dev@openjpa.apache.org
>>> Subject: [jira] Updated: (OPENJPA-876) Better test profiles for
>>> proprietary databases (DB2, Oracle) and continuous build
>>> Reply-To: dev@openjpa.apache.org
>>>
>>>
>>>
>>> [
>>> 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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
|