java-devel October 2010

java-devel@lists.fedoraproject.org

12 participants
17 discussions

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

Renamed jakarta-commons-* packages
by Mat Booth 02 Nov '10

02 Nov '10

Hi guys, During the great jakarta-commons to apache-commons package rename of 2010, [1] the following packages of yours have been obsoleted by versions with a new apache-prefixed name and a ticket has been raised with rel-eng has been raised to block them [2] from F14 and F15: fnasser: jakarta-commons-beanutils jakarta-commons-configuration jakarta-commons-el jakarta-commons-jxpath pcheung: jakarta-commons-daemon jakarta-commons-fileupload jakarta-commons-net In order to complete the process, it is necessary for the package owner to retire the package in pkgdb [3] so if I'd be most grateful if you'd be able to do that or release ownership of the package so that someone else may do it. Thanks for your help, Mat [1] https://fedoraproject.org/wiki/JakartaCommonsRename [2] https://fedorahosted.org/rel-eng/ticket/4128 [3] https://admin.fedoraproject.org/pkgdb/ -- Mat Booth http://fedoraproject.org/get-fedora

3 5

Java SIG Oct 19 meeting minutes & summary
by Stanislav Ochotnicky 22 Oct '10

22 Oct '10

Hi everyone, We had our bi-weekly meeting yesterday so I'm going to summarize what is happening right now in Fedora-Java world. People present: * cspike * ggraz * mbooth * akurtakov * sochotni Status updates: * Maven 3 - work on custom resolver is starting ** will publish git repo on java-devel in due time * Packages monitored by java sig ** List is getting longer, once semi-finished akurtakov will ask for java-sig user to be created and added to these packages for watchcommits ** agreed that commits will be sent to java-devel * New guidelines are shaping up, several new improvements suggested ** see, comment, improve: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate * Finishing up jakarta->apache rename (packages ready, need maintainers of original packages to retire them - fnasser, jmrodri) ** also create apache-commons-parent package with proper requires/pom.xml Meetbot minutes (note that assigned actions look a bit like two man show, but that's not the case...we just forgot to do #action properly :-) ) ===================================================================== #fedora-meeting: Java SIG -- https://fedoraproject.org/wiki/SIGs/Java ===================================================================== Meeting started by akurtakov_ at 17:02:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-19/fedora-meeting.2… . Meeting summary --------------- * roll-call (akurtakov_, 17:03:38) * akurtakov_ cspike ggraz mbooth sochotni present (sochotni, 17:04:00) * akurtakov_ cspike ggraz mbooth sochotni present (akurtakov_, 17:04:25) * maven 3 status (akurtakov_, 17:05:33) * LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm (sochotni, 17:06:37) * LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm maven 3 source rpm (sochotni, 17:06:45) * LINK: https://fedoraproject.org/wiki/MavenUpdate#Maven_3 may be helpful, too (cspike, 17:06:58) * LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc15.noarch.rpm maven 3 binary rpm (sochotni, 17:07:01) * ACTION: sochotni will put maven 3 spec for review (sochotni, 17:12:25) * ACTION: sochotni will create public git repo with custom resolver so others can see/review (sochotni, 17:12:56) * new resolver should be basically re-implemented maven-aether-provider (sochotni, 17:14:45) * Java packages monitoring (sochotni, 17:15:04) * LINK: https://fedoraproject.org/wiki/SIGs/Java/Monitored_packages Wiki to collect Java packages for monitoring (sochotni, 17:15:27) * LINK: https://fedorahosted.org/fedora-infrastructure/ infra ticketing system (sochotni, 17:19:26) * ACTION: akurtakov_ will file infra ticket asking for java pseudo user (sochotni, 17:19:44) * java-sig user will forward to java-devel mailing list (sochotni, 17:26:08) * New packaging guidelines (akurtakov_, 17:26:54) * LINK: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate Draft (sochotni, 17:27:15) * ACTION: akurtakov_ to add javadoc:aggregate to guidelines (akurtakov_, 17:31:31) * ACTION: akurtakov_ add to guidelines that ant packages that have pom files MUST install them (akurtakov_, 17:35:38) * ACTION: akurtakov_ f there is no pom consider using the one from maven central addition to guidelines (akurtakov_, 17:37:40) * ACTION: akurtakov_ merge parts from JPPMavenReadme and explain when usage of depmap is reasonable and when one have to patch the pom.xml file (akurtakov_, 17:43:42) * LINK: http://fedoraproject.org/wiki/Fedora_meeting_channel (cspike, 17:54:56) * Update Java SIG wiki (sochotni, 17:57:27) * open-floor (akurtakov_, 17:58:15) * LINK: http://fedoraproject.org/wiki/JakartaCommonsRename (cspike, 17:59:12) * LINK: http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life (cspike, 18:01:11) * ACTION: sochotni try to contact jmrodri and fnasser about orphaning their jakarta packages (sochotni, 18:05:32) Meeting ended at 18:25:51 UTC. Action Items ------------ * sochotni will put maven 3 spec for review * sochotni will create public git repo with custom resolver so others can see/review * akurtakov_ will file infra ticket asking for java pseudo user * akurtakov_ to add javadoc:aggregate to guidelines * akurtakov_ add to guidelines that ant packages that have pom files MUST install them * akurtakov_ f there is no pom consider using the one from maven central addition to guidelines * akurtakov_ merge parts from JPPMavenReadme and explain when usage of depmap is reasonable and when one have to patch the pom.xml file * sochotni try to contact jmrodri and fnasser about orphaning their jakarta packages Action Items, by person ----------------------- * akurtakov_ * akurtakov_ will file infra ticket asking for java pseudo user * akurtakov_ to add javadoc:aggregate to guidelines * akurtakov_ add to guidelines that ant packages that have pom files MUST install them * akurtakov_ f there is no pom consider using the one from maven central addition to guidelines * akurtakov_ merge parts from JPPMavenReadme and explain when usage of depmap is reasonable and when one have to patch the pom.xml file * sochotni * sochotni will put maven 3 spec for review * sochotni will create public git repo with custom resolver so others can see/review * sochotni try to contact jmrodri and fnasser about orphaning their jakarta packages * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * sochotni (132) * akurtakov_ (95) * cspike (43) * ggraz (27) * mbooth (12) * zodbot (3) -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com

