Bug 740814 - Review Request: jena - Java framework for building Semantic Web Applications
Summary: Review Request: jena - Java framework for building Semantic Web Applications
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Roland Grunberg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-23 13:08 UTC by Tomas Radej
Modified: 2015-02-23 14:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-18 14:32:49 UTC
rgrunber: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Tomas Radej 2011-09-23 13:08:21 UTC
Spec URL: http://tradej.fedorapeople.org/jena-2.6.4-1/jena-2.6.4-1.fc15.src.rpm
SRPM URL: http://tradej.fedorapeople.org/jena-2.6.4-1/jena.spec

Description: Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine.

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3372238

Comment 1 Roland Grunberg 2011-09-30 17:33:58 UTC
Package Review
==============

Key:
- = N/A
x = Check
! = Problem
? = Not evaluated

=== REQUIRED ITEMS ===
[X]  Rpmlint output:
jena.spec:24: W: mixed-use-of-spaces-and-tabs (spaces: line 24, tab: line 1)
jena.spec: W: patch-not-applied Patch1: %{name}-test-fail.patch
jena.spec: W: invalid-url Source0: jena-2.6.4.tar.xz
0 packages and 1 specfiles checked; 0 errors, 3 warnings.

[X]  Package is named according to the Package Naming Guidelines[1].
[X]  Spec file name must match the base package name, in the format %{name}.spec.
[!]  Package meets the Packaging Guidelines[2].
[X]  Package successfully compiles and builds into binary rpms.
[X]  Buildroot definition is not present
[X]  Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines[3,4].
[X]  License field in the package spec file matches the actual license.
License type:
[X]  If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc.
[-]  All independent sub-packages have license of their own
[X]  Spec file is legible and written in American English.
[X]  Sources used to build the package matches the upstream source, as provided in the spec URL.
[X]  All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines[5].
[X]  Package must own all directories that it creates.
[X]  Package requires other packages for directories it uses.
[!]  Package does not contain duplicates in %files.
[X]  File sections do not contain %defattr(-,root,root,-) unless changed with good reason
[X]  Permissions on files are set properly.
[X]  Package does NOT have a %clean section which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). (not needed anymore)
[X]  Package consistently uses macros (no %{buildroot} and $RPM_BUILD_ROOT mixing)
[X]  Package contains code, or permissable content.
[-]  Fully versioned dependency in subpackages, if present.
[-]  Package contains a properly installed %{name}.desktop file if it is a GUI application.
[X]  Package does not own files or directories owned by other packages.
[X]  Javadoc documentation files are generated and included in -javadoc subpackage
[X]  Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlinks)
[X]  Packages have proper BuildRequires/Requires on jpackage-utils
[X]  Javadoc subpackages have Require: jpackage-utils
[-]  Package uses %global not %define
[X]  If package uses tarball from VCS include comment how to re-create that tarball (svn export URL, git clone URL, ...)
[!]  If source tarball includes bundled jar/class files these need to be removed prior to building
[X]  All filenames in rpm packages must be valid UTF-8.
[X]  Jar files are installed to %{_javadir}/%{name}.jar (see [6] for details)
[X]  If package contains pom.xml files install it (including depmaps) even when building with ant
[X]  pom files has correct add_maven_depmap

=== Maven ===
[X]  Use %{_mavenpomdir} macro for placing pom files instead of %{_datadir}/maven2/poms
[-]  If package uses "-Dmaven.test.skip=true" explain why it was needed in a comment
[-]  If package uses custom depmap "-Dmaven.local.depmap.file=*" explain why it's needed in a comment
[X]  Package DOES NOT use %update_maven_depmap in %post/%postun
[X]  Packages DOES NOT have Requires(post) and Requires(postun) on jpackage-utils for %update_maven_depmap macro

=== Other suggestions ===
[!]  If possible use upstream build method (maven/ant/javac)
[X]  Avoid having BuildRequires on exact NVR unless necessary
[X]  Package has BuildArch: noarch (if possible)
[X]  Latest version is packaged.
[!]  Reviewer should test that the package builds in mock.
Tested on: fedora-rawhide-i36 for mock and fedora-15-i386 for maven build.

=== Issues ===
1. [!]  Package does not contain duplicates in %files.
The copyright.txt file could be included in just the main package itself and not the javadoc subpackage also.

2. [!]  If source tarball includes bundled jar/class files these need to be removed prior to building
There are some jar files in tools-lib that are not removed.

