Release Notes

On this page you will find the release notes for each Xcode-Maven-Plugin release.


1.14.5

Features

xcode8 signing support added Singing methodology has been changed such that developer allowed to specify the signing identities via xcconfig
Bug fixes

No bug fixes

1.14.4

Features

No Features

Bug fixes

Removed SYMROOT from default/managed settings and allowed developer to override it.

1.14.3

Features

watchos2.0 support added to xcode-maven-plugin

Bug fixes

No bug fixes

1.14.2

Features

scheme support added

app build without signing support added: xcodebuild clean build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO

Bug fixes

No bug fixes

1.14.1

Features

no new feature introduced
Bug fixes

Signing of applications is not possible when building with newer (than 6.0.0) Xcode versions.

1.14.0

Features

Git support for versions.xml

When scm releated information is provided to the plugin (for details see here) a file containing this information will be attached as side artifact and the corresponding information is also contained in applications (ipa files). Up to now only perforce was supported as scm. With this release also git is supported.

Bug fixes

No bug fixes

1.13.0

Features

Enable FindBugs and JaCoCo

In order to optimize our code, we have enabled JaCoCo code coverage and FindBugs static analysis. For more information, see http://findbugs.sourceforge.net/ and http://www.eclemma.org/jacoco/.

Embedded Framework Packaging

