• New Configurator API

  XMvn 3.0.0 adds Configurator API service, which exposes XMvn configuration as Java beans.

• New MetadataResolver API

  XMvn 3.0.0 adds new API service - MetadataResolver, which allows resolution of metadata for artifacts installed in the system.

• Service locator API

  Instances of services provided by XMvn API can now be obtained using service locator, without using dependency injection. This change obsoleted XMvn Launcher module, which was removed in XMvn 3.0.0.

• New default compiler source setting

  Since XMvn 3.0.0 compilerSource setting has a new default value equal to 1.6.

• Launcher scripts removed from binary tarball

  Launcher scripts for tools, such as xmvn-resolve, xmvn-install etc., as well as xmvn launcher, were removed. From now on, tools can be ran using java -jar syntax and XMvn itself can be ran using standard mvn launcher. This is upstream change only - downstream distributions may continue to provide distro-specific launchers.

• Ivy connector removed from binary tarball

  Since XMvn 3.0.0, connector for Apache Ivy is no longer included in binary tarball.

• Ignoring duplicate metadata made configurable

  XMvn versions prior to 3.0.0 would previously always ignore installed artifacts, which have multiple metadata, for example when more than one package provides the same artifact. XMvn 3.0.0 added new option ignoreDuplicateMetadata, which can be used to control this behavior. ignoreDuplicateMetadata is true by default, but when set to false XMvn will resolve metadata for the first artifact found, ignoring others.

• POM files for Tycho projects are not installed

  Projects built with Eclipse Tycho install JAR files in private locations specific to Eclipse, so POM files and metadata for them are not installed.

• PoC implementation of Javadoc MOJO

  XMvn 3.0.0 added new MOJO, which can be used to generate API documentation (javadocs) as alternative to Maven Javadoc Plugin. Goal xmvn-mojo:javadoc works in similar way to javadoc:aggregate, but it has some advantages over it. XMvn javadoc makes javadocs more consistent between packages - it unifies javadoc options, doclet used, CSS styles, and so on. It opens possibilities for better integration with distributions in the future, like for example distro-specific themes, links or dependencies between javadoc packages. It also has much fewer dependencies, which means smaller builroots and faster builds.

• More accurate builddep MOJO

  Builddep MOJO, which can be used for auto-generating build-requires, was rewritten almost from scratch. Now its output should be much more accurate.

• Partial compatibility with Maven 3.0

  XMvn 3.0.0 restores partial compatibility with Maven 3.0.

• Ignoring runtime exceptions during bytecode analysis

  Previously XMvn Installer would terminate abnormally on bytecode it couldn't parse, such as newer bytecode than recognized by ASM library which XMvn uses. This has been fixed in XMvn 3.0.0.

• Coping with whitespaces in file names

  When installing files with whitespace in their names, XMvn Installer would previously generate incorrect file descriptor. XMvn 3.0.0 fixes this bug.

• Release on Maven Central Repository

  Since 3.0.0 XMvn will be available in Maven Central Repository.

• Migrated from fedorahosted.org to GitHub

  Since fedorahosted.org, the service that XMvn used to be hosted on, was decommissioned, XMvn source repository was moved to new home, which is now at GitHub: https://github.com/fedora-java/xmvn/

• XMvn Gradle plugin

  XMvn Gradle plugin was implemented in version 2.5.0. When applied on a project, this plugin automatically configures repositories in local mode, so that project dependencies can be resolved from system repository. It also provides xmvnInstall task, which can be used to install artifacts produced by the build with XMvn Installer.

• Custom buildroot option for XMvn Subst

  XMvn Subst now accepts a new option, --root, which specifies buildroot from which XMvn should resolve artifacts, in addition to standard locations. This option can be used for symlinking JARs produced during build. (Bug: 1226251)

• Builddep MOJO fixes

  Builddep MOJO was rewritten from scratch. The new code is more generic and supports many corner case in which the previous version produced incorrect results (bugs: 1217422, 1217425, 1217462, 1217473).

• Warning when builddep MOJO is ran with pure Maven

  XMvn builddep MOJO 2.5.0 will print a warning when it's ran outsides of XMvn.

• Allowing manifacs injection for invalid JAR files

  OpenJDK has a sanity check that prevents adding duplicate entries to ZIP streams. When trying to inject manifests to JAR files with duplicate entries XMvn would previously fail with "ZipException: duplicate entry". XMvn 2.5.0 added a workaround that allows manifest injection to such invalid JAR files.

