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, 9 months
JavaFX
by Rahul Sundaram
Hi
What is the status of JavaFX? Is it under a suitable license? Will it
be included in Fedora? Thanks
Rahul
10 years, 6 months
XMvn 0.5.0 release notes
by Mikolaj Izdebski
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
10 years, 6 months
[Announce] Thermostat Test Day
by Severin Gehwolf
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/
10 years, 6 months
maven-local is missing in f17?
by Patrick Huang
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
10 years, 6 months
JAX-WS web service
by Chen, Wei D
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
10 years, 6 months
Eclipse Kepler M7 builds
by Orion Poplawski
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
10 years, 6 months
Shipping of binaries in jar files
by Orion Poplawski
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
10 years, 7 months
[Eclipse] Odd problem with updating eclipse-wtp-jeetools
by Gerard Ryan
-----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-----
10 years, 7 months