3 3

depfind
by Adam Young 21 Oct '10

21 Oct '10

Having battled the dependency isssues wuith Maven and Buildr on a couple of occasions, I wrote a bunch of scripts for dealing with this stuff and posted it on my blog. And someone responded with this: Why on the Earth one would use Ruby in order to extract deps from the Java files?! Dude, use the right tool for right purpose. http://depfind.sourceforge.net/Manual.html I notice that it isn't in Fedora, nor is it in JPackage, so I wonder if other members of the team have used it or even know about it. It might help many of the people with dependency issues. Boy did that last line have a double meaning. Anyway, figured it was worth bringin to peoples attention and getting some feedback. I'm not in Java mode for this project, so I don't have the cycles to spend on it; maybe someone else does.

2 2

Eclipse Fedora Packager: Call for Testers and Contributors
by Severin Gehwolf 20 Oct '10

20 Oct '10

Hi Fedora Packagers, <pitch> I would like to bring a new Eclipse plug-in to your attention: Eclipse Fedora Packager[1] It's a tool which can help speeding up your Fedora packaging work :-) In a nutshell, it offers similar features as the command-line client fedpkg, but with a GUI. Here's a list of its current features (more to come): - Conveniently clone Fedora Git projects, switch branches etc. - RPM-spec-file editor with syntax highlighting, auto-completion and changelog support (<Ctrl>+<Alt>+C keyboard shortcut) - Download source files and upload new source files - Prepare local builds (execute %prep section of your spec-file) - Create source RPM files based on current spec-file - Execute local builds - Push builds to Koji (the Fedora build system) - Mock builds - Push Bodhi updates (the Fedora updates system) - Eclipse Git support (via EGit) If those features cover all (most) tasks you usually carry out when packaging your software for Fedora, Eclipse Fedora Packager may be a tool for you to look into. Still not sure? It might be the right tool for your Fedora packaging if: - You prefer GUI tools over command-line-clients - You are already familiar with Eclipse or some other IDE - You are a developer and you use Eclipse on a daily basis - You have never packaged something for Fedora, but would like to do so. - You don't know much about how software gets into Fedora but need to get it packaged for it. - Your main goal is to get your software packaged for Fedora as opposed to learning a lot of tooling. Sounds interesting? Want to try it out? Here's what you need to do (please note that Eclipse Fedora Packager will officially come with Fedora 14 for the first time): If you have a F14 box, "yum install eclipse-fedorapackager". Then fire up Eclipse and follow instructions of our user guide: https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide On F13 (I'm using it) and older (untested) you need to install some rawhide packages. This is what I usually do: 1.) Install dependencies (non-rawhide): $ yum install eclipse eclipse-changelog eclipse-rpm-editor \ fedora-release-rawhide fedora-packager 2.) Install eclipse-fedorapackager and eclipse-egit from rawhide $ yum install --enablerepo=rawhide eclipse-fedorapackger 3.) Follow our user guide[2] for information on how to get started using the plug-in. The latest version of eclipse-fedorapackager is 0.1.8 (in rawhide). Here's a link to today's build: https://koji.fedoraproject.org/koji/buildinfo?buildID=201275 Feedback, testing, bug reports, contributions are very much appreciated. Our Trac instance is here (use your FAS to login): https://fedorahosted.org/eclipse-fedorapackager/ If you have questions, run into problems or would be interested in contributing please let me know: email: sgehwolf AT redhat DOT com (this list is preferred) IRC: my nick is "jerboaa" (e.g. #fedora-devel or #fedora-java) I'll get back to you as soon as possible. In any case, let us know what you think ;-) </pitch> Thanks, Severin [1] https://fedorahosted.org/eclipse-fedorapackager/ (Trac/wiki) [2] https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide

