[javapackages] [doc] Dependency handling of non-maven pkgs
by Michael Šimáček
commit 5164dee7fe6a140e1ad0a8a958ae8ebc9958b889
Author: Michael Simacek <msimacek(a)redhat.com>
Date: Tue Apr 14 17:06:37 2015 +0200
[doc] Dependency handling of non-maven pkgs
doc/dependency_handling.txt | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
---
diff --git a/doc/dependency_handling.txt b/doc/dependency_handling.txt
index dfe8090..e353547 100644
--- a/doc/dependency_handling.txt
+++ b/doc/dependency_handling.txt
@@ -56,6 +56,23 @@ artifacts belonging to the same project.
The requires generator also always generates Requires on `java-headless`
and `javapackages-tools`.
+.Dependency handling for non-Maven packages that ship POM files
+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.
+
+.Dependency handling for non-Maven packages that don't ship POM files
+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.
+
.Querying Requires and Provides of built packages
The generated Requires and Provides of built packages can be queried
using `rpm`:
9 years, 1 month
[javapackages] [doc] Remove add_maven_depmap section
by Michael Šimáček
commit 9444bbc4a21200e287cbc29f03a999241bb0ade4
Author: Michael Simacek <msimacek(a)redhat.com>
Date: Mon Apr 13 12:41:31 2015 +0200
[doc] Remove add_maven_depmap section
%mvn_artifact should be used instead
doc/generic_java_build.txt | 77 --------------------------------------------
1 files changed, 0 insertions(+), 77 deletions(-)
---
diff --git a/doc/generic_java_build.txt b/doc/generic_java_build.txt
index 5c29c95..517a4fd 100644
--- a/doc/generic_java_build.txt
+++ b/doc/generic_java_build.txt
@@ -3,83 +3,6 @@ Handling of basic build steps in Java
* usage of build-claspath, build-jar-repository to prepare for build
* ...
-=== add_maven_depmap macro
-
-Maven identifies JAR files by a set of strings: groupId, artifactId and version
-(mostly). To let XMvn know what groupId:artifactId corresponds to which
-POM or JAR file, we may use the `%add_maven_depmap` macro. However, if package
-is build in standard way (i.e.: `%mvn_build` and `%mvn_install`), then calling
-`%add_maven_depmap` is neither needed nor recommended. This macro is usually
-useful only for packages that use other build tool than Maven (e.g.: ant,
-gradle).
-
-For the macro to work properly, all JAR files must be copied into `%{_javadir}`
-and all POM files must be copied into `%{_mavenpomdir}`.
-
-In simplest form (a POM without a JAR file), `%add_maven_depmap` looks like
-this:
-
-.Parent POM
-[source,spec]
---------
-%add_maven_depmap %{name}.pom
---------
-
-This will read the POM file in question and provide a mapping between the
-groupId and artifactId inside the POM file and the POM file placed into
-`%{_mavenpomdir}`.
-
-For a POM that maps directly to a JAR file, the following is the correct form:
-
-.Standard invocation
-[source,spec]
---------
-%add_maven_depmap %{name}.pom %{name}.jar
---------
-
-In addition to creating the POM mapping, this will also ensure that the correct
-JAR is associated with the groupId and artifactId from the POM.
-
-Even if there is no POM file from some reason, it is still possilbe to generate
-mapping between Maven artifact and corresponding JAR file:
-
-[source,spec]
---------
-%add_maven_depmap groupId:artifactId[:extension[:classifier]]:version %{name}.jar
---------
-
-.Providing additional artifact mappings
-[source,spec]
---------
-%add_maven_depmap %{name}.pom %{name}.jar -a "org.apache.commons:commons-lang"
---------
-This form also adds additional mappings for given POM/JAR file. For example, if
-the POM file indicates that it contains groupId commons-lang, artifactId
-commons-lang, this form ensures that we also add a mapping between groupId
-org.apache.commons and the installed POM/JAR files. This is necessary in cases
-where the groupId or artifactId may have changed, and other packages might
-require different IDs than those reflected in the installed POM.
-
-.Multiple subpackages
-[source,spec]
---------
-%add_maven_depmap %{name}.pom %{name}.jar -f "XXX"
---------
-This form stores metadata information in file with suffix "XXX". This
-is useful for packages with multiple subpackages where each has its own
-JAR files.
-
-.Multiple artifacts in a subdirectory
-[source,spec]
---------
-%add_maven_depmap %{name}-sub.pom %{name}/sub.jar
---------
-
-This form should be used when a package consists of multiple JAR files that are
-installed into a subdirectory of `%{_javadir}`. Note that in this case, the POM
-file name includes the optional subdirectory field.
-
-
=== Generating Application Shell Scripts
As mentioned in section about xref:XFor_Packagers[Java packaging basics], all
Java applications need wrapper shell scripts to setup the environment before
9 years, 1 month