[
https://issues.apache.org/jira/browse/DERBY-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-5475:
-----------------------------------
Issue & fix info: (was: Patch Available)
Committed patch 3a to trunk with revision 1330751.
The next step is probably to rewrite one of the tests to start using the
repository, and to make it available in the test framework.
I do plan to remove the code that downloads the JARs from Apache because. In my
opinion downloading the JARs each time you run the test needing them is a waste
of resources. Instead the developer should download them once and then update
the local repository, which is as simple as typing 'svn up', at regular
intervals or explicitly when a new release happens.
As for more functionality, I'm considering moving the handling of
derbyTesting.oldVersionsPath into ReleaseRepository. I have no feel for how
much this is being used, but it does allow for a solution where the
configuration can be relatively easy scripted from a shell or similar.
> Formalize use of old Derby distributions in tests
> -------------------------------------------------
>
> Key: DERBY-5475
> URL: https://issues.apache.org/jira/browse/DERBY-5475
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.9.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Attachments: derby-5475-1a-DerbyVersion.diff,
> derby-5475-1b-DerbyVersion.diff, derby-5475-2a-rename_and_cleanup.diff,
> derby-5475-2a-rename_and_cleanup.stat, derby-5475-3a-repository.diff
>
>
> Some types of tests need old Derby distributions to perform the required
> actions. Currently this includes the upgrade test and the compatibility test.
> Instead of each test dealing with this in their own way, there should be
> support for accessing old Derby distributions in the test framework.
> I propose to add a Derby distribution repository in the test framework, with
> the following guidelines and changes:
> o keep it as simple as possible, which suggests it is the users
> responsibility to keep the repository updated
> o compatibility with the existing derbyTesting.oldReleasePath property
> o make the tests requiring old distributions fail if there are no
> distributions available
> o establish a default location where the test framework will look for old
> distributions if derbyTesting.oldReleasePath is unspecified
> o the repository should not incur any costs when not used by the test(s)
> being run
> In favor of simplicity the repository will not download releases itself. The
> user has to keep the repository contents up-to-date, which is as simple as
> running 'svn up' each time a new Derby release is published. It is unclear
> if, and what, the repository and/or relevant tests should do if the
> repository is outdated. It seems useful to allow the user to make available
> only a subset of the distributions, but maybe printing a warning is helpful
> to remind developers that their repository is stale.
> Another related issue, which will only be relevant some time in the future,
> is whether a test framework of version X should make available distributions
> of version X+n. Currently I'm leaning towards not doing that, but haven't
> really looked into it.
> See also thread on derby-dev: http://db.markmail.org/thread/44uyusa726cwjuk2
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira