feat(dissertation): write XPC plugin in full

This commit is contained in:
Anthony Berg 2024-05-22 12:39:16 +01:00
parent e3884791f6
commit 0f28ea0c9d
2 changed files with 87 additions and 35 deletions

View File

@ -715,43 +715,95 @@ memory leak and a massive memory write usage.
% Gradle % Gradle
% Testing % Testing
% GitHub CI % GitHub CI
\begin{itemize} % \begin{itemize}
\item XPC package is not published on a public Maven repository % \item XPC package is not published on a public Maven repository
\item There has been a pull request that was merged to the \textit{develop} branch % \item There has been a pull request that was merged to the \textit{develop} branch
that provides Maven POMs~\cite{xpc:pom}. However, the maintainer for the % that provides Maven POMs~\cite{xpc:pom}. However, the maintainer for the
project, at the time, did not have enough time to figure out the process of % project, at the time, did not have enough time to figure out the process of
publishing the package to a Maven repository~\cite{xpc:pom-time} % publishing the package to a Maven repository~\cite{xpc:pom-time}
\item Therefore, had to find an alternative way to implement % \item Therefore, had to find an alternative way to implement
\item Jitpack~\cite{jitpack} % \item Jitpack~\cite{jitpack}
\begin{itemize} % \begin{itemize}
\item In theory, simple to publish a repository, all that is required is a GitHub % \item In theory, simple to publish a repository, all that is required is a GitHub
repository and searching if one has already been created on JitPack or build and publish % repository and searching if one has already been created on JitPack or build and publish
a specific version % a specific version
\item However, due to the structure of the XPC repository, JitPack could not locate the % \item However, due to the structure of the XPC repository, JitPack could not locate the
build tools (Apache Maven in this case) as JitPack only searches on the root directory % build tools (Apache Maven in this case) as JitPack only searches on the root directory
for the compatible build tools % for the compatible build tools
\end{itemize} % \end{itemize}
\item Gradle gitRepository~\cite{gradle:gitRepository} % \item Gradle gitRepository~\cite{gradle:gitRepository}
\begin{itemize} % \begin{itemize}
\item There was not a lot of documentation % \item There was not a lot of documentation
\item Ambiguous on how to define directory for where the Java library is located in the Git repository % \item Ambiguous on how to define directory for where the Java library is located in the Git repository
\item However, as XPC was only built with Maven, Gradle was not able to add the dependency as \lstinline|gitRepository()| % \item However, as XPC was only built with Maven, Gradle was not able to add the dependency as \lstinline|gitRepository()|
only works with Gradle builds~\cite{gradle:gitRepoGradleOnly} % only works with Gradle builds~\cite{gradle:gitRepoGradleOnly}
\end{itemize} % \end{itemize}
\item Resorted to using a compiled Jar file and adding the dependency to Gradle % \item Resorted to using a compiled Jar file and adding the dependency to Gradle
\item Not happy about that because it means maintaining it will be more difficult as % \item Not happy about that because it means maintaining it will be more difficult as
it is not as simple as just changing the version number % it is not as simple as just changing the version number
\item Later, resorted to adding Gradle build files to XPC % \item Later, resorted to adding Gradle build files to XPC
\item Used automatic conversion from Maven to Gradle using \lstinline|gradle init| command~\cite{gradle:migratePOM} % \item Used automatic conversion from Maven to Gradle using \lstinline|gradle init| command~\cite{gradle:migratePOM}
\item Had to add local dependencies due to how Gradle works differently % \item Had to add local dependencies due to how Gradle works differently
\item Had to fix previous structure of Maven POM as the grouping as not good % \item Had to fix previous structure of Maven POM as the grouping as not good
\end{itemize} % \end{itemize}
The XPC Java library is not published on a public Maven repository. There has been a pull
request that was merged into the \textit{develop} branch that provides Maven POMs~\cite{xpc:pom}.
However, the maintainer of the project, at the time, did not have enough time to figure out
the process of publishing the package to a Maven repository~\cite{xpc:pom-time}.
Therefore, an alternative had to be found to implement the XPC library and there were
a few attempts made, before remaking the build files and publishing the library onto
GitHub's Maven repository.
The first tool found was Jitpack~\cite{jitpack}, which in theory makes it simple to
publish to their own public Maven repository, as the requirements to publish the package
was to input a desired GitHub repository and search if one has already been created on
JitPack. If it has not been, JitPack will build and publish a desired version of
the project. However, due to the structure of the XPC repository, JitPack was unable to
locate the build tools (Apache Maven in this case) as JitPack only searches the root directory
of the repository for the compatible build tools; XPC's build tools was in the \lstinline|Java/|
directory.
The next step was to look if Gradle was able to handle building and implementing libraries
from a GitHub repository, to which there is the \lstinline|gitRepository| function~\cite{gradle:gitRepository}.
It was a bit problematic trying to figure out how the \lstinline|gitRepository| function worked
as there is not a lot of documentation provided for it, and the documentation provided was
ambiguous on how to define the directory where the Java library is located in the Git
repository. However, as XPC was only built with Maven, Gradle was unable to add the dependency
to the project as \lstinline|gitRepository| only works with Gradle builds~\cite{gradle:gitRepoGradleOnly}.
Therefore, as a temporary solution, implementing the library was resorted to using the Jar
files provided with XPC and adding the dependency to Gradle. But this caused future maintainability
problems as updating the XPC library would require downloading the Jar file manually and replacing
the previous version. It also results in other tools being unable to check if there is a new
version of XPC available.
This temporary solution was later fixed by creating a fork of XPC and implementing
\textit{Gradle} build files.
As there already are \textit{Apache Maven} build files for the Java library,
the \lstinline|gradle init| command could be used to automatically generate
\textit{Gradle} build files based on the \textit{Apache Maven} build files~\cite{gradle:migratePOM}.
There was still some configuration required for the \textit{Gradle}
build files as the previous \textit{Apache Maven} configuration was not
properly implemented, resulting in fixing local dependencies and splitting up the
library into their respective package groups.
\subsubsection{Continuous Deployment of the Maven Package} \subsubsection{Continuous Deployment of the Maven Package}
\begin{itemize} % \begin{itemize}
\item Used GitHub's template for Gradle package publishing % \item Used GitHub's template for Gradle package publishing
\item Required some setup in Gradle build files % \item Required some setup in Gradle build files
\end{itemize} % \end{itemize}
To be able to use the new package created with \textit{Gradle} and publish them,
GitHub provides tools to publish \textit{Gradle} projects automatically.
This required defining in the build files on where \textit{Gradle} can
publish the packages.
This was combined GitHub's Gradle Continuous Deployment template
to publish the package, with the only change to the template being defining the working
directory to be the \lstinline|Java/|
\subsection{Submitting a Pull Request} \subsection{Submitting a Pull Request}
% What I did: % What I did:

Binary file not shown.