March 2014 - java-devel - Fedora Mailing-Lists

by David Blevins

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.noa... * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-webprofile-1.5.2-... * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-plus-1.5.2-1.noar... 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

8 years, 2 months

5
5
0 / 0

Javadoc packages

by Mikolaj Izdebski

We'll have to move to Java 8 in Fedora sooner or later. I did some testing of Maven and Ant stacks regards that and most of things seem to be working well, except for javadoc. Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs. In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs. My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it. The main reasons for making javadoc optional are: 1. Java 8 problems, as explained above. 2. Storage. I took a typical set of 265 Java source packages. When all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB. 3. Build time. Javadoc generation usually takes more time than compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time. I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21. -- Mikolaj Izdebski

10 years, 1 month

8
8
0 / 0

Splitting SLF4J

by Michael Šimáček

Hello, I've split the slf4j package into subpackages. The api, simple and nop submodules were left in the main package, in order not to break many packages that depend on slf4j. Submodules that were moved into subpackages: jdk14 log4j12 jcl ext jcl-over-slf4j log4j-over-slf4j jul-to-slf4j If some of your packages require one of those, please change your BuildRequires accordingly. Most of the packages shouldn't be affected. If your package needs just api, nop or simple submodules or you use mvn() style BuildRequires, no changes should be necessary. Regards, Michael Simacek

10 years, 1 month

5
4
0 / 0

Re: [fedora-java] AArch64: We have a release

by Jiri Vanek

Hi All! I wont to add, that RPMS for fedora are built and downloadable on http://icedtea.wildebeest.org/download/fedora/ They have a bit strange name, but basically they are built on same tags as below source tarballs. Those are also pushed in fedora (rawhide) git (with sources in cache) so you can rebuild. *java-1.7.0-openjdk* http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-1.7.0.60... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-1.7.0.60... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-accessib... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-debuginf... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-demo-1.7... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-devel-1.... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-headless... http://icedtea.wildebeest.org/download/fedora/java-1.7.0-openjdk-src-1.7.... *java-1.8.0-openjdk* http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-1.8.0.0-... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-1.8.0.0-... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-accessib... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-debuginf... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-demo-1.8... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-devel-1.... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-headless... http://icedtea.wildebeest.org/download/fedora/java-1.8.0-openjdk-src-1.8.... J. On 03/12/2014 05:42 PM, Andrew Haley wrote: > We at the AArch64 Port Project are pleased to announce the first > release of OpenJDK on the Linux/AArch64 platform. It is the first > implementation of the Java platform to be made available for this > processor architecture. > > For those who haven't heard: AArch64 is the latest architecture from > ARM. It is an entirely new instruction set, not compatible with the > earlier generation of 32-bit ARM processors, so we need a new OpenJDK > port for it. > > This is a complete port, with template interpreter and client and > server JIT compilers. We have JDK8 and JDK7 versions available for > download now. It will shortly be included in Fedora for AArch64. > It is, of course, entirely free software, available under the GPL. > > Source bundles are available from > http://icedtea.wildebeest.org/download/source/aarch64-port-jdk7u60-aarch6... > http://icedtea.wildebeest.org/download/source/aarch64-port-jdk8-aarch64-9... > > We will now to make plans to integrate this port with the main OpenJDK > project. > > Credit where credit is due: > > We started this work at Red Hat almost two years ago with two Red Hat > engineers, Andrew Haley and Andrew Dinn. It became an OpenJDK project > and we were joined by Linaro, who have been extremely helpful with > testing, bug fixing, and keeping up with OpenJDK's continuous updates. > Many people have helped, but in particular I'd like to thank Edward > Nevill for his support and tireless work. > > Of course the work will go on: there is performance tuning to be done > on real hardware and we need to do a lot more real-world testing. In > particular, we haven't yet done work to optimize HotSpot for the > Advanced SIMD and Cryptography units. If you are interested in > working on this exciting project or if you just want to chat about it, > come over to aarch64-port-dev(a)openjdk.java.net . > > Andrew Haley > OpenJDK AArch64 port Project Lead >

10 years, 1 month

1
0
0 / 0

Fedora Java-SIG projects for GSoC 2014

by Lali Devamanthri

Hi, Is there any projects we can propose for this year Google Summer of Code programme. I have noticed there are no any single project idea proposed in Java for Fedora (but there are few from last year) It may be great chance to get new contributors for Java SIG. Thanks, /Lali

10 years, 1 month

3
6
0 / 0

Intent to retire maven-ant-tasks

by Orion Poplawski

I think it is well past time to have retired maven-ant-tasks. I just doesn't support maven 3 and upstream appears to be dead - no scm commits for 10 months. I'm planning on retiring by Friday unless someone else wants to flog this dead horse. # repoquery --whatrequires maven-ant-tasks leiningen-0:1.7.1-7.fc20.noarch but I don't know about BuildRequires. - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

10 years, 1 month

3
3
0 / 0

Replacement for JCEECDHKeyAgreement

by David Juran

Hello! I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement. I'm maintaining the azureus package for fedora and (quite some time ago), it's come to my attention (https://bugzilla.redhat.com/show_bug.cgi?id=820117) that azureus bundles an ancient version of BouncyCastle and relies on the JCEECDHKeyAgreement class. This class no longer exists in current BouncyCastle and all information I can find about it is a javadoc of a rather old Bouncycastle version (http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/jce/provider/JCEECD...) So now my question is, does anyone have any good leads on how to convert this too use the current BouncyCastle API? The problematic (upstreams) sources can be found in http://svn.vuze.com/public/client/branches/BRANCH_4812/azureus2/src/com/a... -- David Juran Sr. Consultant Red Hat +46-725-345801

10 years, 1 month

3
11
0 / 0

R: Lucene major update to 4.6.1

by GILBERTO CTTNEO

hi is available 4.7.0 please consider upgrading regards gil >----Messaggio originale---- >Da: msimacek(a)redhat.com >Data: 04/03/2014 17.00 >A: <java-devel(a)lists.fedoraproject.org> >Ogg: [fedora-java] Lucene major update to 4.6.1 > >Hello, > >I'm updating lucene from version 3.6.2 to 4.6.1. >This update will break some packages due to API changes. > >Affected packages: >eclipse >eclipse-m2e-core >eclipse-mylyn >h2 >hibernate-search >infinispan >maven-indexer >solr3 >thermostat > >Packages that may be affected, but FTBFS regardless of lucene version: >opengrok > >The rest of dependent packages built fine. > > > >Please try to update to the new API, it would be better if we didn't have to create >a compat package. > >Regards, >Michael Simacek >-- >java-devel mailing list >java-devel(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/java-devel

10 years, 1 month

2
1
0 / 0

Lucene major update to 4.6.1

by Michael Šimáček

Hello, I'm updating lucene from version 3.6.2 to 4.6.1. This update will break some packages due to API changes. Affected packages: eclipse eclipse-m2e-core eclipse-mylyn h2 hibernate-search infinispan maven-indexer solr3 thermostat Packages that may be affected, but FTBFS regardless of lucene version: opengrok The rest of dependent packages built fine. Please try to update to the new API, it would be better if we didn't have to create a compat package. Regards, Michael Simacek

10 years, 1 month

1
0
0 / 0

bouncycastle

by gil

hi please retire bouncycastle-tsp now bouncycastle-pkix (bcpkix) is available in rawhide remove from bouncycastle-mail bundled bcpkix source code regards gil

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel March 2014