java-devel May 2013

java-devel@lists.fedoraproject.org

18 participants
9 discussions

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

JavaFX
by Rahul Sundaram 25 May '13

25 May '13

Hi What is the status of JavaFX? Is it under a suitable license? Will it be included in Fedora? Thanks Rahul

2 1

XMvn 0.5.0 release notes
by Mikolaj Izdebski 24 May '13

24 May '13

What's new in XMvn 0.5.0 * Major features * XMvn Subst Version 0.5.0 brings a new tool - XMvn Subst. This tool is able to replace individual artifact files with symbolic links to corresponding files in system artifact repository. It is also able to recursively process whole directories. * XMvn Bisect Since version 0.5.0 a new tool - XMvn Bisect - is available. This tool helps automating debugging build failures using bisection method. It first builds project using dependencies coming from system repository only, next only from remote repositories, then halves dependency set recursively until it finds differences which are causing build failure. * Minor features * Basic support for dependency version ranges In previous versions XMvn did not support dependency version ranges. If range was used in POM then Maven would try to resolve all available versions from remote repository and pick the best match. Starting from XMvn 0.5.0 any dependency version ranges without recommended version specified are replaced with version <<<SYSTEM>>>, which means default artifact version in the system. This prevents Maven from trying to use remote repositories. * Improved configuration loading Starting from version 0.5.0 configuration is read only once at the beginning of the build. In previous versions configuration was read every time it was needed. The new approach is not only faster, but also allows configuration to be modified by plugins during runtime. * Better handling of inaccurate configuration In previous versions any packaging rules that didn't match any artifact in the reactor were silently ignored. Since version 0.5.0 any non-optional packaging rule that is not used causes the build to fail. * Minor bugfixes * Incorrect path to JPP artifacts Paths to JPP artifacts containing more than one slash in groupId were generated incorrectly. This could cause dependency resolution failures in some rare cases. This bug was fixed in version 0.5.0. * Fixed exit code of XMvn Resolve Now <<<xmvn-resolve>>> returns 0 when it successfully resolves all artifacts, 1 on failure to resolve one or more artifacts and 2 when some other error occurs. In the last case a stack trace is printed too. * Fixed installation of artifact marked as not installable Before version 0.5.0 XMvn tried to find installers for all artifacts in the reactor, even for those marked as not installable. As a result reactors that contained artifacts with unsupported packaging types failed to build, even if instalation of these artifacts was explicitly skipped. This bug was fixed in XMvn 0.5.0, in which artifact packaging type has to be supported only if the artifact is installable. -- Mikolaj Izdebski IRC: mizdebsk

3 4

[Announce] Thermostat Test Day
by Severin Gehwolf 22 May '13

22 May '13

Hi, I'd like to invite interested Java developers, system admins and other interested parties to our Thermostat Test Day. The test day is tomorrow, May 23, 2013[1]. Thermostat[2] is an extensible open source serviceability and monitoring tool for OpenJDK. The tool gives you an inside perspective of what's going on in the JVM and on the host the JVM is running on. Ever wanted to create a heap dump? Interested in which threads are mostly idle in your application? Thermostat is the tool you are looking for! If you've never heard about Thermostat before, this is your opportunity to try it out and familiarize yourself with this new and exciting tool. We are going to be around all day tomorrow to assist you trying out Thermostat. You can get a hold of us on IRC in #fedora-test-day or #thermostat (both on freenode). We'd be particularly interested what first-time users find confusing about the tool. So don't be shy! Just follow the instructions described in the "Planned Tests" section. What's more, we're here to help. Thanks and happy testing! Cheers, Severin [1] https://fedoraproject.org/wiki/Test_Day:2013-05-23_Thermostat [2] http://icedtea.classpath.org/thermostat/

1 0

maven-local is missing in f17?
by Patrick Huang 19 May '13

19 May '13

Hi, Starting from last Friday 17 May, when I build anything targeting f17 will get this error: DEBUG util.py:264: Error: No Package found for maven-local This includes previously successful build. Has anything changed? Regards, Patrick Huang Senior Software Engineer Engineering - Internationalisation Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8278 Fax: +61 7 3514 8199 IRC: pahuang github: github.com/huangp Website: www.redhat.com

2 1

JAX-WS web service
by Chen, Wei D 13 May '13

13 May '13

Hi, Is there any project in fedora repo has a reference implementation of JSR-224? Our project need jaxws-rt.jar and streambuffer.jar to implement JAX-WS web service and deploy on tomcat6, but these binary has not been included in fedora repo. any substituted implementation which would be found from fedora repo? Best Regards, Dave Chen

4 6