3. [!]  Package successfully compiles and builds into binary rpms.
When doing a local mock/mvn build I get the following test failure :

ERROR [main] (RDFDefaultErrorHandler.java:40) - http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd(line 39 column 14): {E213} Unexpected end of file from server
Tests run: 9501, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 177.971 sec <<< FAILURE!

This isn't the same test as the one for Patch1. I guess as long as it builds in koji it should be fine, but was unsure why this was failing.

Comment 2 Tomas Radej 2011-10-04 14:19:32 UTC
Thank you for reviewing this one.

Ad Issues: 
1. Since the javadoc subpackage is not dependent on the base package, it must contain the license file.

2. Removed when creating the source package.

3. I don't get that error, but now I get a different one (maybe it was caused by another package being updated). I skipped the tests entirely and intend to work on it once it's in rawhide - I need this package for maven-doap-plugin.

Spec URL: http://tradej.fedorapeople.org/jena-2.6.4-2/jena.spec
SRPM URL: http://tradej.fedorapeople.org/jena-2.6.4-2/jena-2.6.4-2.fc17.src.rpm

Koji build (rawhide): http://koji.fedoraproject.org/koji/taskinfo?taskID=3401982
Koji build (f16): http://koji.fedoraproject.org/koji/taskinfo?taskID=3401984

Comment 3 Roland Grunberg 2011-10-04 15:45:59 UTC
I was thinking that since the javadoc subpackage is derived from the sources, it would qualify as an implicit dependency. Everything else looks fine. Setting as approved.

= REQUIRED ITEMS =
[X]  Package meets the Packaging Guidelines[2].
[X]  Package does not contain duplicates in %files.
[X]  If source tarball includes bundled jar/class files these need to be removed prior to building

=== Maven ===
[X]  If package uses "-Dmaven.test.skip=true" explain why it was needed in a comment

=== Other suggestions ===
[X]  If possible use upstream build method (maven/ant/javac)
[X]  Reviewer should test that the package builds in mock.
Tested on: fedora-rawhide-i386 for mock and fedora-15-i386 for maven build.

Comment 4 Tomas Radej 2011-10-05 08:02:06 UTC
Yeah, I used to interpret that as well, but I was told that implicit dependency means a transitive Require.

Thank you very much for review.

Comment 5 Tomas Radej 2011-10-05 08:06:06 UTC
New Package SCM Request
=======================
Package Name: jena
Short Description: Java framework for building Semantic Web applications
Owners: tradej
Branches: f16
InitialCC: java-sig

Comment 6 Gwyn Ciesla 2011-10-14 13:46:23 UTC
Subject is Jena, SCM request is jena, please make them match so I know which
you want.  Thanks!

Comment 7 Tomas Radej 2011-10-14 14:01:23 UTC
It's jena. Thanks.

Comment 8 Gwyn Ciesla 2011-10-14 16:10:36 UTC
Git done (by process-git-requests).

Comment 9 Don Pellegrino 2015-01-09 21:35:53 UTC
I am unable to find a package for Apache Jena by searching for "jena" in the Fedora Package List (https://apps.fedoraproject.org/packages/s/jena). I do not see it in the list of Deprecated Packages (http://fedoraproject.org/wiki/Deprecated_packages). This bug report was closed in 2011 and marked as NEXTRELEASE, so I expected to find the package in the distribution. What is the status of this package?

Comment 10 Alexander Kurtakov 2015-01-09 21:41:07 UTC
The maintainer retired it as he lost interest in it. If you want to revive it please open a new review request.

Comment 11 Don Pellegrino 2015-01-13 20:03:09 UTC
It seems that the links to the .spec file are dead. Is the .spec still available or will I need to start from scratch on that?

Comment 12 Alexander Kurtakov 2015-01-13 20:08:04 UTC
(In reply to Donald Pellegrino from comment #11)
> It seems that the links to the .spec file are dead. Is the .spec still
> available or will I need to start from scratch on that?

http://pkgs.fedoraproject.org/cgit/jena.git/tree/?id=9dde28df36a25f12dfc45b5c2b67e14bbdd84923 seems to be the latest sources

Comment 13 Don Pellegrino 2015-02-23 14:03:44 UTC
I made an attempt at updating the .spec file for the latest release of Apache Jena. The new .spec is attached to the review request at bug#1193730. I am willing to maintain this package however this is my first package and I need to be sponsored into the packager group.


Note You need to log in before you can comment on or make changes to this bug.