XMvn 2.0.0 release notes
by Mikolaj Izdebski
What's new in XMvn 2.0.0
XMvn 2.0.0 was released on 2014-05-29. Most important changes
include:
* 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.maven>>>.
* 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.
9 years, 10 months
Update to XMvn 2.0.0 and Javapackages 4.0.0
by Mikolaj Izdebski
Upstreams are planning to release XMvn 2.0.0 and Javapackages 4.0.0 on
29 May. I am going to push them to rawhide as soon as they are released.
Some of more important changes which could affect some Java packages:
The notion of "depmap" is removed. %_mavendepmapdir and
%_mavendepmapfragdir macros are deprecated and scheduled for removal in
future. %add_maven_depmap is considered as obsolete and despite its name
it doesn't create depmaps any longer, but a new kind of metadata.
%mvn_build no longer creates depmaps either, but it will continue to use
them for artifact resolution during transition period (for at least one
Fedora release; after that depmap support may be removed completely).
Full release notes will be available at release time.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
9 years, 11 months
POM packages rebuild
by Mikolaj Izdebski
I'm going to rebuild 40 packages in rawhide to regenerate mvn
auto-requires on POM packages. It's important to do that before the
mass rebuild in order to avoid unnecessary failures later.
13 of these packages which I don't own or comaintain are listed below.
directory-project
fasterxml-oss-parent
jamon-java-parent
jamon-parent
jbossws-parent
lucene
lucene3
mybatis-parent
opensaml-java-parent
portals-pom
truecommons-parent
uima-parent-pom
znerd-oss-parent
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
9 years, 11 months
Intent to orphan pdfbox
by Orion Poplawski
Due to lack of time and interest, I'm going to orphan pdfbox. The most
recent version 1.8.5 introduces some new dependencies and I don't have
the time to fix that up. The current users of pdfbox seem to be:
jabref-2.9.2-2.fc20.src.rpm
solr-4.7.2-1.fc21.src.rpm
tika-1.4-5.fc21.src.rpm
So hopefully one or more of those maintainers will be willing to take it on.
Thanks,
Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
9 years, 11 months
Hadoop + log4j2 = fullstop
by Robert Rati
I've been working on updating the hadoop package to the latest 2.4.0
release and at this point I've resolved all the issues but I'm now
blocked by the log4j2 update. log4j2 breaks the hadoop build pretty
severely, and it doesn't seem the log4j2 team has spent much time
thinking about how to provide backwards compatibility to existing
log4j1.2 users. From my investigation of log4j2:
log4j.properties file is no longer read at all
configuration file is now in XML or JSON
configuration file name is log4j2.[xml|json|jsn]
V2 isn't backwards compatible with V1. There's a shim for v1 api but it
will only work for a limited set of cases, and for some cases it does
work for it turns some operations into noop calls.
This is a pretty major change and even the compatibility layer, if it
will work for a project, does not seem to guarantee like functionality
and minimally will require a re-do of all log4j configuration files a
project ships. I'm not sure many sizable upstream projects would
undertake/accept such a drastic change very quickly.
The list of projects currently blocked by this update are:
hadoop
hbase
oozie
hive
apache-log4j-extras
amplab-tachyon
I would be surprised if there aren't a lot more. I understand Fedora is
always pushing for the latest versions, but for some fundamental
packages can there be compatibility packages introduced at the same time
as an incompatible update? Package maintainers of dependent packages
will still need to touch their packages and determine if the new version
will work for them. Providing a compat package will also allow packages
to update to their newer versions while not held up on trying to
integrate changes from a compatibility breaking dependency update.
Rob
9 years, 11 months
junit4 virtual provides were dropped
by Mikolaj Izdebski
junit4 virtual provides were recently removed. Reason: junit4 was
renamed to junit over 2 years ago, so it was time to drop legacy provides.
The following provides were dropped from junit:
* junit4
* junit4-demo
* junit4-javadoc
* junit4-manual
Additionally, the following provide was dropped from maven-surefire:
* maven-surefire-provider-junit4
Any remaining dependencies on junit4 should be replaced with their junit
counterparts.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
9 years, 11 months
Self Introduction: Christopher Tubbs
by Christopher
Hi,
My name is Christopher Tubbs. I'm a long-time user of Fedora and
Linux, and a big fan of free (as in speech) software. I love bigdata
and scientific computing, and consider myself a seasoned Java
developer and Maven user.
I'm currently working on Apache Accumulo as my first package for
Fedora (https://fedoraproject.org/wiki/Changes/ApacheAccumulo). I'm
also an upstream developer for Accumulo project, which helps, because
there's a lot of patches I need to make to get it to build with the
dependency versions available in Fedora.
I'm not yet in the package maintainers group, but my FAS account is
ctubbsii and I'm seeking a mentor (preferably one familiar with the
Hadoop ecosystem and Java packaging) to help me get all the kinks
worked out of my package. I'm still very new to the whole packaging
environment in Fedora, and trying to get a handle on understanding all
the infrastructure at Fedora needed to get things done. I definitely
need a mentor to help me understand the packaging process and tools in
the Fedora infrastructure (cgit, bugzilla, koji, etc.).
My draft packaging is not yet done, but in progress here:
https://github.com/ctubbsii/accumulo-fedora (temporary)
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
9 years, 11 months
Retiring animal-sniffer and mojo-signatures
by Mikolaj Izdebski
I am going to retire animal-sniffer and mojo-signatures, unless someone
wants to maintain them. Reason: Not useful in Fedora - we don't care
about older JDKs.
Currently only infinispan requires them, but that's easy to patch out (I
can take care of that).
Name : animal-sniffer
Version : 1.9
Release : 6.fc21
Architecture: noarch
Size : 416933
Packager : Fedora Project
Group : Unspecified
URL : http://mojo.codehaus.org/animal-sniffer/
License : MIT and ASL 2.0
Repository : rawhide
Summary : Tools to assist verifying backward compatibility of Java
classes
Source : animal-sniffer-1.9-6.fc21.src.rpm
Description :
Tools to assist verifying that classes compiled with a newer JDK/API
are compatible with an older JDK/API
Name : mojo-signatures
Version : 1.1
Release : 0.11.svn11457.fc19
Architecture: noarch
Size : 1332214
Packager : Fedora Project
Group : Development/Libraries
URL : http://mojo.codehaus.org/
License : MIT
Repository : rawhide
Summary : Mojo API signatures project
Source : mojo-signatures-1.1-0.11.svn11457.fc19.src.rpm
Description :
The API Signatures project contains a number of projects which
generate signatures of various APIs, such as the Java Runtime. These
signatures are generated by and consumed by the Animal Sniffer
project.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
9 years, 11 months