java-devel June 2011

java-devel@lists.fedoraproject.org

13 participants
11 discussions

SIG meeting - 29th June (Wednesday) 13:00 UTC - guideline changes, FTBFSs
by Stanislav Ochotnicky 30 Jun '11

30 Jun '11

We will have quite important meeting tomorrow. Main agenda is: * Change of guidelines * Use add_maven_depmap instead of add_to_maven_depmap * Stop using update_maven_depmap and Requires(post[un]):jpackage-utils in F16+ * FTBFSs Everyone interested is welcome, https://fedoraproject.org/wiki/Meeting:Java_SIG_2011-06-29 -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

1 1

Heads-up: Maven builds might be failing for some period
by Aleksandar Kurtakov 23 Jun '11

23 Jun '11

Hi everyone, Fedora is transitioning to using Maven 3 by default. Up until now it was working because a lot of things were bringing maven2 into the build system. Maven2 was part of Fedora for more ~5 years - long enough time to get a lot of crap accumulated. We are slowly fixing issues as they arrive but there will surely be a lot of pain until we get Maven 3.x properly working without maven2 being installed. Example issues can be: * failing to resolve parent poms * failing to resolve artifacts * projects depending on maven2 apis * you hit one of the few incompatibilities between maven 3.x and maven2 * other issues we are still not aware of Warning: None of the Java SIG active members has expressed any intention to work on improving maven2 anymore. So if you hit a problem with your maven build I strongly encourage you to move to maven 3 as fast as you can. Realistically, maven2 bug reports might not be even processed for rawhide because both versions depend on the very same stack and we(Java SIG) as the maintainers of most of the stack are slightly moving it to maven 3 only. We will not break maven2 intentionally but we won't stop improvements in maven 3 because of maven2. In short, if you want to keep maven2 be prepared to put a lot of effort into it!!! Help us get a sane Java stack, Alex

1 0

New
by Edwin Jose 20 Jun '11

20 Jun '11

I am new to Development in Fedora. I want to Know how can i contribute with my java knowledge. Thks in advance -- Regards *R.Edwin Jose*

3 2

JRE not recognised in eclipse IDE
by Yup Yup 14 Jun '11

14 Jun '11

Hi, I installed eclipse-platform-3.5.2-2.fc13.x86_64 on Fedora 13. Java has been installed on the system. ca1@localhost ~]$ java -version java version "1.6.0_18" ...... But, Java runtime is not recognised in the Eclipse IDE. Under Menu....... Window>Preferences there are no installed JREs options. Also, no Java project, class options in the menu is available.

5 5

Wiki page: Indigo updates in Fedora
by Andrew Overholt 14 Jun '11

14 Jun '11

Hi, I created a Fedora wiki page to track the work to get things updated for Indigo: https://fedoraproject.org/wiki/EclipseIndigo If you're helping out, please track things there and use strikethrough text for items that are finished. Thanks, Andrew

1 0

Getting rid of maven2-depmap.xml
by Stanislav Ochotnicky 12 Jun '11

12 Jun '11

This is just an update on progress on migrating from maven2 to maven package. I just committed changes to maven package that will do a few things: * direct processing of fragment files generated by %add*_maven_depmap macros * being able to process fragments in /usr/share/maven-fragments * being able to resolve pom files in /usr/share/maven-poms This will mean several things once the whole puzzle is created: * No need for %update_maven_depmap macro in %post and %postun * With it - no need for Require(post): jpackage-utils * No more rpmlint warnings about non-conf file in /etc * Sane place for pom files :-) * Simpler packaging (IMO) * Later on simpler patches to maven once we remove compat code. For now we are backward compatible, so maven still reads from /etc/maven/fragments and old _mavenpomdir. Obviously there is certain performance penalty for processing few hundred small files instead of one big file. However this performance hit is rather small and only affects mvn-local and mvn-rpmbuild so it won't affect users. Worst case scenario, I'd rather move regenerating of depmaps into maven shell script (comparing last change of depmap.xml with last modification of fragments and all that...). Right now no packaging modifications are necessary, since we don't want to break maven2 just yet :-) Next up: jpackage-utils and generation of maven2-depmap.xml even from /usr/share/maven-fragments (for maven2 compat). See https://fedoraproject.org/wiki/Migration_from_maven2 for more details and plan. -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

