java-devel December 2013

java-devel@lists.fedoraproject.org

8 participants
10 discussions

Apache TomEE rpms
by David Blevins 12 Feb '16

12 Feb '16

Hello Fedora/Java people, First post to the list, so hello! We've crafted up some RPMs for Apache TomEE and are looking to contribute them to Fedora if at all possible. * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-jaxrs-1.5.2-1.noarc… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-webprofile-1.5.2-1.… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-plus-1.5.2-1.noarch… I haven't much of an idea on what the process for this might be. Dan Allen (RedHat) pointed us this way. Hoping someone here might have insight, even if that is some other list. -David

5 5

Why no Class-Path manifest attribute?
by Florian Weimer 06 Feb '14

06 Feb '14

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

10 23

Packaging tomcat shell scripts
by Robert Rati 16 Jan '14

16 Jan '14

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

5 22

Heads-up: Upcoming netty major version update in Rawhide (Will Break Stuff)
by Jon VanAlten 02 Jan '14

02 Jan '14

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/8237afff64509520865c08bf4f5fd130e06ae…

5 11

Re: [fedora-java] Problem changing symlink to directory with %pretrans scriptlet
by Richard Fearn 28 Dec '13

28 Dec '13

Hi Bruno, On 28 December 2013 16:43, Bruno Wolff III <bruno(a)wolff.to> wrote: > https://fedoraproject.org/wiki/Packaging:Guidelines#The_.25pretrans_scriptl… > 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

1 1

FindBugs 2.0.2 update coming to F19/F20
by Richard Fearn 28 Dec '13

28 Dec '13

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

2 4

Orphaning Eucalyptus Packages
by Matt Spaulding 14 Dec '13

14 Dec '13

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

3 3

Failed eclipse-findbugs noarch build due to use of %{_libdir}
by Richard Fearn 14 Dec '13

14 Dec '13

Hi, I tried to build eclipse-findbugs (a noarch package) in rawhide yesterday but the build failed: http://koji.fedoraproject.org/koji/buildinfo?buildID=483577 Here's the spec file: http://pkgs.fedoraproject.org/cgit/eclipse-findbugs.git/tree/eclipse-findbu… The spec file passes a few locations to ant based on %{eclipse_base}, which is defined like this: %global eclipse_base %{_libdir}/eclipse I guess I've been lucky up to now because eclipse-findbugs has always built on a 32-bit builder. Yesterday it built on a 64-bit builder where %{_libdir} is /usr/lib, but Eclipse is installed under /usr/lib64. I found a few tickets discussing this: https://bugzilla.redhat.com/show_bug.cgi?id=808983 https://bugzilla.redhat.com/show_bug.cgi?id=847130 https://fedorahosted.org/fpc/ticket/203 which imply %{eclipse_base} shouldn't be used. What's the correct way to build this plugin? Thanks, Richard -- Richard Fearn richardfearn(a)gmail.com

3 3

XMvn 1.4.0 release notes
by Mikolaj Izdebski 09 Dec '13

09 Dec '13

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.

1 0

New shaded artifacts in objectweb-asm3
by Michal Srb 06 Dec '13

06 Dec '13

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

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel December 2013