Spec URL: <http://fedorapeople.org/~dwalluck/jbossweb2.spec> SRPM URL: <http://fedorapeople.org/~dwalluck/jbossweb2-2.1.1-2.jpp5.src.rpm> Description: JBoss Web Server is an enterprise ready web server designed for medium and large applications, based on the Apache Tomcat. It is meant to be used as a replacement for the standard Web servers on all major platforms. JBoss Web Server provides organizations with a single deployment platform for Java Server Pages (JSP) and Java Servlet technologies, Microsoft .NET, PHP, and CGI. It uses a genuine high performance hybrid technology that incorporates the best of the most recent OS technologies for processing high volume data, while keeping all the reference Java specifications. It supports both in and out of the process execution of CGI and PHP scripts, as well as .NET applications. The hybrid technology model offers the best from threading and event processing models, and that makes the JBoss Web Server one of the fastest and most scalable web servers in the market.
I'll take this one.
There are a few BuildRequires in this package that doesn't exist in Fedora, here's what I'm seeing in a mock build: No Package Found for javamail_1_3_1_api No Package Found for wsdl4j16 No Package Found for jbossas >= 0:4.2.0
We really need to get the geronimo API's into Fedora. Alternatively, we could update existing Fedora packages with these provides. For now, I will simply change javamail_1_3_1_api to javamail. I will change wsdl4j16 to wsdl4j (1.5.2). Then, jbossweb just needs to be able to build against this version as we don't require wsdl4j at runtime. The jbossas dependency can be removed. The jboss logging sources are bundled along with jbossweb. There is a question as to whether these should be removed and we should be them as an external dependency first.
Spec URL: <http://fedorapeople.org/~dwalluck/jbossweb2.spec> SRPM URL: <http://fedorapeople.org/~dwalluck/jbossweb2-2.1.1-4.1.fc10.src.rpm>
I still can't build with the new srpm in mock with rawhide, I'm getting: [javac] 182. ERROR in /builddir/build/BUILD/jbossweb2-2.1.1/java/org/apache/catalina/ant/jmx/JMXAccessorTask.java (at line 42) [javac] import javax.management.remote.JMXConnector; [javac] ^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.management.remote cannot be resolved [javac] ---------- [javac] 183. ERROR in /builddir/build/BUILD/jbossweb2-2.1.1/java/org/apache/catalina/ant/jmx/JMXAccessorTask [javac] .java (at line 43) [javac] import javax.management.remote.JMXConnectorFactory; [javac] ^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.management.remote cannot be resolved [javac] ---------- [javac] 184. ERROR in /builddir/build/BUILD/jbossweb2-2.1.1/java/org/apache/catalina/ant/jmx/JMXAccessorTask.java (at line 44) [javac] import javax.management.remote.JMXServiceURL; [javac] ^^^^^^^^^^^^^^^^^^^^^^^ [javac] The import javax.management.remote cannot be resolved .... and a few others. Does it needs a BR on mx4j or some other package?
I built the RPM in rawhide x86_64. What JDK is being used? tomcat6 doesn't have a requirement on mx4j, so I suspect it might be a JDK5 vs. JDK6 issue.
I was trying to build it in rawhide i386. Looking at root.log, here are some of the packages installed: DEBUG util.py:250: java-1.5.0-gcj-devel i386 1.5.0.0-22.fc10 fedora 46 k DEBUG util.py:250: java-1.5.0-gcj i386 1.5.0.0-22.fc10 fedora 132 k DEBUG util.py:250: java-1.6.0-openjdk i386 1:1.6.0.0-2b12.fc10 fedora 29 M the java-devel is the 1.5.0 gcj one, so it's the JDK5 vs. JDK6 then? Was yours built with JDK 6?
I tried a rawhide x86_64 build and it builds successfully, and from root.log, these packages installed: DEBUG util.py:250: java-1.5.0-gcj-devel x86_64 1.5.0.0-22.fc10 fedora 46 k DEBUG util.py:250: java-1.6.0-openjdk-devel i386 1:1.6.0.0-2b12.fc10 fedora 12 M DEBUG util.py:250: java-1.5.0-gcj x86_64 1.5.0.0-22.fc10 fedora 132 k DEBUG util.py:250: java-1.6.0-openjdk i386 1:1.6.0.0-2b12.fc10 fedora 29 M I wonder if openjdk-devel get installed on this buildroot randomly. I tried another i386 build, and it still fails as mentioned above.
Why is it only pulled in on x86_64 when it should be the default on i386 also? Is there really something that requires that explicitly or does it have something to do with comps.xml (or who can we ask)? The larger problem is that we will have to force this so that other archs work as well. There's no consistency in the build roots, so we are always forced to change from JPackage to require JDK6. Since we don't have a better solution right now, I will make the JDK change and upload again.
I'm not sure it's only pulled in on x64_64 because of some explicit Requires: or it has to do with comps.xml. I'm not sure who we can ask either.
Spec URL: <http://fedorapeople.org/~dwalluck/jbossweb2.spec> SRPM URL: <http://fedorapeople.org/~dwalluck/jbossweb2-2.1.1-4.2.fc10.src.rpm>
Naming - OK Legal - OK Licensing - OK - LGPLv3 No inclusion of pre-built binaries or libraries - OK, removed in %prep verify any sources and patches : * Should the TOMCAT_CFG file be set to /etc/jbossweb/jbossweb2.conf instead of /etc/jbossweb/jbossweb.conf in jbossweb2-2.1-tool-wrapper.script? verify that the license stated in the spec file matches the actual license of the software - OK skim the summary and description for typos and oddities - OK make sure that the correct build root is used - OK ensure that macro usage is consistent - OK * rpmlint output: [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.src.rpm jbossweb2.src:86: E: hardcoded-library-path in /lib/lsb/init-functions jbossweb2.src:87: E: hardcoded-library-path in /lib/lsb/init-functions jbossweb2.src:145: W: unversioned-explicit-provides jsp21 jbossweb2.src:173: W: unversioned-explicit-provides servlet6 jbossweb2.src:174: W: unversioned-explicit-provides servlet25 jbossweb2.src: W: non-standard-group Networking/Daemons [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.noarch.rpm jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/temp jbossweb jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/temp 0775 jbossweb2.noarch: E: non-standard-gid /var/lib/jbossweb2/webapps jbossweb jbossweb2.noarch: E: non-standard-dir-perm /var/lib/jbossweb2/webapps 0775 jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/webapps /var/lib/jbossweb2/webapps jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/conf /etc/jbossweb2 jbossweb2.noarch: W: dangling-symlink /usr/share/jbossweb2/lib /usr/share/java/jbossweb2 jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/lib /usr/share/java/jbossweb2 jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/work jbossweb jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/work 0775 jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/work /var/cache/jbossweb2/work jbossweb2.noarch: E: non-standard-gid /etc/jbossweb2/tomcat-users.xml jbossweb jbossweb2.noarch: E: non-readable /etc/jbossweb2/tomcat-users.xml 0660 jbossweb2.noarch: E: non-standard-gid /var/log/jbossweb2 jbossweb jbossweb2.noarch: E: non-standard-dir-perm /var/log/jbossweb2 0775 jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/temp /var/cache/jbossweb2/temp jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/logs /var/log/jbossweb2 jbossweb2.noarch: E: non-standard-gid /etc/jbossweb2/Catalina/localhost jbossweb jbossweb2.noarch: E: non-standard-dir-perm /etc/jbossweb2/Catalina/localhost 0775 jbossweb2.noarch: W: non-standard-group Networking/Daemons jbossweb2.noarch: W: dangerous-command-in-%preun rm jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} [pcheung@tonka result]$ rpmlint jbossweb2-admin-webapps-2.1.1-4.2.fc10.noarch.rpm jbossweb2-admin-webapps.noarch: W: no-documentation jbossweb2-admin-webapps.noarch: W: non-standard-group System Environment/Applications [pcheung@tonka result]$ rpmlint jbossweb2-docs-webapp-2.1.1-4.2.fc10.noarch.rpm jbossweb2-docs-webapp.noarch: W: no-documentation jbossweb2-docs-webapp.noarch: W: non-standard-group System Environment/Applications [pcheung@tonka result]$ rpmlint jbossweb2-javadoc-2.1.1-4.2.fc10.noarch.rpm [pcheung@tonka result]$ rpmlint jbossweb2-jsp-2.1-api-2.1.1-4.2.fc10.noarch.rpm jbossweb2-jsp-2.1-api.noarch: W: no-documentation jbossweb2-jsp-2.1-api.noarch: W: non-standard-group Internet/WWW/Dynamic Content [pcheung@tonka result]$ rpmlint jbossweb2-lib-2.1.1-4.2.fc10.noarch.rpm jbossweb2-lib.noarch: W: no-documentation jbossweb2-lib.noarch: W: dangling-relative-symlink /usr/share/java/jbossweb2/jbossweb2-servlet-2.5-api-2.1.1.jar ../jbossweb2-servlet-2.5-api-2.1.1.jar jbossweb2-lib.noarch: W: dangling-relative-symlink /usr/share/java/jbossweb2/jbossweb2-jsp-2.1-api-2.1.1.jar ../jbossweb2-jsp-2.1-api-2.1.1.jar jbossweb2-lib.noarch: W: non-standard-group Development/Compilers jbossweb2-lib.noarch: W: dangerous-command-in-%preun rm [pcheung@tonka result]$ rpmlint jbossweb2-servlet-2.5-api-2.1.1-4.2.fc10.noarch.rpm jbossweb2-servlet-2.5-api.noarch: W: no-documentation jbossweb2-servlet-2.5-api.noarch: W: non-standard-group Internet/WWW/Dynamic Content [pcheung@tonka result]$ rpmlint jbossweb2-webapps-2.1.1-4.2.fc10.noarch.rpm jbossweb2-webapps.noarch: W: no-documentation jbossweb2-webapps.noarch: W: non-standard-group System Environment/Applications Changelog - OK Tags - OK Requires - OK BuildRequires - OK Summary & description - OK Encoding - OK Documentation - OK Initscripts * Following https://fedoraproject.org/wiki/Packaging/SysVInitScript, this needs the following : # This is for /sbin/service Requires(preun): initscripts and also a # description line following right after chkconfig: line Why does the init script use the lsb/init-functions instead of the regular one? File and Directory ownership - OK Users and Groups: * Should the shell for jbossweb /sbin/nologin? Web Applications - OK * Should the default TOMCAT_USER be jbossweb2(instead of tomcat) in /etc/jbossweb/jbossweb2.2.1.init? No Files or Directories under /srv - OK All patches should have an upstream bug link or comment: * Please add comments for the patches The BuildRequires and Requires section in the Java packaging guidelines have the following: At a minimum, Java packages MUST: BuildRequires: java-devel [>= specific_version] BuildRequires: jpackage-utils Requires: java >= specific_version Requires: jpackage-utils For historical reasons, when specifying versions 1.6.0 or greater, an epoch of 1 must be included. Example: Requires: java >= 1:1.6.0 Please update the BR and R to the above format.
I fixed TOMCAT_CFG (which was wrong in both scripts) and TOMCAT_USER. The initscript is an LSB initscript (for cross-distro compatibility). I don't know that LSB is against Fedora policy in any way. LSB does not require chkconfig or service, but I added the description line just in case. I added comments to the Patch lines in the spec. There are no corresponding upstream bugs. I used java-1.6.0 and java-1.6.0-devel which has the same effect but avoids the epoch mess mentioned. The JDK is also set to /usr/lib/jvm/java-1.6.0, but I wonder if this won't work if java-devel is not installed, and it's not required. Does setting it to /usr/lib/jvm/jre-1.6.0 in /etc/sysconfig/jbossweb2 work as expected?
Spec URL: <http://fedorapeople.org/~dwalluck/jbossweb2.spec> SRPM URL: <http://fedorapeople.org/~dwalluck/jbossweb2-2.1.1-7.1.fc10.src.rpm>
Here are my justifications for rpmlint warnings. If it's the same warning/error I don't list it twice. [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.src.rpm jbossweb2.src:86: E: hardcoded-library-path in /lib/lsb/init-functions jbossweb2.src:87: E: hardcoded-library-path in /lib/lsb/init-functions This file is in /lib on both i386 and x86_64. jbossweb2.src:145: W: unversioned-explicit-provides jsp21 jbossweb2.src:173: W: unversioned-explicit-provides servlet6 jbossweb2.src:174: W: unversioned-explicit-provides servlet25 The versions are in the names. jbossweb2.src: W: non-standard-group Networking/Daemons Fedora allows any Group tag. [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.noarch.rpm jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/temp jbossweb jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/temp 0775 jbossweb2.noarch: E: non-standard-gid /var/lib/jbossweb2/webapps jbossweb jbossweb2.noarch: E: non-standard-dir-perm /var/lib/jbossweb2/webapps 0775 This is correct since it's a daemon, if we agree on the perms. jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/webapps /var/lib/jbossweb2/webapps jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/conf /etc/jbossweb2 jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/lib /usr/share/java/jbossweb2 jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/work /var/cache/jbossweb2/work jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/temp /var/cache/jbossweb2/temp jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/logs /var/log/jbossweb2 I am not sure how to fix these, or what the actual problem is. jbossweb2.noarch: E: non-readable /etc/jbossweb2/tomcat-users.xml 0660 This file contains passwords, so it should not be world readable. jbossweb2.noarch: W: dangerous-command-in-%preun rm # clean tempdir and workdir on removal or upgrade /bin/rm -rf /var/cache/jbossweb2/work/* /var/cache/jbossweb2/temp/* This allows the rpm to be removed cleanly, but it's not typical to do this. What do you think? jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} This uses a variable in case the name of the script is changed, but since NAME is NAME="$(basename $0)", it is fine. [pcheung@tonka result]$ rpmlint jbossweb2-admin-webapps-2.1.1-4.2.fc10.noarch.rpm jbossweb2-admin-webapps.noarch: W: no-documentation Documentation is in the main package. [pcheung@tonka result]$ rpmlint jbossweb2-lib-2.1.1-4.2.fc10.noarch.rpm jbossweb2-lib.noarch: W: dangling-relative-symlink /usr/share/java/jbossweb2/jbossweb2-servlet-2.5-api-2.1.1.jar ../jbossweb2-servlet-2.5-api-2.1.1.jar jbossweb2-lib.noarch: W: dangling-relative-symlink /usr/share/java/jbossweb2/jbossweb2-jsp-2.1-api-2.1.1.jar ../jbossweb2-jsp-2.1-api-2.1.1.jar This is because the links are actually in another package, but jbossweb2-lib Requires that package, so it's fine. jbossweb2-lib.noarch: W: dangerous-command-in-%preun rm if [ "$1" = "0" ]; then /bin/rm -f /usr/share/java/jbossweb2/\[commons-collections-tomcat5\].jar \ /usr/share/java/jbossweb2/\[commons-dbcp-tomcat5\].jar \ /usr/share/java/jbossweb2/\[commons-pool-tomcat5\].jar \ /usr/share/java/jbossweb2/\[ecj\].jar >/dev/null 2>&1 fi This is to clean dangling symlinks. Is it valid?
(In reply to comment #15) > Here are my justifications for rpmlint warnings. If it's the same warning/error > I don't list it twice. > > [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.src.rpm > jbossweb2.src:86: E: hardcoded-library-path in /lib/lsb/init-functions > jbossweb2.src:87: E: hardcoded-library-path in /lib/lsb/init-functions > > This file is in /lib on both i386 and x86_64. > > jbossweb2.src:145: W: unversioned-explicit-provides jsp21 > jbossweb2.src:173: W: unversioned-explicit-provides servlet6 > jbossweb2.src:174: W: unversioned-explicit-provides servlet25 > > The versions are in the names. > > jbossweb2.src: W: non-standard-group Networking/Daemons > > Fedora allows any Group tag. > > [pcheung@tonka result]$ rpmlint jbossweb2-2.1.1-4.2.fc10.noarch.rpm > jbossweb2.noarch: E: non-standard-gid /var/cache/jbossweb2/temp jbossweb > jbossweb2.noarch: E: non-standard-dir-perm /var/cache/jbossweb2/temp 0775 > jbossweb2.noarch: E: non-standard-gid /var/lib/jbossweb2/webapps jbossweb > jbossweb2.noarch: E: non-standard-dir-perm /var/lib/jbossweb2/webapps 0775 > > This is correct since it's a daemon, if we agree on the perms. Should the perm be 0755? > > jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/webapps > /var/lib/jbossweb2/webapps > jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/conf > /etc/jbossweb2 > jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/lib > /usr/share/java/jbossweb2 > jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/work > /var/cache/jbossweb2/work > jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/temp > /var/cache/jbossweb2/temp > jbossweb2.noarch: W: symlink-should-be-relative /usr/share/jbossweb2/logs > /var/log/jbossweb2 > > I am not sure how to fix these, or what the actual problem is. > These seems to be ok. > jbossweb2.noarch: E: non-readable /etc/jbossweb2/tomcat-users.xml 0660 > > This file contains passwords, so it should not be world readable. > > jbossweb2.noarch: W: dangerous-command-in-%preun rm > > # clean tempdir and workdir on removal or upgrade > /bin/rm -rf /var/cache/jbossweb2/work/* /var/cache/jbossweb2/temp/* > > This allows the rpm to be removed cleanly, but it's not typical to do this. > What do you think? Hmm... ff the content of these directories are not cleaned, do they just sit there and the rpm can't be removed? > > jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} > jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} > jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} > jbossweb2.noarch: W: incoherent-subsys /etc/init.d/jbossweb2 ${NAME} > > This uses a variable in case the name of the script is changed, but since NAME > is NAME="$(basename $0)", it is fine. > > [pcheung@tonka result]$ rpmlint > jbossweb2-admin-webapps-2.1.1-4.2.fc10.noarch.rpm > jbossweb2-admin-webapps.noarch: W: no-documentation > > Documentation is in the main package. > > [pcheung@tonka result]$ rpmlint jbossweb2-lib-2.1.1-4.2.fc10.noarch.rpm > jbossweb2-lib.noarch: W: dangling-relative-symlink > /usr/share/java/jbossweb2/jbossweb2-servlet-2.5-api-2.1.1.jar > ../jbossweb2-servlet-2.5-api-2.1.1.jar > jbossweb2-lib.noarch: W: dangling-relative-symlink > /usr/share/java/jbossweb2/jbossweb2-jsp-2.1-api-2.1.1.jar > ../jbossweb2-jsp-2.1-api-2.1.1.jar > > This is because the links are actually in another package, but jbossweb2-lib > Requires that package, so it's fine. > > jbossweb2-lib.noarch: W: dangerous-command-in-%preun rm > > if [ "$1" = "0" ]; then > /bin/rm -f /usr/share/java/jbossweb2/\[commons-collections-tomcat5\].jar \ > /usr/share/java/jbossweb2/\[commons-dbcp-tomcat5\].jar \ > /usr/share/java/jbossweb2/\[commons-pool-tomcat5\].jar \ > /usr/share/java/jbossweb2/\[ecj\].jar >/dev/null 2>&1 > fi > > This is to clean dangling symlinks. Is it valid? Do they need to be removed explicitly? don't they get removed automatically during rpm -e? One thing that's still there is the shell for jbossweb is /bin/sh instead of /sbin/nologin.
Blocking against FE-Legal on advice from Red Hat Legal counsel. I'll get more information after the holiday break.
So, the key problem that Red Hat Legal identified was with the licensing on the JSON code (java/org/apache/tomcat/util/json/JSON*): /* Copyright (c) 2002 JSON.org Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The Software shall be used for Good, not Evil. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ The sentence "The Software shall be used for Good, not Evil." makes it non-free, as it is impossible for us to abide by that use-case restriction. We hit this once before with a different package, and tried to contact the copyright holder, but he was unwilling to alter the line (changing "shall" to "should" would suffice to make it a suggestion rather than a legal requirement). Either this code needs to be removed (from both the source and the binary RPM) or JSON.org needs to relicense it without that sentence. In addition to that, the license tag is incorrect on the package, there is no LGPLv3 code in this package that I could see, all of it is either Apache 2.0, LGPLv2+ or the non-free license I mentioned above. Remember that the presense of LICENSING/COPYING does not signal license versioning in the case of GPL/LGPL. Ignoring the "Evil" license, the License tag should be: License: LGPLv2+ and ASL 2.0
I came across this problem with the JSON license before. There is an Apache licensed source zip available from http://www.json.org/java/apache.zip. I'm not sure how it came about, it's not referenced on the main page, I came across it in an Apache mailing list - http://www.nabble.com/JSON-License-td5252908.html.
Is this Apache-licensed zip acceptable? We have another package that has yet to be submitted for review because it needs this json library.
Sure. That zip is ASL 2.0, which is fine. Since JSON seems to be useful for multiple projects, would it make sense to package it separately?
(In reply to comment #21) > Sure. That zip is ASL 2.0, which is fine. Awesome! > Since JSON seems to be useful for multiple projects, would it make sense to > package it separately? Yes.
So, the logical followup is that someone should make a JSON package, get it reviewed, then have this package pull out its local copy and depend on the JSON package. This will also prevent odd things like having eclipse bits depend on a JBoss Web Server. ;) It should be a trivial package, feel free to poke me when it is ready for review.
You are completely correct.
(In reply to comment #24) > You are completely correct. Is any progress being made on a JSON package for Fedora (and fixing jbossweb2 to use that JSON package)?
(In reply to comment #25) > (In reply to comment #24) > > You are completely correct. > > Is any progress being made on a JSON package for Fedora (and fixing jbossweb2 > to use that JSON package)? I know nothing about jbossweb2 but I figure I can bite the bullet and make a JSON package. After EclipseCon (week after next) I'll have time to do it.
Any progress on the JSON package? Moreover: will this package provide jboss-common-jdbc-wrapper.jar? (the spec and SRPMs are not available anymore)
The JSON package is done (although I may have forgotten to build it ... will check). I don't know about the JBoss JAR.
I did build it: http://koji.fedoraproject.org/koji/taskinfo?taskID=1304544
Great, let's move with this review forwards then:) I'd appreciate somebody (probably the reporter;) to make a scratch build again so that I can find out whether jbossweb2 will provide jboss-common-jdbc-wrapper.jar which I need to update mysql-connector-java from a years-old-and-nothing-providing version to current. Thanks in advance.
...just forgot: Andrew, would you mind building and releasing json as an update for F9/10/11? It will enable doing the same with jbossweb2 later on, thanks.
(In reply to comment #31) > ...just forgot: Andrew, would you mind building and releasing json as an update > for F9/10/11? It will enable doing the same with jbossweb2 later on, thanks. How would you like to be a co-maintainer? Then you can do it and help out when I suck at maintaining :)
Heh...ok ;) Request done in pkgdb.
Ping...where does it stuck?
The latest findbugs needs mysql-connector-java 5.1.7 or later (supposedly; I'm looking at a potential way to dodge that bullet), which needs this work done first (see comment 30). Is there anything I can do to help move this forward?
I'm going to lift FE-Legal here, on the assumption that this package will use the ASL 2.0 JSON package.
Is this package still worked on? David, Permaine?
I'm closing the bug because of no activity in a long period. Please reopen or open a new one when this package is ready for review again.