Eclipse Kepler M7 builds
by Orion Poplawski 10 May '13

10 May '13

Any plans to update eclipse components in F19+ to the kepler M7 builds (which I believe were this week)? Current eclipse PTP git builds are failing for me, I suspect because of changes to the CDT. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

2 3

Shipping of binaries in jar files
by Orion Poplawski 03 May '13

03 May '13

The eclipse PTP project that I package is starting to ship an executable in one of its plugins. The executable is packed into a jar file. This prevents debuginfo creation for the executable. I started taking a look at how this might be handled elsewhere and found: /usr/lib64/eclipse/dropins/cdt/eclipse/plugins/org.eclipse.cdt.core.linux.x86_64_5.2.0.201302132326.jar: 13327 Defl:X 3624 73% 02-13-2013 23:21 326488c7 os/linux/x86_64/libpty.so 23720 Defl:X 7151 70% 02-13-2013 23:21 c26c2c94 os/linux/x86_64/libspawner.so but no debuginfo package. Thoughts, comments? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

8 13

[Eclipse] Odd problem with updating eclipse-wtp-jeetools
by Gerard Ryan 02 May '13

02 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi folks, I'm trying to update eclipse-wtp-jeetools but I'm running into a problem that's probably something obvious that I should know, but it's not coming to me: Bundle A (org.eclipse.jst.common.annotations.core) requires bundle B (org.eclipse.jem.util - from eclipse-wtp-common). Bundle A specifies in its MANIFEST.MF to 'Require-Bundle' on bundle B. Bundle B is available during the build in the '-d' parameter to the eclipse-pdebuild command. The problem arises when compilation reaches a file in bundle A that has an 'import' for a file in bundle B -- errors such as the following occur: [javac] 12. ERROR in /builddir/build/BUILD/eclipse-wtp-jeetools-3.4.0/webtools.javaee-201304111500/plugins/org.eclipse.jst.common.annotations.core/src/org/eclipse/jst/common/internal/annotations/core/Annotat ionsProviderManager.java (at line 8) [javac] import org.eclipse.jem.util.RegistryReader; [javac] ^^^^^^^^^^^^^^^ [javac] The import org.eclipse.jem cannot be resolved I've also tried adding 'Import-Package' on the specific packages from Bundle B into the MANIFEST.MF for Bundle A, but that didn't work either. Does anybody have any suggestions as to what is going wrong, or where I should be looking? I bet I'm looking in completely the wrong place. If you think it would be helpful, there's a copy of the srpm that I'm trying is at [1] (there are a lot of changes - plan is to get the update working, then tidy up the package). There's also a copy of the build.log I've been experiencing at [2]. Thanks for any advice or insights that you can provide, Gerard, [1] http://galileo.fedorapeople.org/eclipse-wtp-jeetools-3.4.0-6.fc20.src.rpm [2] http://galileo.fedorapeople.org/jeetools-build.log -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRgkKtAAoJEG7cfkpivEoV51kP/0TcjoINaUdqihsZcwQPay3Q VFpCQIBCtESmcBqWQ8qsQIb07AgesXX23/ff4T6GwNYkkgqHGzovr98vaU44oRmt J5IieUF0h5vd2IH4cxTJrgHxuyfCcJZePA326f2eJjAT/yzQwvPgpS4GxSJKJllo J2EzGFnFZJfC1AjCT9FLGMEaSEs9FC7HvSofq3UG+JFnqsLNvyx7QzfhoBH4BfhU 1qt8Zgdi0pnWMAWkGsC6xcrIEuBUVQ6+nOPh2Im9k37TejF3zW9xc4sPz9C0Egr8 Gnwm+pEKXiuzFME9ppx1nC3oqZQVqiNAfpo7XNoZxhZorhe6pJfELkkt0lY0/OV9 jfen4Lp4lmo5f1AqF5XCEJPg/4NUE4c2CQlXhAE5ft92pHrJAJ3XBPieKk4dPMIT L/8Dt8meB4hnt3aTGm8iAFJ+dA+0xsnhOx1CjuSSGnGRR9+Pf0yQt3PhFrGa3iwv g+2bseg46tfCrowhMlTRPE+UU6PSHZ+wEA3gY4VacQMP4y+aI9cOxRDFPOGCTeJP 3AsaAnHNuvHWYYseon2I5FzzzqKFadbSLoagixxspSXTTUDMrfTclI1dDTOxuzTP SZq/xYJimQtCZejLOf4R1WWgDpW5svSP61VqjdPnvyLo/XTcaJo1ehUrw3UWfVX9 CpxopDO77vp/Z9ZsF+Aa =v3iF -----END PGP SIGNATURE-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel May 2013