Source strings

25 Strings
100%
Browse Translate
1,221 Words
100%
8,263 Characters
100%
This translation is being used as source strings within this component.

Strings status

Strings Words Characters
25 1,221 8,263
All strings Browse Translate Zen
25 1,221 8,263
Read-only strings Browse Translate Zen
2 164 1,082
Strings with any failing checks Browse Translate Zen
2 164 1,082
Failing check: Unpluralised Browse Translate Zen

Summary

Project website forge.fedoraproject.org
Instructions for translators

Mailing list for translators: trans@lists.fedoraproject.org
Translation license Creative Commons Attribution Share Alike 3.0 Unported
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://forge.fedoraproject.org/localization-docs/java-packaging-howto.git
Repository branch main
Last commit in Weblate Translated using Weblate (Greek) 38073721
Weblate Translation Memory authored 07/11/2026
Weblate repository https://translate.fedoraproject.org/git/fedora-docs-l10n-java-packaging-howto/masterantorayml/
File mask po/*/master/pages/dependency_handling.po
Translation file Download pot/master/pages/dependency_handling.pot
Last change April 9, 2026, 12:23 a.m.
Last change made by None
Language English
Language code en
Text direction Left to right
Case sensitivity Case-sensitive
Number of speakers 1,728,473,503
Number of plurals 2
Plural type One/other
Plurals Singular 1
Plural 0, 2, 3, 4, 5, 6, 7, 8, 9, 10, …
Plural formula n != 1
08/23/2026

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 25 1,221 8,263
Translated 100% 25 100% 1,221 100% 8,263
Needs editing 0% 0 0% 0 0% 0
Read-only 100% 25 100% 1,221 100% 8,263
Failing checks 8% 2 13% 164 13% 1,082
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 26 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes
SepOctNovDecJanFebMarAprMayJunJulAug

Quick numbers

1,221
Hosted words
25
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
—
—
Hosted strings
—
—
Translated
—
—
Contributors
—
User avatar None

Source string added
While Requires and Provides are automated for Maven projects, BuildRequires still remain a manual task. However, it can be at least a bit simplified. XMvn ships a script `xmvn-builddep` that takes a `build.log` output from mock and prints maven-style BuildRequires on artifacts that were actually used during the build. It doesn't help you to figure out what the BuildRequires are before you actually build it, but it may help you to have a minimal set of BuildRequires that are less likely to break, as they don't rely on transitive dependencies.
04/09/2026
User avatar None

Source string added
See also xref:introduction_for_developers.adoc#querying_repositories[Querying Fedora repositories]
04/09/2026
User avatar None

Source string added
For packages without POMs it's necessary to specify `Requires` tags manually. In order to build the package you needed to specify `BuildRequires` tags. You `Requires` tags will therefore likely be a subset of your `BuildRequires`, excluding build tools and test only dependencies.
04/09/2026
User avatar None

Source string added
If the package is built built using different tool than Apache Maven, but still ships Maven POM(s), the you will still get automatic provides generation if you install the POM using `%mvn_artifact` and `%mvn_install`. The requires generation will also be executed but the outcome largely depends on whether the POM contains accurate dependency insformation. If it contains dependency information, you should double check that it's correct and up-to-date. Otherwise you need to add `Requires` tags manually as described in the next section.
04/09/2026
User avatar None

Source string added
The requires generator also always generates Requires on `java-headless` and `javapackages-tools`.
04/09/2026
User avatar None

Source string added
The generated Requires are based on dependencies specified in Maven POMs in the project. Only dependencies with `scope` set to either `compile`, `runtime` or not set at all are used for Requires generation. Requires don't rely on package names and instead always use virtual provides that were described above, in exactly the same format, in order to be satisfieable by the already existing provides. For packages consisting of multiple subpackages, Requires are generated separately for each subpackage. Additionally, Requires that point to an artifact in a different subpackage of the same source package are generated with exact versions to prevent version mismatches between artifacts belonging to the same project.
04/09/2026
User avatar None

Source string added
The Java packaging tooling on Fedora provides automatic Requires and Provides generation for packages built using XMvn. The Provides are based on Maven artifact coordinates of artifacts that were installed by the currenlty being built. They are generated for each subpackage separately. They follow a general format `mvn(groupId:artifactId:extension:classifier:version)`, where the extension is omitted if it's `jar` and classifier is omitted if empty. Version is present only for compat artifacts, but the trailing colon has to be present unless it's a Jar artifact with no classifier.
04/09/2026
User avatar None

Source string added
RPM has multiple types of metadata to describe dependency relationships between packages. The two basic types are Requires and Provides. Requires denote that a package needs something to be present at runtime to work correctly and the package manager is supposed to ensure that requires are met. A single Requires item can specify a package or a virtual provide. RPM Provides are a way to express that a package provides certain capability that other packages might need. In case of Maven packages, the Provides are used to denote that a package contains certain Maven artifact. They add more flexibility to the dependency management as single package can have any number of provides, and they can be moved across different packages without breaking other packages' requires. Provides are usually generated by automatic tools based on the information from the built binaries or package source.
04/09/2026
User avatar None

Resource updated
File “pot/master/pages/dependency_handling.pot” was added. 04/09/2026
User avatar None

String added in the repository
While `Requires` and `Provides` generation is automated for Maven projects, `BuildRequires` still remains a manual task. However, there are tools to simplify it to some extent. XMvn ships a script `xmvn-builddep` that takes a `build.log` output from mock and prints Maven-style `BuildRequires` on artifacts that were actually used during the build. It does not help you to figure out what the `BuildRequires` are before you actually build it, but it may help you to have a minimal set of `BuildRequires` that are less likely to break, as they do not rely on transitive dependencies.
While `Requires` and `Provides` generation is automated for Maven projects, `BuildRequires` still remains a manual task. However, there are tools to simplify it to some extent. XMvn ships a script `xmvn-builddep` that takes a `build.log` output from mock and prints Maven-style `BuildRequires` on artifacts that were actually used during the build. It does not help you to figure out what the `BuildRequires` are before you actually build it, but it may help you to have a minimal set of `BuildRequires` that are less likely to break, as they do not rely on transitive dependencies.
04/09/2026
Browse all translation changes