java-devel August 2014

java-devel@lists.fedoraproject.org

9 participants
7 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

Re: [fedora-java] Circular dependencies in BuildRequires
by Sérgio Basto 26 Aug '14

26 Aug '14

Hi, sorry I fail to send to ML in first time On Seg, 2014-08-25 at 10:32 -0400, Michael Simacek wrote: > > ----- Original Message ----- > > From: "Sérgio Basto" <sergio(a)serjux.com> > > To: "Michael Simacek" <msimacek(a)redhat.com> > > Sent: Monday, August 25, 2014 3:33:46 PM > > Subject: Re: [fedora-java] Circular dependencies in BuildRequires > > > > On Dom, 2014-08-24 at 13:18 -0400, Michael Simacek wrote: > > > ----- Original Message ----- > > > > From: "Sérgio Basto" <sergio(a)serjux.com> > > > > To: java-devel(a)lists.fedoraproject.org > > > > Sent: Sunday, August 24, 2014 6:33:36 PM > > > > Subject: [fedora-java] Circular dependencies in BuildRequires > > > > > > > > Hi, > > > > I'm trying bring eclipse 4.4 to Fedora 20 [1] > > > > > > > > eclipse need jetty , jetty needs objectweb-asm 5 , normally I do : > > > > fedpkg clone $package > > > > cd $package > > > > fedpkg switch-branch f21;fedpkg srpm ; mock -r fedora-20-x86_64 > > > > --no-clean --rebuild ./$package.fc21.src.rpm > > > > > > > > So I build objectweb-asm 5 , after that I can't almost build anything > > > > because multiple dependencies > > > > > > > > jdependency [2] needs maven-plugin-tools , hawtjni, plexus-containers > > > > that need be rebuild for new objectweb-asm > > > > > > > > hawtjni-1.10-2.fc21 [3] needs maven-plugin-tools > > > > > > > > maven-dependency-analyzer [4] needs maven-plugin-tools, hawtjni etc > > > > > > > > maven-plugin-tools can't be build because depends on maven > > > > > > > > maven depends on sisu, sisu-mojos and maven-wagon > > > > > > > > sisu depends on javapackages-tools-4.1.0 > > > > > > > > javapackages-tools have an error that BuildRequires: javapackages-tools > > > > >= 4.0.0 , impossible , but removing it depends on xmvn-resolve >= > > > > 2.0.0 > > > > > > > > repoquery --releasever=21 xmvn-resolve --source > > > > xmvn-2.0.1-1.fc21.src.rpm > > > > xmvn depends on maven >= 3.2.1-10 and sisu-mojos > > > > > > > > how we build it on a new arch or from scratch ? I try looking for > > > > bootstrap some packages have references to bootstraping but no flags > > > > on .spec > > > > > > We generally don't need to really build it from scratch. Most Java packages > > > are noarch, > > > so they already should work on the new arch. We just need to import them > > > and then > > > do proper rebuild from source when all the dependencies are satisfied. > > > > ok how I compile all in Fedora 20 ? > > I'm afraid for bootstraping from scratch you'll need some hack like: > 1. Temporarily bundle pre-built JARs for the packages instead of building them from source so > other pacakges can use them as a dependency. > 2. When all the packages in the dependency cycle are built like this, remove bundled stuff > and rebuild them properly from source, because now they can use dependencies from point 1. > > But I still don't understand why you want to do it from scratch. Why don't you > use objectweb-asm3, javapackages-tools, sisu etc. from F20? > You don't need newer versions of these, do you? I need update sisu to have sisu-mojos for compile maven-3.2.2, that requires it, and I'm stuck here btw. I can't build sisu-0.2.1 on Fedora 20 but now, it seems to me, that is a problem with %mvn_build macro rpm, because all packages that I want rebuild ends with : java.lang.RuntimeException: Failed to load XMvn configuration I'm sending sisu-0.2.1 to build in copr for us see the build error on : http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… > > > > > > > Eclipse 4.4 is already available for Fedora 20 in Mat Booth's Copr: > > > http://copr-fe.cloud.fedoraproject.org/coprs/mbooth/eclipse-luna/ > > > > I don't like the approaching and have a second eclipse , I "need" > > eclipse 4.4 as an upgrade of eclipse of the system > > > > please see status of my tries in > > http://copr.fedoraproject.org/coprs/sergiomb/eclipse_4.4/builds/ > > > > I understand that objectweb-asm only can build it after have > > objectweb-asm3 , I try bootstrap some packages . > > > > Now in a circular dependencies of sisu and xmvn , xmvn > 2 needs sisu > > > 0.2.1 > > > > > > I try compile also objectweb-asm3 , objectweb-asm3.spec have a big bug > > > > IMHO > > > > # shade-jar utility used in this spec file needs this > > > > BuildRequires: objectweb-asm3 > > > > > > > > repoquery --releasever=21 -f /usr/bin/shade-jar --source > > > > javapackages-tools-4.1.0-2.fc21.src.rpm > > > > > > > > but correctly, I think that should be: > > > > BuildRequires: /usr/bin/shade-jar > > > > > > > > but we don't have any shade-jar in Fedora 20 , can we remove shade-jar > > > > scripting from spec ? > > > > > > shade-jar script is part of javapackages-tools and it needs > > > objectweb-asm3-processor to work, > > > but javapackages-tools don't Require it (most likely to not increase > > > install size). > > > > > > > > > Michael Simacek > > > > > > > > > > > > > > > any feedback is welcome ! > > > > > > > > Thanks, > > > > > > > > [1] > > > > http://copr.fedoraproject.org/coprs/sergiomb/eclipse_4.4/builds/ > > > > > > > > [2] > > > > http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… > > > > [3] > > > > http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… > > > > [4] > > > > http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… > > > > > > > > > > > > -- > > > > Sérgio M. B. > > > > > > > > -- > > > > java-devel mailing list > > > > java-devel(a)lists.fedoraproject.org > > > > https://admin.fedoraproject.org/mailman/listinfo/java-devel > > > > -- > > Sérgio M. B. > > > > -- > > Sérgio M. B. -- Sérgio M. B.