• GradleResolver crash when resolving tools.jar

  XMvn 2.5.0 fixes a bug that caused Gradle resolver crash when trying to resolve tools.jar artifact.

• Crash when effective POM generation failed

  XMvn 2.5.0 fixes a bug that caused crash with NullPointerException uppon failure to generate effective POM.

• Slashes in effective POM names are replaced with dots

  XMvn versions prior to 2.5.0 would try to create effective POM files with artifactID as name, even if it contain slash character. XMvn 2.5.0 fixes this bug.

XMvn 2.5.0 drops support for rarely-used compatibility configuration suffixes.

• Support for Mock pm_request plugin

  XMvn 2.4.0 supports on-demand artifact installation via Mock pm_request plugin. When this plugin is enabled then XMvn will try to install any missing artifacts instead of failing.

• Java requires

  Generation of Java requires (rhbz#1086335) was fixed in this XMvn release.

• Effective POM caching

  XMvn 2.4.0 fixes tries to avoid creating polluting system with temporary files. In particular effective POMs are cached in XDG cache directory.

• NullPointerException during model validation

  XMvn 2.3.2 fixes a NullPointerException regression in XMvnModelValidator, which occured during validation of models without build instructions.

• Installation of multiple artifacts in one directory

  Version 2.3.1 fixes a bug that caused XMvn Install to fail when trying to install multiple artifacts to the same directory.

• Optional dependencies in effective POM

  Since version 2.3.1 effective POMs generated by XMvn include information whether given project dependency is optional or not.

• Ownership of generated directories

  XMvn Install 2.3.0 generates RPM directory ownership (%dir) for subdirectories it creates.

• Minimal compiler source/target 1.6

  XMvn now enforces source and target values of at least 1.6 in Maven Compiler Plugin.

• Deployer optional dependencies

  Metadata format used in 2.3.0 contains new field, which can be used to flag any artifact dependency as optional. XMvn deployer and installer were modified to set this flag for generated metadata.

• Skip generating %attr for symbolic links

  XMvn 2.3.0 doesn't generate RPM file attributes (%attr) for symbolic links it creates, which prevents RPM warnings.

• Depmap support dropped

  XMvn 2.3.0 removes support for depmaps, which was deprecated for some time.

• Dependecy on Java 8

  XMvn now requires Java 8 to run.

• Ivy connector regression bugfix

  XMvn 2.1.1 introduced regression in Ivy connector, which prevented parent POMs from being resolved correctly. Version 2.2.1 fixes this regression.

• Gradle connector

  XMvn 2.2.0 includes connector for Gradle, which provides integration of Gradle with XMvn. It provides an adapter which allows XMvn resolver to be used as Gradle resolver.

• Software collection support

  Several bugs related to support for software collections were fixed.

• OSGi artifact installation

  XMvn MOJO now correctly passes fully qualified OSGi artifact verions to Eclipse P2 installer.

• Resolution of Ivy artifacts with classifiers

  XMvn 2.1.1 fixes a bug which could cause some Ivy artifacts with classifiers not to be resolved correctly in some cases.

• Metadata format improvement

  requestedVersion field in artifact metadata was made optional with default value of "SYSTEM".

• Temp file cleanup

  Upon JVM termination XMvn will now remove more temporary files to conserve disk space.

• Eclipse plugin detection

  XMvn 2.1.0 will refuse to install Eclipse plugins if XMvn P2 plugin is not installed. (This plugin is shipped as a part of fedoraproject-p2.)

• Javadoc report location capture

  Now XMvn will properly detect exact location where Maven Javadoc Plugin saves generated API documentation to allow other tools to refer to this location.

• Compiler options capture

  During build XMvn now captures compiler source and target used to build each module. These values can be later used by other tools to generate dependencies on particular Java version.

• Merge dependencies when merging metapackages

  This release of XMvn fixes a bug which prevented artifact dependencies to be merged in package metadata, which could result in incomplete package requires.

• Fix crashes during artifact installation

  XMvn 2.1.0 fixes some crashes during artifact installation.

• Property to disable effective POMs

  XMvn 2.0.1 allows to globally disable generation and resolution of effective POMs by setting system property xmvn.resolver.disableEffectivePom

• Fixed JAR post-processing during installation

  In some cases XMvn 2.0.0 may have failed to inject Javapackages manifest entries to JARs it installs. It also failed to detect native code inside JARs. This was fixed in XMvn 2.0.1.

• Fixed return code of xmvn-install

  XMvn Installer CLI used to return zero exit code even if installation failed. This was corrected in XMvn 2.0.1.

• Implemented lazy loading of metadata

  XMvn spawns background threads to initialize some "eager" singletons in order to minimize delay on their first use and improve overall performance. Since Java allows isolated class realms to have multiple singleton instances, hundreds of initializer threads may have be spawned in applications heavily using isolated realms, such as in unit testing.

  XMvn 2.0.1 implemented lazy initialization instead of eager initialization, which results in lower performance, but better worst-case behavior.

• Fixed artifact resolution from local workspace repository

  XMvn 2.0.1 fixes a regression introduced in version 2.0.0 - artifacts were no longer resolved from local workspace repository ($PWD/.m2).

• New metadata format

  XMvn 2.0.0 now reads and writes the new Javapackages metadata format instead of dependency maps. Read-only depmap support remains, but was deprecated.

• Ivy integration

  Starting with version 2.0.0 XMvn provides a connector for Apache Ivy which enables Ivy or its clients to have access to XMvn resolver and deployer.

  This feature enables Ant build scripts using Ivy tasks or other build systems that use Ivy to use local system artifact repository to resolve dependencies and more, making Ivy a first-class citizen among other build systems.

• Artifact deployment

  Starting with version 2.0.0 XMvn provides an API to deploy artifacts to system repositories.

• API separation

  XMvn 2.0.0 ships with a separate API module, which makes it more clear which parts of XMvn are part of public interface and which are considered as implementation details.

• Class loader isolation

  XMvn 2.0.0 Core implementation is now using an isolated class loader to prevent unwanted classes from polluting Maven Core or user classpath.

• Improved logging

  XMvn logging was ported from Plexus to SLF4J. This makes it possible to easily set different logging levels for different subsystems as well as use a custom backend.

  Besides that some logging messages were improved and new ones were added.

• Dependency version report

  At the end of a build XMvn can now print a dependency version report, which contains information about requested and resolved dependency artifact versions.

• Improved Tycho integration

  XMvn 2.0.0 works better with Eclipse Tycho. In particular system-scoped OSGi dependencies injected by Tycho are now ignored and don't cause installation failures any longer.

• Repository filtering

  XMvn 2.0.0 improves artifact filtering for installation repositories.

• Migration to JSR-330

  Internal dependency injection mechanisms were migrated from Sisu Plexus to Sisu Inject, which provides JSR-330-compatible IoC mechanisms.

• XMvn Connector rename

  xmvn-connector module was renamed to xmvn-connector-aether to reflect addition of the new xmvn-connector-ivy module.

• Removal of deprecated API

  Parts of XMvn API which were marked as deprecated were removed.

• Namespace cleanup

  Java package names were renamed from org.fedoraproject.maven to org.fedoraproject.xmvn.

• XMvn Installer rewrite

  XMvn Installer was rewritten from scratch in 2.0.0 and a new pluggable API was added.

• Effective POM installation

  Effective POM's are no longer installed during package build. XMvn resolver is able to generate them on demand during package build from the new Javapackages metadata.

• Limited support for absolute JPP artifact files

  Artifact files specified as absolute paths pointing to arbitrary locations are now allowed. They are implemented as symbolic links which are pointing to the primary artifact file, which must be explicitly specified as non-absolute file.

  Appropriate suffixes are added depending on artifact version, classifier and extension. As absolute symlinks can be placed at any location, configured repositories are not taken into account and flat repository layout is always assumed.

  Absolute symlinks are only created for artifact files and attached artifacts, but not for POM files. Absolute files for artifacts with no files (i.e. POM artifacts) are silently ignored.

• Fix NullPointerException bug in installer code
• Allow file installation in root directory

  XMvn was unable to install files in root directory because of false assumption that every directory has a parent. This was fixed in version 1.4.0.

• Installation of Ivy modules

  Since version 1.3.0 XMvn can install Ivy modules. Ivy descriptor files are transparently converted to Maven POMs and installed as such. This feature is still experimental.

• Fix manifest injection

  XMvn no longer injects manifests to JAR files that have no manifests. This also fixes a bug that caused POM files to be replaced with empty JAR files in some cases.

• Delay simplification of effective POMs

  Effective POMs are now simplified during package installation, not build. This way installer has enough information needed to generate auto-requires on Java version.

• Make resolver ignore artifact types

  Configured artifact types by repositories no longer affect behaviour of XMvn resolver, but are still understood by installer.

• Fix potential resource leaks

  XMvn 1.3.0 fixes a few bugs in which certain resources (mostly files) were not released (closed) even when they were no longer needed.

• Artifact information in manifests

  Since version 1.2.0 XMvn injects artifact coordinates to manifests of artifact files it installs. XMvn Subst can read this information and use it to locate artifacts in the system. This way artifacts that do not contain pom.properties can still be correctly replaced with symbolic links by XMvn Subst.

• Artifacts using native code

  Previous versions only tried to detect artifacts containing native code. In addition to that XMvn version 1.2.0 also attempts to detect JAR files using native code. This means that such JARs can be installed to a different location than JARs not containing and not using native code.

• Stereotype support in auto-requires

  XMvn Installer did not take into account artifact stereotypes. This caused generated auto-requires to be incorrect in some cases. This bug was partially fixed by embedding default Maven artifact type mappings. This means that any non-standard stereotypes may still be handled incorrectly and produce unsatisfiable dependencies.

• Generated self-requires

  Auto-requires generator was corrected to generate correct auto-requires in complex cases involving compatibility versions, namespaces and dependencies on artifacts provided by the same package.

• Dangling symlinks

  Version 1.1.0 fixes a bug that caused relative symbolic links creted by XMvn to be incorrect in many cases.

• Improved debugging messages

  XMvn 1.1.0 tries to better describe reasons of build failure. Some new logging messages were introduced. New useful data was added to some other messages. Effective packaging rules are printed even for skipped artifacts.

• Strict mode of XMvn Subst

  XMvn Subst 1.1.0 introduced a new option -- strict mode. In this mode XMvn Subst will fail if there are any artifacts that were unable to replace with symbolic links.

• Dry run mode of XMvn Subst

  XMvn Subst 1.1.0 supports dru run. In this mode it will fail not replace any artifacts, but report what would be normally done.

• Skipped artifacts

  Metadata generated by XMvn 1.1.0 and later versions includes information about artifacts which were part of Maven reactor, but were not installed. This information will be used by Java Packages Tools for performing better sanity checks on built packages.

• Compressed metadata files

  XMvn 1.1.0 can read metadata files compressed with GNU zip. For bigger files this will allow them to be stored entirely in i-nodes and therefore improve performance and decrease disk usage.

• Missing requires on parent POM artifacts

  Version 1.0.0 introduced a regression -- automatic dependencies on parent POM packages were no longer generated. Version 1.0.2 fixes this regression.

• Missing sanity checks for missing models

  In version 1.0.2 more strict sanity checks were added for cases when artifacts were installed with missing model (POM) files.

• Flexible repositories

  Since version 1.0.0 XMvn has a new way of configuring repositories from which artifacts are resolved and to which they are installed. Several aspects of artifact resolution which were hardcoded in previous versions of XMvn are configurable since version 1.0.0.

• Classifiers and extensions

  Previous versions of XMvn lacked support for artifact classifiers and for artifact extensions other than jar and pom. Since version 1.0.0 XMvn supports resolution and installation of artifacts with any classifier and extension.

• Compatibility versions

  Although previous versions were able to resolve versioned artifacts (also knows as compatibility versions), there was no support for installing versioned artifacts. Since version 1.0.0 XMvn fully supports compatibility versions -- it is able to both resolve and install versioned artifacts.

• Installing artifacts not produced in reactor

  Sometimes there is a need to install artifacts not produced in Maven reactor, but generated by other means, like custom script or other build system. Since version 1.0.0 XMvn allows installation of such artifacts along with artifacts produced by Maven build.

• Artifact namespaces

  XMvn 1.0.0 allows artifacts to have namespaces, which limits possible name clashes and allows several versions of the same artifact to be installed more easily without the need to use compatibility versions. This feature can be used to implement support for software collections.

• Improved performance of resolver

  Reading depmap fragments is the dominant operation when running short-living tools like XMvn Resolve or XMvn Subst. Since version 1.0.0 depmaps are being read in parallel, which improves performance on multi-processor systems.

• Improved build-requires generator

  Dependency did not include all possible cases when generating build-requires. This has been improved in XMvn 1.0.0.

• Improved support for compatibility versions

  Versioned artifacts are now resolved in simpler and more obvious way.

• Improved handling of Java versions

  Besides standard versions like 1.4 or 1.7 XMvn now recognizes other visioning schemes like 7.0 or 7, as well as jsr14 and cldc1.1.

• Improved error handling in command-line tools

  Command like tools now print better error messages and are less likely to print stack traces for user errors.

• Possible concurrency bug when creating symbolic links

  Possible concurrency bug when creating symbolic links was avoided by using file system atomic operations, if supported by file system.

• XMvn Subst

  Version 0.5.0 brings a new tool - XMvn Subst. This tool is able to replace individual artifact files with symbolic links to corresponding files in system artifact repository. It is also able to recursively process whole directories.

• XMvn Bisect

  Since version 0.5.0 a new tool - XMvn Bisect - is available. This tool helps automating debugging build failures using bisection method. It first builds project using dependencies coming from system repository only, next only from remote repositories, then halves dependency set recursively until it finds differences which are causing build failure.

• Basic support for dependency version ranges

  In previous versions XMvn did not support dependency version ranges. If range was used in POM then Maven would try to resolve all available versions from remote repository and pick the best match.

  Starting from XMvn 0.5.0 any dependency version ranges without recommended version specified are replaced with version SYSTEM, which means default artifact version in the system. This prevents Maven from trying to use remote repositories.

• Improved configuration loading

  Starting from version 0.5.0 configuration is read only once at the beginning of the build. In previous versions configuration was read every time it was needed. The new approach is not only faster, but also allows configuration to be modified by plugins during runtime.

• Better handling of inaccurate configuration

  In previous versions any packaging rules that didn't match any artifact in the reactor were silently ignored. Since version 0.5.0 any non-optional packaging rule that is not used causes the build to fail.

• Incorrect path to JPP artifacts

  Paths to JPP artifacts containing more than one slash in groupId were generated incorrectly. This could cause dependency resolution failures in some rare cases. This bug was fixed in version 0.5.0.

• Fixed exit code of XMvn Resolve

  Now xmvn-resolve returns 0 when it successfully resolves all artifacts, 1 on failure to resolve one or more artifacts and 2 when some other error occurs. In the last case a stack trace is printed too.

• Fixed installation of artifact marked as not installable

  Before version 0.5.0 XMvn tried to find installers for all artifacts in the reactor, even for those marked as not installable. As a result reactors that contained artifacts with unsupported packaging types failed to build, even if instalation of these artifacts was explicitly skipped.

  This bug was fixed in XMvn 0.5.0, in which artifact packaging type has to be supported only if the artifact is installable.

• Empty fields in artifact aliases

  Version 0.4.0 introduced a regression - empty fields in artifact aliases were not replaced by corresponding fields from the main artifact. This bug was fixed in version 0.4.2.

• Read configuration files in sorted order

  In previous versions configuration files were read in in the system default order. This was causing unpredictable results in cases where the order of configuration did matter.

• Correctly handle conflicts between explicit packaging rules and implicit singleton packaging rule

  Previously it was unspecified which of rules would take precedence. Since version 0.4.1 the first rule encountered will be used.

• Don't set scope of optional compile dependencies to provided

  The code that was setting scope of optional dependencies to provided was removed. This code was meant to be used for testing only and it was never supposed to make into a stable release.

• Improved configuration

  Starting from version 0.4.0 XMvn is configured using XML configuration files instead of environmental variables. The configuration model was built using Modello and it's fully documented. The XML model supports new configuration options, it's more flexible and has new features, such as inheritance of different configuration files.

• Improved bootstrapping

  Prior to version 0.4.0 XMvn used to be bootstrapped using a custom launcher code. In version 0.4.0 XMvn Launcher module was dropped and bootstrapping process was migrated to standard Classworlds launcher. Now the bootstrap process can be controlled with standard m2.conf file.

• New site

  Now XMvn site is created from XMvn POM using Maven Site Plugin. It contains much more detailed information about the project, including release notes, Javadocs, source cross-reference and much more.

• XMvn installation now uses standard Maven directory layout, which improves integration with other Maven components and fixes problems with Maven Invoker.

• Improved support for Fedora Software Collections
• Enhanced artifact blacklist
• Improved logging
• Added m2eclipse configuration to POM
• Javadocs use API diagrams generated with Graphviz

• Many minor bugfixes, see git log for a full list