java-devel February 2014

java-devel@lists.fedoraproject.org

14 participants
8 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

Javadoc packages
by Mikolaj Izdebski 22 Mar '14

22 Mar '14

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

8 8

Replacement for JCEECDHKeyAgreement
by David Juran 06 Mar '14

06 Mar '14

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/JCEECDHK…) 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/ael… -- David Juran Sr. Consultant Red Hat +46-725-345801

3 11

eclipse 4.3.2 plans?
by Orion Poplawski 01 Mar '14

01 Mar '14

Any schedule for an update to eclipse 4.3.2? Thanks, Orion -- 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 1

Question about servlet apis tomcat/jboss
by Orion Poplawski 21 Feb '14

21 Feb '14

I maintain olfs which has been compiling fine against tomcat-servlet-3.0-api. Latest version however fails. Apparently upstream uses servlet 2.5. I see we have a jboss-servlet-2.5-api package now, and it compiles fine against that. What would be the implications switching to that? Does it then need to be run in jboss, or could it still be used in tomcat? Sorry, I don't know much about this area.... -- 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 1

Maven update in rawhide
by Mikolaj Izdebski 21 Feb '14

21 Feb '14

I've just updated Maven in rawhide to next upstream version -- 3.2.1. Please let me know if you encounter any issues. -- Mikolaj Izdebski IRC: mizdebsk

2 3

maven-wagon split
by Mikolaj Izdebski 20 Feb '14

20 Feb '14

Package maven-wagon has been split into multiple subpackages in rawhide. Wagon has several modules, which have different dependencies and are not strongly connected with other. Splitting maven-wagon package was aimed at optimizing dependencies. For now maven-wagon has requires on all subpackages, so packages can still require maven-wagon main package for now, but it is highly recommended to migrate them to require one or more of wagon subpackages to reduce the number of unneeded dependencies. In future all packages will have to require modules they use. Packages that use mvn(*)-style requires and build-requires will immediately benefit from the split, without any change to them. Packages which currently require or build-require maven-wagon and therefore are possibly affected by this change: aether aether-connector-okhttp antlr-maven-plugin apache-commons-jci apache-rat eclipse-m2e-core maven maven2 maven-eclipse-plugin maven-idea-plugin maven-indexer maven-javadoc-plugin maven-jxr maven-plugin-bundle maven-project-info-reports-plugin maven-remote-resources-plugin maven-repository-builder maven-shared-io maven-site-plugin maven-wagon-ahc mercury shrinkwrap-resolver -- Mikolaj Izdebski IRC: mizdebsk

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel February 2014