IDE}. This is the most popular\citing{javaReport2011} among them and seems to be
de facto standard IDE for Java development regardless of platform.
-\section{Source code organization}
-All the parts of this master project is under version control with
-\name{Git}\footnote{\url{http://git-scm.com/}}.
-
-The software written is organized as some \name{Eclipse} plugins. Writing a plugin is
-the natural way to utilize the API of \name{Eclipse}. This also makes it possible to
-provide a user interface to manually run operations on selections in program
-source code or whole projects/packages.
-
-When writing a plugin in \name{Eclipse}, one has access to resources such as the
-current workspace, the open editor and the current selection.
-
-The thesis work is contained in the following Eclipse projects:
-
-\begin{description}
- \item[no.uio.ifi.refaktor] \hfill \\ This is the main Eclipse plugin
- project, and contains all of the business logic for the plugin.
-
- \item[no.uio.ifi.refaktor.tests] \hfill \\
- This project contains the tests for the main plugin.
-
- \item[no.uio.ifi.refaktor.examples] \hfill \\
- Contains example code used in testing. It also contains code for managing
- this example code, such as creating an Eclipse project from it before a test
- run.
-
- \item[no.uio.ifi.refaktor.benchmark] \hfill \\
- This project contains code for running search based versions of the
- composite refactoring over selected Eclipse projects.
-
- \item[no.uio.ifi.refaktor.releng] \hfill \\
- Contains the rmap, queries and target definitions needed by by Buckminster
- on the Jenkins continuous integration server.
-
-\end{description}
-
-\subsection{The no.uio.ifi.refaktor project}
-
-\subsubsection{no.uio.ifi.refaktor.analyze}
-This package, and its subpackages, contains code that is used for analyzing Java
-source code. The most important subpackages are presented below.
-
-\begin{description}
- \item[no.uio.ifi.refaktor.analyze.analyzers] \hfill \\
- This package contains source code analyzers. These are usually responsible
- for analyzing text selections or running specialized analyzers for different
- kinds of entities. Their structure are often hierarchical. This means that
- you have an analyzer for text selections, that in turn is utilized by an
- analyzer that analyzes all the selections of a method. Then there are
- analyzers for analyzing all the methods of a type, all the types of a
- compilation unit, all the compilation units of a package, and, at last, all
- of the packages in a project.
-
- \item[no.uio.ifi.refaktor.analyze.checkers] \hfill \\
- A package containing checkers. The checkers are classes used to validate
- that a selection can be further analyzed and chosen as a candidate for a
- refactoring. Invalidating properties can be such as usage of inner classes
- or the need for multiple return values.
-
- \item[no.uio.ifi.refaktor.analyze.collectors] \hfill \\
- This package contains the property collectors. Collectors are used to gather
- properties from a text selection. This is mostly properties regarding
- referenced names and their occurrences. It is these properties that makes up
- the basis for finding the best candidates for a refactoring.
-\end{description}
-
-\subsubsection{no.uio.ifi.refaktor.change}
-This package, and its subpackages, contains functionality for manipulate source
-code.
-
-\begin{description}
- \item[no.uio.ifi.refaktor.change.changers] \hfill \\
- This package contains source code changers. They are used to glue together
- the analysis of source code and the actual execution of the changes.
-
- \item[no.uio.ifi.refaktor.change.executors] \hfill \\
- The executors that are responsible for making concrete changes are found in
- this package. They are mostly used to create and execute one or more Eclipse
- refactorings.
-
- \item[no.uio.ifi.refaktor.change.processors] \hfill \\
- Contains a refactoring processor for the \MoveMethod refactoring. The code
- is stolen and modified to fix a bug. The related bug is described in
- \myref{eclipse_bug_429416}.
-
-\end{description}
-
-\subsubsection{no.uio.ifi.refaktor.handlers}
-This package contains handlers for the commands defined in the plugin manifest.
-
-\subsubsection{no.uio.ifi.refaktor.prefix}
-This package contains the \type{Prefix} type that is the data representation of
-the prefixes found by the \type{PrefixesCollector}. It also contains the prefix
-set for storing and working with prefixes.
-
-\subsubsection{no.uio.ifi.refaktor.statistics}
-The package contains statistics functionality. Its heart is the statistics
-aspect that is responsible for gathering statistics during the execution of the
-\ExtractAndMoveMethod refactoring.
-
-\begin{description}
- \item[no.uio.ifi.refaktor.statistics.reports] \hfill \\
- This package contains a simple framework for generating reports from the
- statistics data generated by the aspect. Currently, the only available
- report type is a simple text report.
-
-\end{description}
-
-
-\subsubsection{no.uio.ifi.refaktor.textselection}
-This package contains the two custom text selections that are used extensively
-throughout the project. One of them is just a subclass of the other, to support
-the use of the memento pattern to optimize the memory usage during benchmarking.
-
-\subsubsection{no.uio.ifi.refaktor.debugging}
-The package contains a debug utility class. I addition to this, the package
-\code{no.uio.ifi.refaktor.utils.aspects} contains a couple of aspects used for
-debugging purposes.
-
-\subsubsection{no.uio.ifi.refaktor.utils}
-Utility package that contains all the functionality that has to do with parsing
-of source code. It also has utility classes for looking up handles to methods
-and types et cetera.
-
-\begin{description}
- \item[no.uio.ifi.refaktor.utils.caching] \hfill \\
- This package contains the caching manager for compilation units, along with
- classes for different caching strategies.
-
- \item[no.uio.ifi.refaktor.utils.nullobjects] \hfill \\
- Contains classes for creating different null objects. Most of the classes is
- used to represent null objects of different handle types. These null objects
- are returned from various utility classes instead of returning a \var{null}
- value when other values are not available.
-
-\end{description}
-
-
-
-\section{Continuous integration}
-The continuous integration server
-\name{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
-project\footnote{A work mostly done by the supervisor.}. It is used as a way to
-run tests and perform code coverage analysis.
-
-To be able to build the \name{Eclipse} plugins and run tests for them with Jenkins, the
-component assembly project
-\name{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
-through its plugin for Jenkins. Buckminster provides for a way to specify the
-resources needed for building a project and where and how to find them.
-Buckminster also handles the setup of a target environment to run the tests in.
-All this is needed because the code to build depends on an \name{Eclipse}
-installation with various plugins.
-
-\subsection{Problems with AspectJ}
-The Buckminster build worked fine until introducing AspectJ into the project.
-When building projects using AspectJ, there are some additional steps that needs
-to be performed. First of all, the aspects themselves must be compiled. Then the
-aspects needs to be woven with the classes they affect. This demands a process
-that does multiple passes over the source code.
-
-When using AspectJ with \name{Eclipse}, the specialized compilation and the
-weaving can be handled by the \name{AspectJ Development
-Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
-it complicates things when trying to build a project depending on \name{Eclipse}
-plugins outside of \name{Eclipse}. There is supposed to be a way to specify a
-compiler adapter for javac, together with the file extensions for the file types
-it shall operate. The AspectJ compiler adapter is called
-\typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
-with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
-setup this in the build properties file for the project containing the aspects,
-but to no avail. The project containing the aspects does not seem to be built at
-all, and the projects that depends on it complains that they cannot find certain
-classes.
-
-I then managed to write an \name{Ant}\footnote{\url{https://ant.apache.org/}}
-build file that utilizes the AspectJ compiler adapter, for the
-\code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
-take advantage of the environment set up by Buckminster. The solution to this
-particular problem was of a ``hacky'' nature. It involves exporting the plugin
-dependencies for the project to an Ant build file, and copy the exported path
-into the existing build script. But then the Ant script needs to know where the
-local \name{Eclipse} installation is located. This is no problem when building
-on a local machine, but to utilize the setup done by Buckminster is a problem
-still unsolved. To get the classpath for the build setup correctly, and here
-comes the most ``hacky'' part of the solution, the Ant script has a target for
-copying the classpath elements into a directory relative to the project
-directory and checking it into Git. When no \code{ECLIPSE\_HOME} property is set
-while running Ant, the script uses the copied plugins instead of the ones
-provided by the \name{Eclipse} installation when building the project. This
-obviously creates some problems with maintaining the list of dependencies in the
-Ant file, as well as remembering to copy the plugins every time the list of
-dependencies change.
-
-The Ant script described above is run by Jenkins before the Buckminster setup
-and build. When setup like this, the Buckminster build succeeds for the projects
-not using AspectJ, and the tests are run as normal. This is all good, but it
-feels a little scary, since the reason for Buckminster not working with AspectJ
-is still unknown.
-
-The problems with building with AspectJ on the Jenkins server lasted for a
-while, before they were solved. This is reflected in the ``Test Result Trend''
-and ``Code Coverage Trend'' reported by Jenkins.
-
-
\chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
Thinking}\label{ch:jdt_refactorings}
\section{Wishful Thinking}
\todoin{???}
+
\chapter{Composite Refactorings in Eclipse}
\section{A Simple Ad Hoc Model}
\subsection{Memento}
\todoin{Write}
+
+\chapter{Technicalities}
+
+\section{Source code organization}
+All the parts of this master project is under version control with
+\name{Git}\footnote{\url{http://git-scm.com/}}.
+
+The software written is organized as some \name{Eclipse} plugins. Writing a plugin is
+the natural way to utilize the API of \name{Eclipse}. This also makes it possible to
+provide a user interface to manually run operations on selections in program
+source code or whole projects/packages.
+
+When writing a plugin in \name{Eclipse}, one has access to resources such as the
+current workspace, the open editor and the current selection.
+
+The thesis work is contained in the following Eclipse projects:
+
+\begin{description}
+ \item[no.uio.ifi.refaktor] \hfill \\ This is the main Eclipse plugin
+ project, and contains all of the business logic for the plugin.
+
+ \item[no.uio.ifi.refaktor.tests] \hfill \\
+ This project contains the tests for the main plugin.
+
+ \item[no.uio.ifi.refaktor.examples] \hfill \\
+ Contains example code used in testing. It also contains code for managing
+ this example code, such as creating an Eclipse project from it before a test
+ run.
+
+ \item[no.uio.ifi.refaktor.benchmark] \hfill \\
+ This project contains code for running search based versions of the
+ composite refactoring over selected Eclipse projects.
+
+ \item[no.uio.ifi.refaktor.releng] \hfill \\
+ Contains the rmap, queries and target definitions needed by by Buckminster
+ on the Jenkins continuous integration server.
+
+\end{description}
+
+\subsection{The no.uio.ifi.refaktor project}
+
+\subsubsection{no.uio.ifi.refaktor.analyze}
+This package, and its subpackages, contains code that is used for analyzing Java
+source code. The most important subpackages are presented below.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.analyze.analyzers] \hfill \\
+ This package contains source code analyzers. These are usually responsible
+ for analyzing text selections or running specialized analyzers for different
+ kinds of entities. Their structure are often hierarchical. This means that
+ you have an analyzer for text selections, that in turn is utilized by an
+ analyzer that analyzes all the selections of a method. Then there are
+ analyzers for analyzing all the methods of a type, all the types of a
+ compilation unit, all the compilation units of a package, and, at last, all
+ of the packages in a project.
+
+ \item[no.uio.ifi.refaktor.analyze.checkers] \hfill \\
+ A package containing checkers. The checkers are classes used to validate
+ that a selection can be further analyzed and chosen as a candidate for a
+ refactoring. Invalidating properties can be such as usage of inner classes
+ or the need for multiple return values.
+
+ \item[no.uio.ifi.refaktor.analyze.collectors] \hfill \\
+ This package contains the property collectors. Collectors are used to gather
+ properties from a text selection. This is mostly properties regarding
+ referenced names and their occurrences. It is these properties that makes up
+ the basis for finding the best candidates for a refactoring.
+\end{description}
+
+\subsubsection{no.uio.ifi.refaktor.change}
+This package, and its subpackages, contains functionality for manipulate source
+code.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.change.changers] \hfill \\
+ This package contains source code changers. They are used to glue together
+ the analysis of source code and the actual execution of the changes.
+
+ \item[no.uio.ifi.refaktor.change.executors] \hfill \\
+ The executors that are responsible for making concrete changes are found in
+ this package. They are mostly used to create and execute one or more Eclipse
+ refactorings.
+
+ \item[no.uio.ifi.refaktor.change.processors] \hfill \\
+ Contains a refactoring processor for the \MoveMethod refactoring. The code
+ is stolen and modified to fix a bug. The related bug is described in
+ \myref{eclipse_bug_429416}.
+
+\end{description}
+
+\subsubsection{no.uio.ifi.refaktor.handlers}
+This package contains handlers for the commands defined in the plugin manifest.
+
+\subsubsection{no.uio.ifi.refaktor.prefix}
+This package contains the \type{Prefix} type that is the data representation of
+the prefixes found by the \type{PrefixesCollector}. It also contains the prefix
+set for storing and working with prefixes.
+
+\subsubsection{no.uio.ifi.refaktor.statistics}
+The package contains statistics functionality. Its heart is the statistics
+aspect that is responsible for gathering statistics during the execution of the
+\ExtractAndMoveMethod refactoring.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.statistics.reports] \hfill \\
+ This package contains a simple framework for generating reports from the
+ statistics data generated by the aspect. Currently, the only available
+ report type is a simple text report.
+
+\end{description}
+
+
+\subsubsection{no.uio.ifi.refaktor.textselection}
+This package contains the two custom text selections that are used extensively
+throughout the project. One of them is just a subclass of the other, to support
+the use of the memento pattern to optimize the memory usage during benchmarking.
+
+\subsubsection{no.uio.ifi.refaktor.debugging}
+The package contains a debug utility class. I addition to this, the package
+\code{no.uio.ifi.refaktor.utils.aspects} contains a couple of aspects used for
+debugging purposes.
+
+\subsubsection{no.uio.ifi.refaktor.utils}
+Utility package that contains all the functionality that has to do with parsing
+of source code. It also has utility classes for looking up handles to methods
+and types et cetera.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.utils.caching] \hfill \\
+ This package contains the caching manager for compilation units, along with
+ classes for different caching strategies.
+
+ \item[no.uio.ifi.refaktor.utils.nullobjects] \hfill \\
+ Contains classes for creating different null objects. Most of the classes is
+ used to represent null objects of different handle types. These null objects
+ are returned from various utility classes instead of returning a \var{null}
+ value when other values are not available.
+
+\end{description}
+
+\section{Continuous integration}
+The continuous integration server
+\name{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
+project\footnote{A work mostly done by the supervisor.}. It is used as a way to
+run tests and perform code coverage analysis.
+
+To be able to build the \name{Eclipse} plugins and run tests for them with Jenkins, the
+component assembly project
+\name{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
+through its plugin for Jenkins. Buckminster provides for a way to specify the
+resources needed for building a project and where and how to find them.
+Buckminster also handles the setup of a target environment to run the tests in.
+All this is needed because the code to build depends on an \name{Eclipse}
+installation with various plugins.
+
+\subsection{Problems with AspectJ}
+The Buckminster build worked fine until introducing AspectJ into the project.
+When building projects using AspectJ, there are some additional steps that needs
+to be performed. First of all, the aspects themselves must be compiled. Then the
+aspects needs to be woven with the classes they affect. This demands a process
+that does multiple passes over the source code.
+
+When using AspectJ with \name{Eclipse}, the specialized compilation and the
+weaving can be handled by the \name{AspectJ Development
+Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
+it complicates things when trying to build a project depending on \name{Eclipse}
+plugins outside of \name{Eclipse}. There is supposed to be a way to specify a
+compiler adapter for javac, together with the file extensions for the file types
+it shall operate. The AspectJ compiler adapter is called
+\typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
+with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
+setup this in the build properties file for the project containing the aspects,
+but to no avail. The project containing the aspects does not seem to be built at
+all, and the projects that depends on it complains that they cannot find certain
+classes.
+
+I then managed to write an \name{Ant}\footnote{\url{https://ant.apache.org/}}
+build file that utilizes the AspectJ compiler adapter, for the
+\code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
+take advantage of the environment set up by Buckminster. The solution to this
+particular problem was of a ``hacky'' nature. It involves exporting the plugin
+dependencies for the project to an Ant build file, and copy the exported path
+into the existing build script. But then the Ant script needs to know where the
+local \name{Eclipse} installation is located. This is no problem when building
+on a local machine, but to utilize the setup done by Buckminster is a problem
+still unsolved. To get the classpath for the build setup correctly, and here
+comes the most ``hacky'' part of the solution, the Ant script has a target for
+copying the classpath elements into a directory relative to the project
+directory and checking it into Git. When no \code{ECLIPSE\_HOME} property is set
+while running Ant, the script uses the copied plugins instead of the ones
+provided by the \name{Eclipse} installation when building the project. This
+obviously creates some problems with maintaining the list of dependencies in the
+Ant file, as well as remembering to copy the plugins every time the list of
+dependencies change.
+
+The Ant script described above is run by Jenkins before the Buckminster setup
+and build. When setup like this, the Buckminster build succeeds for the projects
+not using AspectJ, and the tests are run as normal. This is all good, but it
+feels a little scary, since the reason for Buckminster not working with AspectJ
+is still unknown.
+
+The problems with building with AspectJ on the Jenkins server lasted for a
+while, before they were solved. This is reflected in the ``Test Result Trend''
+and ``Code Coverage Trend'' reported by Jenkins.
+
+
\chapter{Eclipse Bugs Found}
\newcommand{\submittedBugReport}[1]{The submitted bug report can be found on
\url{#1}.}
git://git.uio.no / ifi-stolz-refaktor.git / commitdiff