How to fix "error: File not found: ... /usr/share/maven-fragments/%{name}"
by Michal Srb
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
9 years, 9 months
Packaging of Eclipse Orbit "wrappers"
by Gerard Ryan
-----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/s...
[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-----
9 years, 9 months
JNI packaging guidelines for optional native sub-package
by Christopher
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
9 years, 9 months
XMvn 2.0.1 release notes
by Mikolaj Izdebski
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>>>).
9 years, 9 months
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
java help properly packaging LightZone
by Matthew Miller
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!"
9 years, 10 months