On this page you will find the release notes for each Xcode-Maven-Plugin release.
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.
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/.
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.
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.
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.
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.
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.
Use 1.11.2 instead since 1.11.0 crashes when executing verification checks with module builds.
Use 1.11.2 instead since 1.11.0 crashes when executing verification checks with module builds.
For details, please see here.
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).
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.