2 5

Circular dependencies in BuildRequires
by Sérgio Basto 24 Aug '14

24 Aug '14

Hi, I'm trying bring eclipse 4.4 to Fedora 20 [1] eclipse need jetty , jetty needs objectweb-asm 5 , normally I do : fedpkg clone $package cd $package fedpkg switch-branch f21;fedpkg srpm ; mock -r fedora-20-x86_64 --no-clean --rebuild ./$package.fc21.src.rpm So I build objectweb-asm 5 , after that I can't almost build anything because multiple dependencies jdependency [2] needs maven-plugin-tools , hawtjni, plexus-containers that need be rebuild for new objectweb-asm hawtjni-1.10-2.fc21 [3] needs maven-plugin-tools maven-dependency-analyzer [4] needs maven-plugin-tools, hawtjni etc maven-plugin-tools can't be build because depends on maven maven depends on sisu, sisu-mojos and maven-wagon sisu depends on javapackages-tools-4.1.0 javapackages-tools have an error that BuildRequires: javapackages-tools >= 4.0.0 , impossible , but removing it depends on xmvn-resolve >= 2.0.0 repoquery --releasever=21 xmvn-resolve --source xmvn-2.0.1-1.fc21.src.rpm xmvn depends on maven >= 3.2.1-10 and sisu-mojos how we build it on a new arch or from scratch ? I try looking for bootstrap some packages have references to bootstraping but no flags on .spec I try compile also objectweb-asm3 , objectweb-asm3.spec have a big bug IMHO # shade-jar utility used in this spec file needs this BuildRequires: objectweb-asm3 repoquery --releasever=21 -f /usr/bin/shade-jar --source javapackages-tools-4.1.0-2.fc21.src.rpm but correctly, I think that should be: BuildRequires: /usr/bin/shade-jar but we don't have any shade-jar in Fedora 20 , can we remove shade-jar scripting from spec ? any feedback is welcome ! Thanks, [1] http://copr.fedoraproject.org/coprs/sergiomb/eclipse_4.4/builds/ [2] http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… [3] http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… [4] http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedora-… -- Sérgio M. B.

