java-devel May 2014

java-devel@lists.fedoraproject.org

9 participants
12 discussions

Apache TomEE rpms
by David Blevins 12 Feb '16

12 Feb '16

Hello Fedora/Java people, First post to the list, so hello! We've crafted up some RPMs for Apache TomEE and are looking to contribute them to Fedora if at all possible. * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-jaxrs-1.5.2-1.noarc… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-webprofile-1.5.2-1.… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-plus-1.5.2-1.noarch… I haven't much of an idea on what the process for this might be. Dan Allen (RedHat) pointed us this way. Hoping someone here might have insight, even if that is some other list. -David

5 5

XMvn 2.0.0 release notes
by Mikolaj Izdebski 04 Jun '14

04 Jun '14

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.

3 4

Update to XMvn 2.0.0 and Javapackages 4.0.0
by Mikolaj Izdebski 29 May '14

29 May '14

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

1 2

POM packages rebuild
by Mikolaj Izdebski 29 May '14

29 May '14

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

1 1

Intent to orphan pdfbox
by Orion Poplawski 22 May '14

22 May '14

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

2 4

log4j12 (1.2.17) is available for review
by gil 22 May '14

22 May '14

https://bugzilla.redhat.com/show_bug.cgi?id=1100323 hi - gil

1 0

Hadoop + log4j2 = fullstop
by Robert Rati 22 May '14

22 May '14

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

6 9

junit4 virtual provides were dropped
by Mikolaj Izdebski 22 May '14

22 May '14

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

1 0

Self Introduction: Christopher Tubbs
by Christopher 19 May '14

19 May '14

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

1 0

Retiring animal-sniffer and mojo-signatures
by Mikolaj Izdebski 12 May '14

12 May '14

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel May 2014