java-devel June 2014

java-devel@lists.fedoraproject.org

17 participants
17 discussions

How to fix "error: File not found: ... /usr/share/maven-fragments/%{name}"
by Michal Srb 10 Jun '14

10 Jun '14

Hello, A lot of packages in Rawhide failed to build with error like this: error: File not found: /builddir/build/BUILDROOT/bouncycastle-1.50-3.fc21.noarch/usr/share/maven-fragments/bouncycastle The reason why the packages fail is that new XMvn and javapackages-tools no longer produce old fragments/depmaps. How to fix it? Spec files of affected packages probably call %add_maven_depmap (most common case) and contain lines similar to these in "files" section: %files %{_javadir}/bcprov.jar %{_mavenpomdir}/JPP-bcprov.pom %{_mavendepmapfragdir}/%{name} %doc LICENSE Calls to %add_maven_depmap create ".mfiles" file in current working directory. ".mfiles" is a text file which contains list of files given to %add_maven_depmap (typically POM and JAR file) and it may also contain file(s) generated by macro itself. So the "files" section in spec file can look like this: %files -f .mfiles %doc LICENSE It simplifies the spec file a bit and it also fixes the problem with "File not found". Please let me know if you have any questions or if you need help with migration of your package to .mfiles. Michal

2 1

xmvn-install and activemq
by Sam Kottler 09 Jun '14

09 Jun '14

Hi! I'm fixing an issue with ftbfs for activemq against F21 and fixed the initial problem (a build-requires name change), but now am hitting an issue with xmvn-install. I assume this is the result of more specific validation with xmvn 2.0. Does anyone have a pointer on how to fix this? https://kojipkgs.fedoraproject.org/work/tasks/3791/7023791/build.log Thanks for your help! -s

2 1

Packaging of Eclipse Orbit "wrappers"
by Gerard Ryan 08 Jun '14

08 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm working on packaging eclipse-webtools to replace the existing eclipse-wtp-* (update nightmare) packages, and would like to solicit some advice/opinion! Currently, eclipse-wtp-webservices package[0] does this horrible thing where it has Source entries for these awful wrapper bundles from Eclipse Orbit, for axis and apache-commons-discovery. Originally the package didn't do this, but then it was discovered that it needs to or stuff breaks[1], because these wrappers bundle the axis & apache-commons-discovery jars, and copy them to resources folder of some web project types at project creation. I think the way this is currently being done in eclipse-wtp-webservices is not the place where this should happen, but I'm not sure where is. I've got a couple of ideas, but not sure which should be done, if any: 1. Have subpackages of axis/commons-discovery for these wrappers to put them in their own locations in Eclipse dropins directory? 2. Have a different package, something like "eclipse-orbit-wrappers" that has packages for each of these, and processes them into locations in Eclipse dropins directory? Does anyone have an opinion or better solution for this? [0] https://apps.fedoraproject.org/packages/eclipse-wtp-webservices/sources/spe… [1] https://bugzilla.redhat.com/show_bug.cgi?id=872806 Thanks, Gerard. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTlJWhAAoJEG7cfkpivEoV6xcP/1filOro/GFlYDDPketcgwPG MYyUOoQ2Li95isVrqqmn1AgCaLzXoNdGykBxSwy1tjguKiT0RFeO5lXlTaOPXmnG /lLRAbdyxIoYQ9gSch9v18UlZHNYVxO4ZXjZBPRfKlz/SR179eipdr4w1Ox/+5+E 8YH3KGTpHLrL79d7RK8OnoMc6K9N/mmS1rTOr7eJCgCwCdJjPw0TlibocNzcQQzu E3bK9PStoal2N/4/jAhMRtQdAkh+jh3g0w1Lpko14bBTO4zmoidC4dZztYECaf63 Rtp2/3baEZSM+uj/4ROA58bS2hl2FVmzeUbdOW6KJMa13/JuJoiuMetYtLlpac/9 SoWZ4UvmzNTPvCF3oGffBE/JNgZqL+dxDZc/t0MLpaXkUNq8Oop4dg7sdX+QoziD ggTkEs+Wplegq8rUHwnJNdVLRAZ4gPSqG6yAXmJIjX7S3VGannTCvm7hzDeZvaZC FJ0KTURkK3XA5jepzfFAD91jYfeHCey1c8ktsYeXOxCyIz9onkLjTBQ5y7Lhul7I WunfF9Pb4sB4GG3y73p8ygeydpSMFSq+EkwKCqARv7cQyVF623fdE6WmHr/+bWyp rtGBQoWzCo85eDAI0EDFGmxd4d4Ta6Zs1rzS+n8X5l0jHyHKDL2gaMPE7rl4g8iI 3a9ejiDUP2HA9wW01sUM =MuYP -----END PGP SIGNATURE-----

1 0

JNI packaging guidelines for optional native sub-package
by Christopher 06 Jun '14

06 Jun '14

Hello all, I'm working on packaging a jar which includes a java-only implementation, and optionally loads [System.load()] if configured to do so and the shared library is available. The actual (arch-dependent) shared library is provided in a separate sub-package (because it's optional). This means that technically, the jar can be noarch. Therefore, it makes much more sense to use the System.loadLibrary() call rather than enforce arch-dependent paths. The JNI packaging guidelines seem to written with the assumption that the package which includes the JNI jar also includes the .so, but that's not the case here, since the .so is optional and provided in a separate arch-dependent sub-package. What is the right packaging procedure here? I'm inclined to think that using System.loadLibrary() is appropriate in these circumstances, and that the jar should be placed in the normal %{_javadir}/%{name} rather than the %{_jnidir} area, since it's technically noarch, and the JNI features are optional. -- Christopher L Tubbs II http://gravatar.com/ctubbsii

1 1

XMvn 2.0.1 release notes
by Mikolaj Izdebski 06 Jun '14

06 Jun '14

What's new in XMvn 2.0.1 XMvn 2.0.1 was released on 2014-06-06. Most important changes include: * 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>>>).

1 0

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

java help properly packaging LightZone
by Matthew Miller 01 Jun '14

01 Jun '14

Hi! I'm really kind of java-clueless, and I'd like to package up LightZone, a unique and powerful open source photography application. I made a package that _works_, but it throws everything in one directory and I'm quite sure that's not how we are supposed to be packaging things, but I'm also not quite sure how to detangle which parts are arch-specific. A _lot_ of the arch-specific stuff seems to be bundled libraries, and I'm not sure how to separate that while also actually linking the java things against the system libraries. Would anyone like to help me with this? Ideally, would anyone like to help, and then, also, be a comaintainer of the package once we get it into Fedora proper? My first cut is in a Copr here: http://copr.fedoraproject.org/coprs/mattdm/LightZone/ (from src.rpm at http://mattdm.org/misc/fedora/LightZone-4.1.0-0.2.beta9.git39223bf.src.rpm) -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org> "Tepid change for the somewhat better!"

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel June 2014