1 0

SIG meeting agenda for Oct 19 2010
by Stanislav Ochotnicky 18 Oct '10

18 Oct '10

We will have another Java SIG meeting on Oct 19 at 17:00 UTC. Agenda is as follows, if you are attending and would like to discuss something please add it to the Meeting page: https://fedoraproject.org/wiki/Meeting:Java_SIG_2010-10-19 * Maven-3 dependencies and update status (sochotni) o See https://fedoraproject.org/wiki/MavenUpdate#Maven_3 o All dependencies are reviewed, we have vanilla maven-3 srpms * Java packages to be monitored by the SIG (sochotni) o See https://fedoraproject.org/wiki/SIGs/Java/Monitored_packages o Please add yours if you'd like your commits to be double-checked * New packaging guidelines status (akurtakov) o See https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate * SIG wiki main page updates/rework. Low hanging fruit for newcomers etc. (cspike, sochotni) -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com

1 0

Maven plugin update status
by Pierre-Yves Chibon 14 Oct '10

14 Oct '10

Dear all, Running my little script there is the status of update for the maven plugin: * maven-antrun-plugin is not up to date upstream: 1.6, Fedora: 1.5-1.fc15 * maven-compiler-plugin is not up to date upstream: 2.3.2, Fedora: 2.0.2-2.fc14 * maven-dependency-plugin is not up to date upstream: 2.1, Fedora: 2.2-0.2.svn949573.fc14 * maven-ejb-plugin is not up to date upstream: 2.3, Fedora: 2.2.1-5.fc14 * maven-install-plugin is not up to date upstream: 2.3.1, Fedora: 2.3-8.fc15 * maven-repository-plugin is not up to date upstream: 2.3.1, Fedora: 2.3-3.fc15 * maven-shade-plugin is not up to date upstream: 1.4, Fedora: 1.3.3-2.fc14 * maven-site-plugin is not up to date upstream: 3.0, Fedora: 2.1-3.fc14 - maven-dependency-plugin is a false positive The other one looks true positive. Regards, Pierre