If you configure your Xcode project to build an Xcode framework (see https://github.com/kstenerud/iOS-Universal-Framework) it is possible to execute this build from the Xcode Maven Plugin and upload the build results to the binary repository. Additionally to the framework artifact, the generated embedded framework will be packaged and prepared for deployment.

Bug Fixes

Fix: Filesystem not strict case sensitive.

Mac file system does not properly distinguish between upper and lower case characters. Inside java files with case differences are considered to be not equal. This causes trouble during build preparation (copy files step). To avoid such problems, we use only canonical files.

1.12.0

Features

Anonymize SCM location

It is possible to provide the transitive envelope of an artifact inside a versions.xml file that could be deployed as side artifact. In this file the scm information (changelist, scm server) is provided. With this change it is possible to anonymize the scm server so that only parts of the server are exposed. The scm information will be anonymized if flag hideConfidentialInformation is set to true.

Bug Fixes

No bug fixes

1.11.2

Features

No new features

Bug Fixes

Fix crashing build when running verification checkes for module builds (again).

The class loader infrastructure of maven is based on class realms which is a subclass of URLClassloader. For each verification check we introduce a new realm as child of the realm which is reponsible for the xcode-maven-plugin. The name of the child class realm was up to now created based on the name of the class realm for the xcode-maven-plugin and the name of the class representing the verification check. In case of multimodule projects we got name clashes when a verification check was executed on the second xcode releated project inside the reactor. Now we append an index to the name of the class realm used for the verification checks. This index ensures that the name of each class realm is unique.

Fix crashing build when the version file of a predecessor project contains invalid content

For each project a versions.xml file is created during the build. This file contains the dependency tree for a project. When this file is created during the build the versions.xml file for the anchestor projects are resolved in order to be able to provide the full transitive envelop of a project. In case a version file contains invalid content the build crashes. With this fix a version file with invalid content is ignored.

1.11.1

  Use 1.11.2 instead since 1.11.0 crashes when executing verification checks with module builds.

Features

No new features

Bug Fixes

Fix crashing build when running verification checks for module builds.

1.11.0

  Use 1.11.2 instead since 1.11.0 crashes when executing verification checks with module builds.

Features

Xcode Maven Plugin API for verification checks defined.

For details, please see here.

Bug fixes

Access check definition file

Fixed problem when accessing the check definition file for verification checks (see release 1.9.3) via http and https.


1.10.0

Features

Frameworks supported for all configurations

Until version 1.9.3 the frameworks were built only for the configuration provided with parameter primaryFmwkConfiguration. Starting with version 1.9.4 frameworks are built and deployed for all configurations specified in the pom. If nothing is specified the default configurations apply (Debug, Release).

Improvements

Each class representing a verification check (see release 1.9.3) is now loaded in a dedicated class loader that is a child of the class loader of the xcode-maven-plugin. The dependency to the xcode-maven-plugin and the corresponding transitive envelope is ommited inside the class loader of the verification check. Dependencies declared by the project hosting the verification check are also ommited in case they are also contained in the transitive envelope of the xcode-maven-plugin.

Bug fixes

Missing explicit dependency to commons-lang

The apache commons-lang api was used but not explicitly declared. The commons-lang api was only available due to a transitive dependency. Now the reference to commons-lang is declared explicitly.

Docu Update

Documentation for frameworks

The documentation for frameworks has been adjusted according to the new feature described above.

New how-to for keychain handling in master/slave environments

This guide explains how keychains should be opened when running in a master/slave environment.

1.9.3

Features

Verification Check infrastructure for applications

Applications are reviewed by Apple during the upload into the AppStore. In order to reduce the risk to be rejected during that upload some checks could be applied to the application prior to the upload. The infrastructure for such tests is provided. For details see here. Only the infrastructure is provided, the verification checks themselves are not contained in the xcode-maven-plugin.

Bug Fixes

Artifact redirect links were provided also for artifacts downloaded during the deploy phase.

In rare cases downloads happen during the deploy phase. In this cases artifact redirect files were also written for the downloaded artifacts.

Docu Update

How-to section for OTA Service configuration

The OTA Service (Over-the-Air Deployment Service) is provided as part of the xcode-maven-plugin eco system. With this how-to it is explained how to use the OTA Service in builds using the xcode-maven-plugin.


1.9.2

Features

No new features.

Bug Fixes

Dependencies with other types than xcode-lib or xcode-framework causes NullPointerExceptions

A NullPointerException was raised when dependencies with types other than xcode-lib or xcode-framework are provided within the maven project without defining how to handle these dependencies inside the configuration section of the xcode-maven-plugin (see below: Support of transitive archive (zip) components).


1.9.1

Features

Support alternate public header path

Some Xcode libraries create a namespacing for their header files in the build process by putting the header files inside a directory structure according to the namespacing policy. In order to reflect the namespacing in the packaged header tar files created by the xcode-maven-plugin, it is required to provide a parent folder of the PUBLIC_HEADER_FOLDER_PATH as it is defined in the xcode project. With this alternate public header path the headers are packaged containing the remaining part of the folder structure below the alternate public header folder path. The alternate public header path has to be defined into the plugin configuration as alternatePublicHeaderFolderPath in the plugin configuration. This alternate public header path must be a parent folder of the public header path into Xcode.

OTA Service

The Velocity template used to generate the over-the-air deployment HTML page is now configurable. This way the Velocity template can be changed without the need to release and use a new version of the Xcode Maven plugin. To specify a Velocity template path set an absolute path via the property mios.ota-service.buildHtmlTemplate.

E.g. mvn clean install -Dmios.ota-service.buildHtmlTemplate=/Users/myuser/otaBuildTemplate.html

You can use any properties and environment variables inside the Velocity template.

Support of transitive archive (zip) components

You could now use archive components containing for example specific Html5 content - you could decide whether to copy, unpack or use as a bundle such a component.


1.9.0

(use 1.9.1)


1.8.1

Bug Fixes

Wrong file pointers

During the deployment of files into a remote repository we listen to deploy actions and create pointer files pointing to the deployed artifacts. These pointer files resides on the build server and simplifies the retrieval of artifacts inside nexus. In case of multi module builds all pointer files pointed to the artifacts of the last project in the module. With this fix each pointer file points to the artifact it should point to.


1.8.0

Features

Xcode settings and options

Xcode settings and options can now be handed over from command line or from the settings.xml. Settings and options provided this way supersedes settings and options provided in the xcodeproject itself or in the projects pom file.

Settings and options can be provided from the command line with -Dxcode.settings.NAME=VALUE or in this settings.xml in the properties section <xcode.settings.NAME>VALUE</>. For options use prefix xcode.options accordingly.

Bug Fixes

Symbolic links do not work in local builds

With version 1.5.1 symbolic links for headers and libraries have been introduced inside target/headers and target/libs. When new dependencies are added to the project and mvn clean initialize is called, the binaries and the headers were symbolic linked inside the target folder. By linking this libraries in Xcode, the symbolic links are resolved which finally leads to paths pointing to locations outside the project. Usage of symbolic links is now disabled by default for local builds and can be switched on with property xcode.useSymbolicLinks. If the flag is set to true symbolic links are used.

Into the central build, the xcode.useSymbolicLinks property is set to true for improving the build time and the required disk space.

Wrong packaging of dSYM bundles

Fix packaging the dSYM bundle. The dSYM bundle is deployed as a zip archive in Nexus. This zip file was packaged with incorrect structure, i.e after unzipping you did not have folder named <your-product-name>.app.dSYM and had to manually restore it in order to be able to analyze crash reports, received from customers.