java-devel November 2013

java-devel@lists.fedoraproject.org

18 participants
19 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

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

Error: No Package found for mvn(org.apache.ivy:ivy) in F20
by gil 23 Nov '13

23 Nov '13

hi any ideas? Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6215826 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6215838 regards gil

2 1

Re: [fedora-java] eclipse-m2e-core build issues
by Roland Grunberg 21 Nov '13

21 Nov '13

> Wonderful, thanks a lot Roland, I look forward to the fix! :) The build appears to be in rawhide, and I've made a bodhi update as well. Cheers, -- Roland Grunberg

1 0

eclipse-m2e-core build issues
by Gerard Ryan 21 Nov '13

21 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi guys, I'm trying to look into some of the bugs in eclipse-m2e-core, but I'm running into problems building. The latest commit/build (1.4.0-7) which is on Rawhide/F21 and previously built fine, is now failing to build[1]. The cause is a not-so-helpful: org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException Before I go any further down a potentially incorrect rabbithole, are there any problems with maven or tycho right now (or anything else), that this looks like it could be a symptom of? Has anyone seen this before, or does it look obvious to anyone at a glance? [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6206831 Any help greatly appreciated as always, Gerard. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSjTPrAAoJEG7cfkpivEoV8KQP/3rpAqofwu/NDGMSXZnzLw3L pj0eWzFH3ZO05avyiith36jkr+XphsPzTqpF9zgm9uf8JiPn26Dzgp6I2cP45xAU 1cfEygbWQxpKkbY74fOIuYNnBunjp+XGILHzJW1Lga/3eqylYrZF5Ttid1ibYd2T Y3hy3+8oCbiXYBVYCU7wTSxhtwnqqsHHP9REyNQTF3LPdLe9IfsLl0TgwCn72IxL Q07RRoKun0GtLSs4SOIpLSKllBgtwVaDKXZkWN+JcfZJY4mq8HcGJbMihtEJXPIF Mq94KARAfjYTFT7sg94cAPyRAMSEbNeredb7DnQeI3Z3GKMZAfhfvx6Mxve0qIYf Ne+GXWTf9vc+9o660CIwC22z7rZambebIo8dtsXErHYlpx1/XiY8G4AVQa/vFT8Y nw4U6sfPl/2OvdYY++go/04pKK+DS4X4awcvQr5PIOTxd07TFiKQtp8IVtAWTFp4 gykmPf5DAnfBZy7y1k4VjKOL2P1c+dRAk/58HWu4/MbH8LASHAYe3ONbmLt/oN+G BijtzkPxqMVSV9wXB0h1W6KXbnGXq1UM20T83+a3dpUa76PbLgBfr2ByVwNi9WO6 bCkz7sP1UzvpvXMxtt1WvA2+pXjQOMCwPhqqt2Eb2mvyyT5dLWTPZenz4IQbE2s0 qFmB1ULWKbI7KCcXxUI8 =6q1H -----END PGP SIGNATURE-----

2 2

Re: [fedora-java] FindBugs 2.0.2 update coming to F19/F20
by Richard Fearn 19 Nov '13

19 Nov '13

Sending again, this time including java-devel. >> there is only a problem in your spec file >> mkdir -p $RPM_BUILD_ROOT%{_javadocdir} >> cp -a apiJavaDoc $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} >> ln -s %{name}-%{version} $RPM_BUILD_ROOT%{_javadocdir}/%{name} >> must be >> cp -a apiJavaDoc $RPM_BUILD_ROOT%{_javadocdir}/%{name} >> see https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installation > > Thanks! There are a few other cleanups I'd like to do in the FindBugs > packages (as well as adding the POMs), but I wanted to get the new > version out there, because it's long overdue, and eclipse-findbugs > stopped working a while ago. I'll come back to the versioned Javadoc > dir in the next few days. -- Richard Fearn richardfearn(a)gmail.com

1 0

Eclipse crashes on F20 with Google Talk plugin
by Mattias Eriksson 18 Nov '13

18 Nov '13

I don't know if this is the correct place, but the wiki ( https://fedoraproject.org/wiki/Eclipse ) pointed me here. I just wanted to inform you that it seems that the google-talkplugin makes eclipse totally unusable. It will crash everytime it loads webkit (which is about every 5 seconds for a normal eclipse developer, if I'm a good measurement). I was forced to spend a few hours of debugging (replacing system java, system eclipse aso) before I found this: http://eclipseandlinux.blogspot.se/2013/10/google-talk-plugin-presence-brea… and also https://bugs.eclipse.org/bugs/show_bug.cgi?id=334466 https://bugs.webkit.org/show_bug.cgi?id=100622 I realize that the real problem here is to handle this in webkit, and not crash if plugins are bad. Or to just make google-talkplugin behave nicely. But it also seems weird that eclipse craches because some bad web browser plugin, I suggest to make eclipse use webkit without plugins support. Something like: webview.getSettings().setPluginsEnabled(false); I think they did this with shotwell, to avoid a simmilar flash related crash: http://redmine.yorba.org/issues/2183 I think this is a quite serious crash, since many people depend on eclipse to work and quite a lot of them may have google-talkplugin installed. And I can also tell you that it is not the easiest problem to track down, since it is not the most obvious connection. I hope this helps. //Snaggen

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel November 2013