[
https://issues.apache.org/jira/browse/DERBY-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4845:
--------------------------------------
Attachment: d4845-iapi-dependablefinder.diff
d4845-iapi-resultsetstatistics.diff
d4845-iapi-statementnode.diff
One thing that's causing problems for the dependency tracking is that we
compile the impl classes in the engine before we build the iapi classes. Since
the impl classes depend on the iapi classes, most of the iapi classes will
already have been built when the iapi build target is invoked. Building iapi
before impl is the right way to do it, but that doesn't work currently because
of some ugly dependencies from iapi to impl that have snuck in and cause some
impl classes to be built using the wrong classpath if built that way.
It may be a good, incremental improvement if we remove the dependencies from
iapi to impl, and then make iapi being built before impl. Once that's done, we
can set sourcepath="" on the iapi target (see previous comment) to prevent
accidental reintroduction of dependencies on impl classes.
The iapi classes currently have many dependencies on implementation classes.
Here are three patches that remove some of the dependencies:
- d4585-iapi-statementnode.diff:
The implementation class StatementNode is used in the signatures of methods in
the TriggerDescriptor and DataDictionary iapi interfaces. The patch changes the
signatures to use the iapi interface Visitable instead of StatementNode. In
some cases that's specific enough. In other cases, the impl classes that use
these methods need to cast the return value to StatementNode now. Actually,
most callers of the methods already cast the return value to StatementNode
(which suggests that the a less specific interface has been used in the
signature before too) or to sub-classes of StatementNode, and didn't need to be
changed.
- d4845-iapi-resultsetstatistics.diff:
To apply this patch, first run: svn mv
java/engine/org/apache/derby/impl/sql/execute/rts/ResultSetStatistics.java
java/engine/org/apache/derby/iapi/sql/execute/ResultSetStatistics.java
The interface ResultSetStatistics lives in the impl sub-tree. However, it is
used in the signature of the iapi interface ResultSetStatisticsFactory. It is
also the parent of the iapi interface XPLAINVisitor. This suggests that the
interface really belongs in iapi and not in impl. The patch moves the interface
to iapi and updates import statements to point to the new location.
d4845-iapi-dependablefinder.diff:
The impl classes DDdependableFinder and DDColumnDependableFinder are
instantiated directly by the iapi class TupleDescriptor and many of its
sub-classes. Since the DD* classes are specific to the data dictionary
implementation, the patch adds creator methods to the DataDictionary interface
and moves the actual creation of these instances into DataDictionaryImpl. Then
we don't need to reference these two implementation classes from iapi classes.
All the regression tests ran cleanly with these three patches.
> Improve the dependency tracking for our build targets
> -----------------------------------------------------
>
> Key: DERBY-4845
> URL: https://issues.apache.org/jira/browse/DERBY-4845
> Project: Derby
> Issue Type: Bug
> Components: Build tools
> Affects Versions: 10.8.1.2
> Reporter: Rick Hillegas
> Attachments: check-build.ksh, d4845-iapi-dependablefinder.diff,
> d4845-iapi-resultsetstatistics.diff, d4845-iapi-statementnode.diff,
> derby-4845-01-aa-removeParserPrep, derby-4845-02-aa-flipUtilsAndTypes.diff,
> tools-i18n.diff
>
>
> Derby is supposed to have an incremental build. That is, if you change a
> file, then the following command should recompile the file:
> ant all
> There are several places in the graph of Derby build targets where this is
> not true. If you change a file in certain packages, a subsequent "ant all"
> won't notice the change. This issue is a place where we can track these bugs.
--
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
