Why no Class-Path manifest attribute?
by Florian Weimer
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:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
--
Florian Weimer / Red Hat Product Security Team
9 years, 4 months
Packaging tomcat shell scripts
by Robert Rati
I logged a bz (https://bugzilla.redhat.com/show_bug.cgi?id=990588) to
request that the tomcat shell scripts (catalina.sh and the rest) be
packaged. I've had some discussions with the person the bz is assigned
to and few others, but no one knows why the scripts were not packaged.
Nor, it seems, does anyone see a problem with them being packaged as far
as I can tell.
Does anyone know some history here?
Rob
9 years, 4 months
Heads-up: Upcoming netty major version update in Rawhide (Will Break Stuff)
by Jon VanAlten
Hi Java folks,
The current netty in Fedora is 3.6.3. There are newer updates to 3.X series
upstream but also for some time now 4.X series has been available. In the
spirit of keeping the most up to date version in our distro, I aim/plan to
update this in rawhide in the coming weeks. However, there have been some
changes upstream that any maintainers of packages which depend on netty will
need to be aware of. Those packages are:
async-http-client
bookkeeper
eclipse-m2e-core
hadoop
hornetq
littleproxy
resteasy
thermostat
zookeeper
In addition, we currently have a compat netty31 package, which is used only
by the eucalyptus package. I'd also like to encourage the maintainer of
eucalyptus to look into porting to the newer netty, so this longstanding
compat package can be retired. (Well, there are other packages that
"repoquery --whatrequires netty31" returns, but inspection of .spec shows
that they only Require: netty without a version; only eucalyptus has an
explicit requirement for netty31.)
So, what are the implications of this update? Well, upstream netty has
moved from being a jboss project to being independent at netty.io, and has
changed their package namespace accordingly. In addition, some key API
classes have slightly changed names. Finally, and I haven't looked deep at
this part yet, but it seems there are some other incompatible API changes.
Any package currently using netty will *at least* require a search-and-
replace for package/class name changes, and may require more indepth fixes
in order to work with the most recent upstream releases.
The bulk of the changes came with the 4.0 release, and conveniently enough
upstream made a single commit updating most of their example code at once[1]
which is likely to be a good reference for anyone porting an application.
I'll be starting on this work around mid-November. My plan is to first
create package of the newest netty release at the time but not push to
rawhide just yet, rather make srpm available to interested maintainers via
other means. Then, as co-maintainer of thermostat, I will help to port that
package to the new netty API. I hope around this same time maintainers of
other packages will do same. To me, this will act as "sanity check" for the
updated netty package, and if this check is successful, I'll then push the
netty changes to rawhide. If all goes well, this should be done by the end
of November (modulo a week or so).
Please, if you have any concerns with this plan, speak up! Otherwise, wait
for my email in a few weeks with .srpm to play with :)
cheers,
jon
P.S. I *really* hope that at the end of all this we are not left with *two*
compat packages for netty, ie I hope that either eucalyptus is able to port
or that all of the others are able to port, or even better both of the
above.
[1] https://github.com/netty/netty/commit/8237afff64509520865c08bf4f5fd130e06...
9 years, 5 months
Re: [fedora-java] Problem changing symlink to directory with %pretrans scriptlet
by Richard Fearn
Hi Bruno,
On 28 December 2013 16:43, Bruno Wolff III <bruno(a)wolff.to> wrote:
> https://fedoraproject.org/wiki/Packaging:Guidelines#The_.25pretrans_scrip...
> Notes that you need to use lua in pretrans scriptlets, not shell commands.
Thanks. I've already seen that. It doesn't seem to make any difference
whether it's a bash scriptlet or a lua scriptlet, though; irrespective
of what language is used to delete the symlink, the problem still
occurs.
> I haven't found an example for you to copy, but note there are still some
> cases where changing symlinks to directories or vise versa won't work with
> rpm (https://bugzilla.redhat.com/show_bug.cgi?id=975909).
I think deleting the symlink manually may be revealing a problem in
rpm. It seems to treat /usr/share/javadoc/test-1/hello (from the old
package) and /usr/share/javadoc/test/hello (from the new package) as
the same thing. Since the new package is installing
/usr/share/javadoc/test/hello, it therefore decides to 'skip' the old
'hello' file, rather than 'erase' it.
I'm not sure yet why these two paths are considered to be the same...
Rich
--
Richard Fearn
richardfearn(a)gmail.com
9 years, 5 months
FindBugs 2.0.2 update coming to F19/F20
by Richard Fearn
Hi all,
This is just a quick heads-up to let you know that I am updating
FindBugs to 2.0.2 in F19 and F20.
A few dependencies have also been updated:
* jFormatString has been updated, but only FindBugs depends on it.
* findbugs-bcel has been updated to a snapshot of the BCEL trunk.
* jsr-305 has been updated by a couple of Subversion revisions. I
don't believe the changes will have any effect on dependent packages.
Excluding packages that depend on jsr-305, packages that I think could
be affected are:
* gradle
* truezip
TrueZIP looks like it just has a build-time dependency on FindBugs
(the code uses FindBugs annotations). Given that FindBugs 2.0 is
advertised as "a drop-in replacement" for 1.3.9, I don't anticipate
any problems.
As for Gradle: I know this has been retired
(https://lists.fedoraproject.org/pipermail/devel/2013-November/191944.html),
but is still in F19. I might try to figure out if Gradle is broken by
the FindBugs update, but I'm wondering if it's worth the effort. Does
anyone have any opinion?
I've just submitted the F20 update
(https://admin.fedoraproject.org/updates/FEDORA-2013-20079) for
stable. Assuming there are no objections/problems, I'd like to submit
the F19 update (https://admin.fedoraproject.org/updates/FEDORA-2013-20181)
in the next couple of days.
Regards,
Rich
--
Richard Fearn
richardfearn(a)gmail.com
9 years, 5 months
Orphaning Eucalyptus Packages
by Matt Spaulding
Hello,
I am no longer working for Eucalyptus and am orphaning all related packages.
apache-ivy
axiom
axis2
eucalyptus
groovy
ha-jdbc
hamcrest12
jbosscache-core
jbosscache-support
jdbm
jgroups212
mule
neethi
netty31
stax-utils
woden
xmlbeans
xstream
Regards,
Matt
9 years, 5 months
XMvn 1.4.0 release notes
by Mikolaj Izdebski
What's new in XMvn 1.4.0
XMvn 1.4.0 was released on 2013-12-09. Most important changes
include:
* Minor features
* Limited support for absolute JPP artifact files
Artifact files specified as absolute paths pointing to arbitrary
locations are now allowed. They are implemented as symbolic
links which are pointing to the primary artifact file, which
must be explicitly specified as non-absolute file.
Appropriate suffixes are added depending on artifact version,
classifier and extension. As absolute symlinks can be placed at
any location, configured repositories are not taken into account
and flat repository layout is always assumed.
Absolute symlinks are only created for artifact files and
attached artifacts, but not for POM files. Absolute files for
artifacts with no files (i.e. POM artifacts) are silently
ignored.
* Minor bugfixes
* Fix NullPointerException bug in installer code
* Allow file installation in root directory
XMvn was unable to install files in root directory because of
false assumption that every directory has a parent. This was
fixed in version 1.4.0.
9 years, 5 months
New shaded artifacts in objectweb-asm3
by Michal Srb
Hi guys,
I would like to share a quick tip on how to solve class loading
conflicts when both asm3 and asm4 libraries are on class path. Upstream
projects usually solve this problem by bundling shaded versions of
asm3/asm4, but due to "no bundled libraries" rule this trick cannot be
used in Fedora.
Our objectweb-asm3 package now provides shaded versions of all artifacts
in this package (in addition to original ones). Only difference between
original artifacts and our shaded artifacts is that all classes have
been relocated from "org.objetweb.asm" to
"org.objectweb.distroshaded.asm" package. gId:aId of these shaded
artifacts is the same as gId:aId of their original counterparts, but
they have classifier "distroshaded".
So if upstream of your package bundles asm3 and unbundled version causes
problems somewhere, then you can simply change the "org.objectweb.asm.*"
imports in .java files and add proper deps/requires on shaded asm3
artifacts (e.g.: "asm:asm-all::distroshaded:").
Regards
Michal
9 years, 6 months
