XMvn 2.3.0

Major features

• 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.

Minor bugfixes

• 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.

Other changes

• 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.

XMvn 2.2.1

Major bugfixes

• 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.

XMvn 2.2.0

Major features

• 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.

XMvn 2.1.1

Minor bugfixes

• 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.

XMvn 2.1.0

Minor features

• 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.

Minor bugfixes

• 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.

XMvn 2.0.1

Minor features

• 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

Minor bugfixes

• 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).

XMvn 2.0.0

Major features

• 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.

Minor features

• 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.

Other changes

• 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.

XMvn 1.4.0

Minor features

• 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.

Minor bugfixes

• 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.

XMvn 1.3.0

Major features

• 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.

Major bugfixes

• 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.

Minor bugfixes

• 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.

XMvn 1.2.0

Minor features

• 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.

Major bugfixes

• 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.