3 5

(no subject)
by Abdel Gadiel Martínez Lassonde 12 Jun '11

12 Jun '11

abdel.g.martinez.l(a)gmail.com

1 0

Introduction and a request for help
by Ruediger Landmann 10 Jun '11

10 Jun '11

Hi all; I'm part of the Red Hat and Fedora documentation teams, and along the way I've picked up maintainership of a few Java packages that are important to our publishing process. Unfortunately, one of them is causing me some trouble on F15, and I wondered if I could get some more eyes on it please? The package in question is FOP, which we use to generate PDFs. I can build the current upstream version (1.0)[1], but it doesn't actually work! Instead, FOP errors out because it can't find the event-model.xml files that it needs. There's a bug open that shows the error message -- https://bugzilla.redhat.com/show_bug.cgi?id=689930 Comparing the package built on Koji with the binary available upstream, it seems that there should be one of these event model files for most of the classes in the .jar, but they're simply not created at build time. The problem is in our EventProducerCollector, which is patched to use a different version of qdox (1.12) from the one that upstream bundles with FOP (1.6). Specifically, clazz.getParentClass() is always null and would result in a null pointer exception: /home/rlandmann/rpmbuild/BUILD/fop-1.0/build.xml:374: java.lang.NullPointerException at com.thoughtworks.qdox.model.JavaMethod.getReturnType(JavaMethod.java:464) at com.thoughtworks.qdox.model.JavaMethodDelegate.getReturnType(JavaMethodDelegate.java:26) at com.thoughtworks.qdox.model.JavaMethodDelegate.getReturnType(JavaMethodDelegate.java:166) at org.apache.fop.tools.EventProducerCollector.createMethodModel(EventProducerCollector.java:142) at org.apache.fop.tools.EventProducerCollector.processEventProducerInterface(EventProducerCollector.java:130) at org.apache.fop.tools.EventProducerCollector.scanFile(EventProducerCollector.java:99) at org.apache.fop.tools.EventProducerCollectorTask.processFileSets(EventProducerCollectorTask.java:213) at org.apache.fop.tools.EventProducerCollectorTask.execute(EventProducerCollectorTask.java:69) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) ...except that we have a check at lines 125-127 that just quits if clazz.getParentClass() is null. If anyone has time and inclination to take a look for me, I'd appreciate any tips about what to try next. I can't see why getParentClass() isn't working on the various EventProducer classes in the source. :( TIA Rudi [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=246382

2 1

Warning: Removing commons-* symlinks
by spike 07 Jun '11

07 Jun '11

Hi, As some of you may know, apache-commons packages usually install their jar(s) to apache-commons-*.jar and provides a symlink named commons-*.jar. Some also provide a similar symlink for the javadoc directory, some don't. The shorter symlink doesn't provides any advantage (at least, I don't know any) but causes trouble from time to time (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=447156) and clutters javadir and javadocdir. Therefore, I'll remove both the jar and the javadoc symlink at least for the apache-commons packages I (co-)maintain. Please check you spec file if you are using one of those and adapt accordingly. If you are a apache-commons maintainer (Carl, Mat, Mohamed, Orion and Sandro), please consider to do the same for your packages or let me know if you want me to do it for you. Regards, Chris

4 4

packaging problem using maven3
by David Nalley 03 Jun '11

03 Jun '11

Hi folks, Disclaimer first: I am a newb to java packaging, so excuse my ignorance. I am working on packaging a number of java packages[1]. And currently on apache-log4j-extras. However, I currently get this far[2]. My spec file is here[3]. I am certain it is something simple and obvious that I am missing. Ohhh this is on F15 btw. Thanks [1]http://fedoraproject.org/wiki/Cloudstack [2]http://fpaste.org/PTTq/ [3]http://ke4qqq.fedorapeople.org/apache-log4j-extras.spec

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel June 2011