2 2

Re: [fedora-java] [Crash-catcher] java reports by crash catcher
by Mark Wielaard 13 Oct '10

13 Oct '10

Looks like the java-devel list disgarded any email from non-subscribers (so that included my initial email and your reply). Hope that is fixed now. I left all text in the email, even though my reply consists of only on tiny paragraph so others can catch up on the discussion. On Mon, 2010-10-11 at 15:32 +0200, Jiri Moskovcak wrote: > On 10/11/2010 03:19 PM, Mark Wielaard wrote: > > Hi Jiri, > > > > On Wed, 2010-10-06 at 10:11 +0200, Jiri Moskovcak wrote: > >> what about resurrecting this feature for F15? We made some changes to > >> abrt so it uses socket instead of the helper app, so we can send you the > >> info on how to use it if you'd be interested in implementing it to javavm. > > > > I currently don't have the time to work on this, but do think they are > > good ideas that would improve abrt a lot for java/jvm based packages. > > > > I added Fedora Java Developers list to the CC in the hope someone would > > be interested. So if someone is looking for a fun (python!) hack, this > > might be interesting. > > > Actually it would be probably more C fun. > > > One idea is that abrt/crash-catcher creates a lot of bugzilla reports > > against the jvm package. Those do include a native backtrace, but don't > > include the (often far more useful) hs_err_pid.log file. It would be > > nice if abrt would find it and offer to automagically attach it to the > > bug report. > > Attaching the file is not a problem, but does it live in some > predictable location? It lives in the current working directory of the JVM. In theory one could hack the hotspot sources to place it somewhere else. But what would be a good place? > > The other idea discussed was when a java program exits through an > > uncaught exception in the main thread. In that case you might want to > > catch that and create a bug report against the package that contains the > > main class file (instead of against the jvm package). > > > > This one is actually what I'd like to be done in F15. > > > The first idea is probably the least work and has the most benefit in > > the short term (at least for the java-1.6.0-openjdk bug maintainers). > > > >> On 11/16/2009 09:43 AM, Jiri Moskovcak wrote: > >>> On 11/13/2009 11:00 AM, Mark Wielaard wrote: > >>>> On Wed, 2009-11-11 at 11:05 +0100, Jiri Moskovcak wrote: > >>>>> On 11/05/2009 05:49 PM, Mark Wielaard wrote: > >>>>>> The code is already setup to save if in a different place if necessary > >>>>>> (in fact if the current directory isn't writable for the user it will > >>>>>> try saving in /tmp). If /var/log/java is made writable for all users > >>>>>> that could be a place to dump the log also. > >>>>>> > >>>>>> The code can also be modified to actually call abrt (or an helper > >>>>>> executable/script) if necessary either with the path of the log file or > >>>>>> even with an open file descriptor to the log. > >>>>>> > >>>>> We use a helper to handle the python logs, so I think we could use the > >>>>> same helper for saving the java logs. > >>>> > >>>> Do you have a pointer to the code for this helper? > >>> > >>> http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob;f=src/Hooks/abrt… > >>> > >>> > >>>> > >>>>>>> The other thing I have in mind is how to catch an unhandled > >>>>>>> exception in > >>>>>>> java programs, because in this case the VM exits "normally" and abrt > >>>>>>> can't detect it. We managed to catch these exception in python by > >>>>>>> overriding the default exception handler by script that is > >>>>>>> automatically > >>>>>>> loaded everytime when python VM is started. If there would be some way > >>>>>>> to this for java we could wire this to ABRT. > >>>>>> > >>>>>> In principal we could install some uncaught exception handler, but > >>>>>> uncaught exceptions might not be fatal (although they are admittedly > >>>>>> sloppy). The program may even happily run even if one thread has an > >>>>>> uncaught exception (as long as there are other non-daemon threads > >>>>>> running). > >>>>>> > >>>>> ABRT doesn't care if it is or isn't fatal, this is up to your exception > >>>>> handler - you can just log the exception using the abrt helper (because > >>>>> even if the exception is not fatal, it's usually a bug..) and contiune > >>>>> running the program. > >>>> > >>>> This part is trickier than the above. In case of a JVM crash there is a > >>>> clear point where we catch that crash and produce the necessary logs for > >>>> a bug report. In case of an application specific uncaught exception > >>>> there is an uncaught exception handler mechanism, but the application > >>>> could already be using it (either for a specific Thread, the ThreadGroup > >>>> or system wide). This might require some surgery to get right (and > >>>> unobtrusive for the application running on the JVM). > >>>> > >>> > >>> This is really up to you as I don't know much about about insides of JVM. > >>> > >>>>>> How would you determine which package the exception belongs to? For > >>>>>> a VM > >>>>>> crash it is almost always the java VM package that should get the bug > >>>>>> report (since the VM just shouldn't crash ever). > >>>>> > >>>>> If I'm right the Java VM is compiled, so it creates a coredump and would > >>>>> be handled by a different hook then scripts, but that applies only if > >>>>> you don't catch the sigsegv, sigabrt (whichI think you do, to create the > >>>>> logs..) and let it die. > >>>> > >>>> Yes, the VM catches fatal signals and creates an hs_err log file based > >>>> on the information it can still retrieve at that point before dying. > >>>> > >>> > >>> Ok, so we need to find the way how to pass this logs to abrt hook. > >>> > >>>>> I think, as Java VM is a non-trivial programme, > >>>>> we should write a special handler for it, or we can try to improve the > >>>>> general hook for compiled programs to be able to handle some additional > >>>>> data as the log file if that would be enough. > >>>>> > >>>>>> But for uncaught > >>>>>> exceptions reporting it against the java VM package is definitely the > >>>>>> wrong thing to do. How do you solve that in the python case? > >>>>>> > >>>>> > >>>>> The python exception hook is run in the context of the running script, > >>>>> so it knows the script name and the path to the script and then we can > >>>>> simply run $ rpm -qf /path/to/script to determine the package, the code > >>>>> to do this is: > >>>>> > >>>>> executable = os.path.abspath(sys.argv[0]) > >>>> > >>>> Aha. I think we could determine the main class that is being run and the > >>>> classpath with .jar/.zip files that this class comes from. With that we > >>>> could probably achieve similar heuristics about the package that > >>>> provided the classes. > >>>> > >>>> Thanks, > >>>> > >>>> Mark

2 2

Maven 3 srpm & binary rpms for testing
by Stanislav Ochotnicky 13 Oct '10

13 Oct '10

Hi everyone, Quite a few people from Java SIG are responsible for this early version of maven3 rawhide rpms. Please try them out if you can for building your projects. This release is installable parallel to current maven2 so if any problems with maven2 appear after installing this version let me know. One caveat: there is no mvn3-jpp yet. I'll be working on it over the course of next few days. The command to run is mvn3. SRPM: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm RPM: http://sochotni.fedorapeople.org/maven-3.0-1.fc15.noarch.rpm You will need several dependencies that are currently under review. aether: https://bugzilla.redhat.com/show_bug.cgi?id=641967 (review done) sisu: https://bugzilla.redhat.com/show_bug.cgi?id=641390 (waiting) google-guice: https://bugzilla.redhat.com/show_bug.cgi?id=640992 (review done) -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com

1 0

Few maven 3 dependency reviews
by Stanislav Ochotnicky 12 Oct '10

12 Oct '10

Hi, as some of you know I've been working on getting maven 3 packaged for Fedora. Current status seems pretty good. I have all dependencies up for review and maven 3 builds with rawhide's mvn-jpp. This is where you come in. I could use someone reviewing these dependencies (ascending complexity): aether: https://bugzilla.redhat.com/show_bug.cgi?id=641967 sisu: https://bugzilla.redhat.com/show_bug.cgi?id=641390 google-guice: https://bugzilla.redhat.com/show_bug.cgi?id=640992 Thanks, -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2010