Moving to Maven

Codename One is migrating to Maven. This will simplify some aspects of our build process and update/dependency management. Jump To Topic As the headline states, we’re moving to Maven, and leaving the ant-infested old build system behind. To be honest, I love using Ant. It is quick and dirty, and let’s me assemble ad-hoc build […]

Codename One is migrating to Maven. This will simplify some aspects of our build process and update/dependency management.

Moving to Maven - Codename One

Jump To Topic

As the headline states, we’re moving to Maven, and leaving the ant-infested old build system behind. To be honest, I love using Ant. It is quick and dirty, and let’s me assemble ad-hoc build workflows with little effort.

Migrating to Maven, at times, felt like strapping on a pair of cement boots. It is much more rigid than Ant, and much more opinionated. It’s the “Maven” way, or you’re in for a world of pain.

Why Maven?

So, you may ask, if Maven is so opinionated and painful, why are we adopting it? The reason is simply because it is worth it. Maven’s rigidity encourages better project hygiene — Builds that “just work“, without having to read through a page of build instructions, or embarking on a dependency scavenger hunt. Once you agree to surrender some of the flexibility that Ant provided, you can begin to enjoy a better developer experience, all round.

Dependencies can be added as XML snippets to the pom.xml file rather than downloaded manually. And they can be removed, or upgraded to new versions just as easily.

The Maven eco-system is mature and diverse, providing all kinds of plugins to augment your build process. Maven’s rigidity helps all of these plugins work together as if on an assembly line.

Maven projects are also well supported by all major IDEs. Rather than maintaining a separate project type for each IDE, we can provide a single Maven project archetype that can be used by any IDE – or even no IDE if you prefer.

New Features

As part of this move, we’ve included a few new features, some of which are simply by-products of using Maven.

Local Builds

Due to popular demand, we have provided support for building iOS, Android, and Cross-platform JavaSE Desktop apps locally. i.e. No build server or Codename One account required. More on this in a future blog post, but you can read more about it here.

Building JavaSE Desktop App

First-Class Kotlin Support

Kotlin support is now provided directly using the official Kotlin Maven plugin, and it is included into the Codename One Application archetype by default. Previously we had been providing Kotlin support via a cn1lib that included a Kotlin runtime, which we maintained ourselves by periodically updating it to newer versions of Kotlin.

For more information about developing Codename One apps in Kotlin, see Getting Started with the Bare-bones Kotlin App Template.

Support for Jar Dependencies

You can now use regular Java jar dependencies in your projects, with the caveat that your build will fail if you use any APIs (transitively) that aren’t supported by Codename One. You can paste regular dependency snippets from Maven central into your projects. In the past, only cn1libs were supported, as they ensured compliance with the Codename One API.

This is made possible by improvements to our compile-time compliance check which incorporates Proguard to determine which classes and methods are used in your app, then throw an error if it identifies any unsupported APIs.

Warning

It isn’t yet clear how useful this “jar” support will be, as many Jar dependencies on Maven central are directed at server-side audiences and are fundamentally incompatible with Codename One. For this reason, I still prefer to use cn1libs.

Publish your Libraries on Maven Central

You can now deploy your Codename One Library projects to Maven central so that others can use them by pasting a dependency snippet into the the pom.xml file of their Application projects. Cn1libs listed in Codename One Settings can now include a Maven dependency snippet which will be used when adding the library to a Maven project.

A Small Change in the Workflow

The transition to Maven should be nearly seamless, but you will notice a few changes in the development workflow.

The “Old” Ant Workflow


1

Install Codename One


2

Create New Project


3

Develop & Debug App


4

Add cn1libs


5

Create a Build

The old Ant workflow worked as follows:

1. Install the Codename One Plugin in your IDE via the “Install Plugin” mechanism in the IDE. We provide plugins for IntelliJ, NetBeans, and Eclipse.

2. Create a new Codename One Application project using the “New Project” option in your IDE.

3. Use the IDE’s editor to develop and debug your application.

4. Add cn1libs (plugins) to your project using Codename One Settings.

5. Use the Codename One menu in the IDE to perform tasks like building your project for iOS or Android.

The New Maven Workflow


1

Codename One initializer


2

Open in IDE


3

Develop & Debug App


4

Add cn1libs


5

Create a Build

With the Maven transition, you no longer need to install a plugin in your IDE, since all of the Major IDEs know how to speak maven out of the box. Instead you can use our Maven project archetypes to create new Application or Library projects – or use the new Codename One initializr tool to generate a new project for you from a growing selection of Application templates. More on that later.

So the workflow (with IDE) becomes:

1. Generate a new project from an application template using Codename One initializr.

2. Open the project in your preferred IDE.

3. Use the IDE’s editor to develop and debug your application.

4. Add cn1libs (plugins) to your project using Codename One Settings – or by pasting a regular Maven dependency snippet into your pom.xml file.

5. Use the provided configuration options in the IDE to build the project for various platforms such as iOS, Android, etc…​

Alternatively, and additionally, everything can be done via the command-line, if you prefer to run, debug, and build your projects that way.

Codename One initializr

Migrating Existing Projects

That new workflow is all fine and dandy for new projects, but what about my existing Codename One application project that I’ve been working on for the past 5 years?

You’re in luck. We’ve included a migration tool in the maven plugin that will convert Ant projects into the new Maven project format. All you need to do is run a single command, and you’ll be all set up to use Maven, like the rest of the cool kids.

Getting Started

Create your first Maven project right now using the Codename One initializr tool.

Read about the nuts and bolts in the Codename One Maven Developers Guide.

Watch the video demo of Codename One initializr.

Source: CodeName One