2 1

icedtea-web crash
by gil 19 Aug '14

19 Aug '14

hi when i try to use http://digiland.libero.it/chat.php icedtea-web crash [1] any ideas? thanks in advance regards gil [1] The folloing exception has occured. For more information, try to launch the browser from the command line and examine the output. For even more information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the steps described there on how to obtain necessary information to file bug Additional information may be available in the console or logs. Even more information is available if debugging is enabled. Another available info: IcedTea-Web Plugin version: 1.5 (fedora-2.fc19-i386) 16/08/14 14.16 Exception was: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button". at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908) Caused by: net.sourceforge.jnlp.LaunchException: The applet is signed but its manifest specifies Sandbox permissions. This is not yet supported. Try running the applet again, but choose the Sandbox run option. at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:206) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:288) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711) ... 2 more Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Run in Sandbox call performed too late. The classloader was notified to run the applet sandboxed, but security settings were already initialized. at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203) ... 8 more This is the list of exceptions that occurred launching your applet. Please note, those exceptions can originate from multiple applets. For a helpful bug report, be sure to run only one applet. 1) at 16/08/14 14.16 net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Run in Sandbox call performed too late. The classloader was notified to run the applet sandboxed, but security settings were already initialized. at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:288) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908) 2) at 16/08/14 14.16 net.sourceforge.jnlp.LaunchException: The applet is signed but its manifest specifies Sandbox permissions. This is not yet supported. Try running the applet again, but choose the Sandbox run option. at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:206) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:288) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Run in Sandbox call performed too late. The classloader was notified to run the applet sandboxed, but security settings were already initialized. at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203) ... 8 more 3) at 16/08/14 14.16 net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button". at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908) Caused by: net.sourceforge.jnlp.LaunchException: The applet is signed but its manifest specifies Sandbox permissions. This is not yet supported. Try running the applet again, but choose the Sandbox run option. at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:206) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:288) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711) ... 2 more Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Run in Sandbox call performed too late. The classloader was notified to run the applet sandboxed, but security settings were already initialized. at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385) at net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203) ... 8 more

3 2

Two bugs reported about fedora-review-plugin-java
by Ismael Olea 18 Aug '14

18 Aug '14

Maybe of your interest: - https://fedorahosted.org/FedoraReview/ticket/239 - https://fedorahosted.org/FedoraReview/ticket/240 -- Ismael Olea http://olea.org/diario/

2 1

Package review requests
by Ismael Olea 17 Aug '14

17 Aug '14

Hi: For updating OmegaT to 2.6.3 it's needed to add four dependencies needing review: - Review Request: snip <https://bugzilla.redhat.com/show_bug.cgi?id=1130756> - Review Request: rundoc <https://bugzilla.redhat.com/show_bug.cgi?id=1130755> - Review Request: jsap <https://bugzilla.redhat.com/show_bug.cgi?id=1127894> - Review Request: gnudiff <https://bugzilla.redhat.com/show_bug.cgi?id=1127879> I think they are near to trivial. Would be nice if some of you review someone. -- Ismael Olea http://olea.org/diario/

1 0

/usr/lib/jni support in Fedora
by Florian Weimer 04 Aug '14

04 Aug '14

As far as I can tell, currently, System.loadLibrary() is mostly unusable for Java libraries because they cannot influence the library search path. If you want to transparently load a DSO, you need to use System.load() and hard-code the path. This probably means patching upstream sources. Debian patches the default search path so that System.loadLibrary() searches /usr/lib/jni for DSOs with native code. This means that classes which call System.loadLibrary() just work, assuming that the Debian package installs its DSOs into /usr/lib/jni. Can we do something similar in Fedora? We probably want /usr/lib/jni and /usr/lib64/jni, for consistency with the rest of the system. The upstream default search path starts with "/usr/java/packages/lib/amd64" (and variants for other architectures), but this isn't mentioned in the Fedora guidelines. I'm also not sure if we want to use this file system location because it doesn't look particularly FHS-compliant. But the proprietary JDKs could install a symlink there so that /usr/lib{,64}/jni is searched as well. -- Florian Weimer / Red Hat Product Security

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel August 2014