It seems that a significant number of JAR files under /usr/share/java do
not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included
with the final link (typically, in the -classpath argument to
/usr/bin/java). This is mightily inconvenient and leaks implementation
details across Java RPM package boundaries. (I don't think
%jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
Florian Weimer / Red Hat Product Security Team
Until recently in Fedora we had 3 versions of easymock - 1, 2 and 3. We
have managed to update all dependencies to use the latest upstream
version -- 3.2.
easymock package was just upfdated from version 1.2 to version 3.2 and
easymock3 will be retired. easymock has virtual provides easymock3 for
now, but packages should migrate to require just "easymock" or "easymock
>= 3" when they are touched. Maven compat alias mvn(easymock:easymock)
is *not* provided.
Also note that there is license change from MIT to ASL 2.0.
This update affects Fedora 20 and later, previous versions are not affected.
I finally came to the conclusion, that I no longer want to invest time
and effort in keeping all my Java packages in good shape. I don't have
the time anymore to unbundle all the bundled libraries and keep a dozen
downstream patches to make it work.
freemind is close to a 1.0.0 release and I provided packages for that
already in a small side repo .
There are also some review requests for additional libraries ,.
So I will orphan the packages next week and will block them if no one
applies for taking them over.
I hope someone will take good care of them.
I just run into a problem and noticed JUnit package in fedora seems to use a snapshot version. It breaks powermock compatibility check. It's a issue in powermock itself and I've reported it http://code.google.com/p/powermock/issues/detail?id=453 But meanwhile, just wondering what's the reason behind packaging a snapshot version?
Senior Software Engineer
Engineering - Internationalisation
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Office: +61 7 3514 8278
Fax: +61 7 3514 8199
Hi, all. As some of you know, I changed jobs 3 months ago, and since
then, I have had no time to work on keeping my java packages updated
and in line with changing packaging guidelines. I'm looking for
volunteers to take over some of these packages, and thought I would
ask this list before posting to fedora-devel. The list is below.
I'll coordinate the orphaning process for each with people who
volunteer. Thanks in advance.
XmlSchema -- Lightweight schema object model
annogen -- Java framework for JSR-175 annotations
aopalliance -- Java/J2E AOP standards
apache-commons-ognl -- Object Graph Navigation Library
apache-parent -- Parent pom file for Apache projects
aspectjweaver -- Java byte-code weaving library
avalon-framework -- Java components interfaces
avalon-logkit -- Java logging toolkit
axiom -- Axis Object Model
axis2 -- Java-based Web Services / SOAP / WSDL engine
bcel -- Byte Code Engineering Library
bsf -- Bean Scripting Framework
btm -- Bitronix Transaction Manager
derby -- Relational database implemented entirely in java
ezmorph -- Object transformation library for Java
geronimo-validation -- Geronimo implementation of JSR 303
ha-jdbc -- High-availability JDBC
hamcrest12 -- Library of matchers for building test expressions
hessian -- Java implementation of a binary protocol for web services
hibernate3 -- Relational persistence and query service
htmlunit -- A headless web browser for automated testing
htmlunit-core-js -- Rhino fork for htmlunit
jakarta-commons-httpclient -- Jakarta Commons HTTPClient implements
the client side of HTTP standards
jamonapi -- A Java monitoring API
java-uuid-generator -- A pure Java UUID generator
javassist -- The Java Programming Assistant provides simple Java
jexcelapi -- A Java API to read, write and modify Excel spreadsheets
joda-convert -- Java library for conversion to and from standard string formats
jsilver -- A pure-Java implementation of Clearsilver
json-lib -- JSON library for Java
jtype -- A small library for working with the Java 5 type system
mule -- Mule Enterprise Service Bus Java libraries
neethi -- Web Services Policy framework
netty31 -- An asynchronous event-driven network application framework
and tools for Java
proxool -- Java connection pool library quartz -- Enterprise Job
Scheduler for Java
sablecc -- A parser generator written in Java saxon -- Java XSLT processor
tagsoup -- A SAX-compliant HTML parser written in Java
woden -- Web Service Description Language (WSDL) validating parser
wss4j -- Apache WS-Security implementation
xalan-j2 -- Java XSLT processor
xml-security -- Implementation of W3C security standards for XML
xom -- XML Pull Parser
Since mule is failing to build I am attempting to update it to use the new
Java guidelines. It currently uses a depmap file to find correct
dependencies. How is this done under the new guidelines? From what I've
read it appears that simply using "%mvn_build" should work, but it fails to
resolve some dependencies.
Would anyone object to me retiring the "xml-commons-apis12" package in F20?
It is a compatibility package that has been hanging around for years that
provides an earlier version of the APIs provided by the "xml-commons-apis"
All packages that need these APIs should be requiring or buildrequiring
xml-commons-apis instead. The last remaining package in F20 that used this
package was axis and I have just committed a patch for the that allows it
to build against the newer xml-commons-apis.
With no more packages in Fedora that depend on xml-commons-apis12 I would
like to retire it for F20 and later.
Is anyone looking at ways to integrate Ivy more fully into Fedora? I ask because I'm working on packaging sbt, which uses Ivy for dependency management; my current approach involves patching sbt to ignore Ivy descriptor files (so it can build with RPM-managed dependencies), but this feels suboptimal and results in some other headaches. So if you're working on Ivy in Fedora (or if you're interested in talking about sbt in Fedora), I'd like to hear from you!
 see http://chapeau.freevariable.com/2013/08/making-fedora-a-better-place-for-... for a discussion of what this involves