It is challenging to develop a cross-platform application, that is, an application that runs on multiple platforms. It requires not only code reuse but also an individual building or compilation for each platform, possibly with di erent development tools. In this paper, we show a simple approach for creating a cross-platform application using Maven, a build tool. We con gure a cross-platform development environment by composing a set of platform-speci c tools or integrated development environments (IDE's). The key idea of our approach is to use Maven to immediately propagate changes made using one platform tool, or IDE, to other platforms. For this, we decompose an application into platformindependent and platform-dependent parts and make the individual tools and IDE's share the platform-independent part in the form of a reusable component or library. We explain our approach in detail by creating a sample application that runs on the Java platform and the Android platform. The development environment consists of IntelliJ IDEA (for Java) and Android Studio. Our approach provides a way to set up a custom, cross-platform development environment by letting software developers pick platform-speci c tools of their choices. This helps maximize code reuse in a multi-platform application and creates a continuous integration environment.
This paper is about using a popular industry tool, Maven, to simplify tasks on
a personal computer with regards to programming in Java. The Apache Maven
is a project management and comprehension tool [
For clari cation in this paper, we will loosely consider the terms \library", \artifact", and \.jar les" to be interchangeable. All terms refer to the underlying .jar, .ear, or .war les that contain Java code. Technically, a library would be the code that is stored either on a hard drive or in a repository and is brought into a project to add the functionality of previously created code. In addition, an \artifact" is the compiled .jar le that is the result of the project currently being worked on. An \artifact" may be stand alone code, such as a nished project, or it may be used as a \library" for a bigger project. In addition, we will use the term \dependency" to refer to any \library" that is required by a Java program. 1.1
Maven can be used in the work sector as an integration tool that will allow completed modules to be shared between computers working on a common project. As each Java developer works on a portion of a larger project, the compiled code, along with its source code and Javadoc, is uploaded to a dedicated repository server set up by that company. Not only can code be uploaded to the repository, but any updates to other modules can be downloaded and integrated into the development environment. Thus, each developer can use their IDE (or other development environment, including the Windows command line or terminal on Linux or Mac) on their own computer. This is commonly known as cross-platform application development and continuous integration. 1.2
Our problem, however, was on a smaller scale. We mostly develop smaller applications for use only on our own computer. But we still had the need to develop our own libraries or Java .jar les that would provide some list of common functions for use in multiple other projects. These needs even extended to using the libraries we developed across multiple platforms such as Eclipse, IntelliJ IDEA, and Android Studio.
As we mention later in Section 5, we found that we could utilize Maven to automatically download dependencies, along with automatically setting up a correct and standardized project structure. Furthermore, the repository that is installed on the local computer leads to a personal level of \continuous integration" by delivering any artifact changes to any other environment on that computer. The details of this encounter are laid out in Section 5.
Programming in Java creates artifacts. An individual developer will be required to keep track of needed projects and artifacts. The interaction of projects or other dependencies can make future code alterations and artifact sharing di cult. Updating code becomes problematic after a su cient amount of time has passed. While there exist build and versioning methods in a business programming environment, there is little talk of implementing such a solution on a personal level for a student or full stack developer. In addition, learning these methodologies at a personal and educational level will help facilitate better programming practices when a student or developer moves into a business environment. Maven is a build tool that can be used to setup such an environment on a personal computer so that changes made in a Java .jar le from one environment can be immediately propagated to other programming environments, including updating and storing the project's source code and Javadocs. This creates a \personal continuous integration" environment for a single developer on a single workstation. 1.3
The rest of this paper is structured as follows. In Section 2, we give a quick overview of the Apache Maven, an open-source build tool. In Section 3, we describe the problem of keeping track of artifacts and libraries that can be used in other projects and the inherent di culties of having to update a library that is used as a dependency in multiple projects. In Section 4, we give an overview of how Maven uses repositories to download and store libraries. This commentary should help lay the groundwork for Section 5, where we go into detail about how we used the repository to successfully coordinate code and code changes across multiple development platforms. 2 2.1
As mentioned previously, Apache Maven is a key component of our approach. It is used as a glue for a set of platform-speci c tools, thus creating across-platform development environment.
Apache Maven is a software project management and comprehension tool,
and it can manage a project's build, reporting and documentation from a central
piece of information [
Archetypes Maven can be used to create a new project using archetypes. Archetype is a Maven project template or prototype from which other similar projects are to be generated [6, Chapter 3]. For example, we can generate a new Java project using the \quickstart" archetype, an archetype for generating a sample project3. The result of creating a new project with the \quickstart" 3 In this paper, we use IntelliJ IDEA and the \quickstart" archetype for reference. This procedure in other IDE's and command lines may vary slightly, but not signi cantly, since one of Maven's objectives is standardization. archetype is a project with directories already created and marked as \sources root", \resources root", \test sources root". As soon as a project is created from an archetype, the directory structure contains the folder for code along with a sample \Hello World" class and the corresponding JUnit test class for reference. POM Central to the way that Maven operates is the Project Object Model (POM ) [6, Chapter 9]. It is an XML representation of a Maven project held in a le named pom.xml containing all necessary information about a project. It is Maven's main con guration le and is used extensively to direct the project after the initial structure is created. In creating a project, there are three pieces of information that are vital and unique to each project: groupID, artifactID, and version. This information is among the rst few lines of the POM le and is used to distinguish each project in the repository. Below is an example of the rst half of a sample POM le from a newly created Maven quickstart project in IntelliJ: 1 <? xml v e r s i o n=" 1 . 0 " e n c o d i n g="UTF 8" ?> 2 3 <p r o j e c t xmlns=" h t t p : //maven . apache . org /POM/ 4 . 0 . 0 " x m l n s : x s i=" h t t p : //www. w3 . org /2001/XMLSchema i n s t a n c e " 4 x s i : s c h e m a L o c a t i o n=" h t t p : //maven . apache . org /POM/ 4 . 0 . 0 h t t p : //maven . apache . org / xsd /maven 4 . 0 . 0 . xsd "> <modelVersion>4 . 0 . 0</ modelVersion> <groupId>com . t i m e l y e p . com</ groupId> < a r t i f a c t I d>mavenTest1</ a r t i f a c t I d> <v e r s i o n>1.0 SNAPSHOT</ v e r s i o n> <name>mavenTest1</name> <u r l>h t t p : //www. example . com</ u r l> <p r o p e r t i e s> <p r o j e c t . b u i l d . s o u r c e E n c o d i n g>UTF 8</ p r o j e c t . b u i l d . s o u r c e E n c o d i n g> <maven . c o m p i l e r . s o u r c e>1 . 7</maven . c o m p i l e r . s o u r c e> <maven . c o m p i l e r . t a r g e t>1 . 7</maven . c o m p i l e r . t a r g e t> </ p r o p e r t i e s> <d e p e n d e n c i e s> <dependency> <groupId>j u n i t</ groupId> < a r t i f a c t I d>j u n i t</ a r t i f a c t I d> <v e r s i o n>4 . 1 1</ v e r s i o n> <s c o p e>t e s t</ s c o p e> </ dependency> </ d e p e n d e n c i e s> <! . . . >
Listing 1.1. The rst part of POM.xml
Notice the \dependencies" section of the POM.xml le. This is of particular importance because any library that is needed, such as the \junit", may be automatically imported into the project by listing it here. The three identi ers listed can be used to identify and add any dependency to the project. The quickstart project comes with the junit dependency listed in the POM le because the project structure includes JUnit testing. At the time of this writing, the basic Maven project has included JUnit version 4.11. This version of JUnit has its own dependency, namely, \hamcrest-core, version 1.3". No matter which environment is being used, specifying Junit 4.11 as a dependency will automatically download Hamcrest-core 1.3 from the online Maven repository. This is called a transitive dependency and is also key to Maven's functionality and this paper. Plugins After setup of the Maven directory structure and dependency listings in the POM.xml le, Maven provides for compilation, testing, reporting, and deployment of Java code, among other tasks. Each of these steps are speci ed by \Plugins" [6, Chapter 17] and each Plugin contains \goals", or speci c subtasks. There are two plugins that we wish to explain for the purpose of this introduction and case study. The rst is the \clean" plugin which simply deletes the folder called \target" along with any reports, artifacts, and test results that were created during a previous build. The second plugin is the \install" plugin which rst executes all the other plugins to compile, run tests, create reports, package the artifact, and nally, place the artifact into the local Maven repository on the local computer. This plugin provides the local repository with the three identi ers that will allow this compiled artifact to be used in other projects in the future. The fact that this plugin puts the artifact into the repository is a key to the case study outlined in Section 5. 2.2
For its overall functionality, Maven is a build tool that has been developed and maintained by Apache. Maven can be run from a command line or is available with extensive support in the three most popular Java IDE's: Eclipse, Netbeans, and IntelliJ IDEA, as well as others. The Maven repository is available to other build tools such as Gradle; Android Studio uses Gradle. As a build tool, Maven provides organization and standardization of project structures as previously outlined. Maven provides versioning of artifacts in the repository and provides testing and reporting tasks as part of the constant development process. The Maven repository is useful not only for organizing artifacts, but can also store source code and Javadoc for each artifact. Since Maven is based on plugins, or tasks, it has extensive support for development of custom plugins [6, Chapter 17]. As will be seen in this paper, Maven is scalable. While Maven provides support for large organizations and programming teams, Maven is also powerful on an individual scale.
Since there are multiple platforms which a developer can choose from, there is not one standard. In fact, a developer often needs to use more than one development environment. For example, a coder may have a preference for writing Java code in Eclipse or IntelliJ IDEA, but may prefer the enhanced GUI developing capabilities of Netbeans. This would require artifacts from one IDE to be imported as libraries into another IDE.
As programs or modules are developed, they often need to be used as building
blocks, or libraries, and integrated into larger projects. Even on a small,
individual scale, there is a need for continuous integration [
There are also other situations that create code that needs to be maintained.
One situation is in developing a library, and another is when a program developer
wants to extract a library, say as part of a Model-View-Control software
development/design pattern [
In summary, keeping track of Java archive (.jar, .war, or .ear) les becomes a task that must be handled by a Java programmer at the intermediate level and above. These Java artifacts become modules that work together, or they become the libraries that other modules use. After a developer has several projects on a local computer, it becomes tedious to keep track of artifact locations and versions. Should any artifact need to be updated, it must then be copied to any other project that used the artifact as a dependency. The core of our approach to con guring a cross-platform development environment is to decompose an application into two parts: a platform-independent part and a platform-dependent part.
{ Platform-independent part (PIP): the part of an application that doesn't depend on a speci c implementation platform such as application programming interfaces (API's). In MVC, the model is a good candidate for the PIP. { Platform-dependent part (PDP): the part of an application that does depend on a speci c platform, e.g., an API available only in a speci c execution environment. In MVC, the view and the view-speci c control correspond to the PDP.
The purpose of this distinction is to share the PIP across platforms while
developing a speci c PDP on each target platform. Thus, the key criterion on
determining the PIP of an application is whether the code can be shared on all
the target platforms of the application. Note that our notions of PIP and PDP
are similar to those of platform-independent models (PIM) and platform-speci c
models (PSM) in model-driven software development [
App1 PDP1 PIP IDE1
App2 PDP2 PIP IDE2
PIP
Maven repository
Figure 1 depicts our approach. The PIP of an application, say App1, is developed in IDE1 and is added to a Maven repository for sharing. Other IDEs like IDE2 and IDE3, possibly for di erent platforms, use the shared PIP to create platform-speci c applications, say App2 and App3. Once a project is con gured, the sharing of PIP is done automatically through Maven. It is of course possible to have multiple PIPs for an application, each developed using a di erent IDE. Below we summarize some of the Maven features that enable our approach. 4.1
Maven is a powerful and multifaceted build tool. Our approach uses two of
Maven's powerful aspects: the repository and dependency resolution. The rst
of these two items is the use of repositories. Maven has an online global repository
and a local repository for storing and versioning artifacts. The process for adding
artifacts to the global online repository is beyond the scope of this paper (refer
to [
Maven Online Global Repository Local Workstation
Project
Maven Local Repository The local Maven repository is a folder on a local workstation that can be browsed and viewed as any other folder. The default location is found in the ${user.home}/.m2/repository/ folder. There are three ways that artifacts can be added to the local repository. As previously mentioned, an artifact included in a Maven project (as a dependency) is downloaded from the online repository and is loaded into the local repository for current and future use. The second method is to execute the \install" goal of the Maven \Install" plugin. The \Install" plugin, or task, is used to compile the Java code, run any tests, generate the artifact, and then place the artifact, be it a .jar, .ear, or .war le, into the local Maven repository. Using the groupID, artifactID, and version speci ed in the build from the POM.xml le, the artifact can now be loaded as a dependency by any other project on the local machine. The third way that an artifact can be loaded into the local repository is by using the \install- le" goal of the Maven \install" plugin. This is usually used from the command line to specify that an existing externally created artifact is to be manually added to the local repository. 4.3
Of speci c importance is how Maven uses the local repository to resolve dependencies. When a project tells Maven that it needs a speci c library or artifact, it is done by adding the artifact's information to the dependency section of Maven's POM.xml le. Almost immediately, Maven loads the dependent artifact from the local Maven repository into the \External Library" section of the local project. If Maven does not nd the artifact in the local repository, it will look in the global online repository, nd the artifact, load the artifact into the local repository, and then into the project's \External Library" section. If Maven is unable to nd the artifact in the local or global repository, then it will display an error.
In addition to resolving dependencies speci ed in the POM.xml le, Maven also resolves transitive dependencies. A transitive dependency is when an artifact has its own dependency. Maven loads the artifact from the repositories and then searches the repositories for the dependencies listed by the artifact. Maven then also loads those transitive dependencies into the local repository and/or the project. 4.4
With these key features of using the Maven repository system to store artifacts and resolve dependencies, we can see several key results in practice. If Maven is used to build project A, then the resulting artifact of project A will be added to the local repository. Now that artifact A is in the repository, it can be used concurrently in any other local Maven project (e.g. Maven projects B, C, and D) on any development platform. Once project B, C, or D specify a dependency of artifact A, any further changes or updates to project A will automatically be deployed to the parent project. In addition, any dependencies that Maven project A speci ed will also be included in projects B, C, and D as transitive dependencies.
We performed a small case study by applying our approach to the development of an Android app. Our case study involves a development of a library based on the MVC architecture. We were writing an app for Android that used a library .jar le provided by a manufacturer. We did not like the functionality of the manufacturer's library and decided to make our own library to more easily expose the functionality that we wanted to use. Instead of doing this work in Android Studio, we decided to create a \model" of the functionality in a more familiar environment (IntelliJ IDEA), then access that library in Android Studio and then later in other platforms. We also wanted to perform coverage and mutation testing for our Java code, and there were several open source tools available for Java IDEs such as Eclipse and IntelliJ IDE. Below we summarize the steps we took in our case study along with our ndings. We rst developed our own library in IntelliJ IDE and used the library in Android Studio. Of course, we had to switch back and forth between the two IDEs.
POM Dependencies We rst had to learn how to add the manufacturer's .jar le into our IntelliJ IDEA project as an external library using Maven. Our research showed that we could specify the library as a static link to the folder location by adding it to the Maven POM.xml le. This, however, was discouraged in every help forum that presented a solution to this dependency problem. The better solution was to use a Maven command line to add the library (.jar le) to the Maven local repository, specify the library as a dependency in the Maven POM.xml le of our project, and then allow Maven to load the library into our project.
POM Plugins Once we started learning how to add dependencies into our
project, it became trivial to load the correct versions of testing and test coverage
tools such as Junit, JaCoCo [
However, one caveat of our approach is that a developer is responsible for
making sure that a PIP is indeed platform independent. For example, our library
should not use any Java language or API features that are not available on
Android4. This checking has to be done manually; it might be possible to automate
some of it using languages or tools such as AspectJ (e.g., static crosscutting) [
way this setup worked, we did not give it much more thought as we started our Android app. But we soon realized that our custom library had a bug and that we were going to have to go back and work on the original code in IntelliJ IDEA. Without closing Android Studio, we opened IntelliJ IDEA and pulled up our library code and xed the bug. We ran the Maven \clean" and \install" goals as we had done many times before. We then switched to the Android Studio window to continue to work. To our amazement, the change that we had made in our other IDE had already been updated in Android Studio. In a ash, Android Studio had seen that there was an update in our library and had loaded the new version from the local Maven repository.
Immediate Code Distribution The above nding would prove to be an incredible time saver as we had to make many changes to our library. For example, we would go back to our library code and add a eld with getters and setters to one of our Java classes and recompile. Then we would ip back over to our Android code and type the classname, hit the period \." and the new getters and setters would show up in the auto-completion list. This setup has allowed us to utilize the idea of continuous integration on a personal level. 6
We have come up with a method to develop a program component in one IDE and immediately have it published and deployed for access from a completely di erent IDE or environment. Our approach allows an individual developer to con gure a cross-platform development environment by composing a set of platform-speci c tools or integrated development environments (IDE's). We don't think that this is a totally new concept. Large projects are developed in this manner. But individual framework development can also bene t from this type of functionality even in the smallest environment. The Maven Central Repository is an incredible tool that allows production code to be con gured and used in various projects. But our contribution was to discover how Maven can be used on a single computer as an agile framework development tool in simultaneous programming environments.