From loganjerry at gmail.com Sun Mar 1 06:35:40 2009 From: loganjerry at gmail.com (Jerry James) Date: Sat, 28 Feb 2009 23:35:40 -0700 Subject: [fedora-java] Maven linkage error Message-ID: <870180fe0902282235o27dc72fdsbc33de551b6bb3a3@mail.gmail.com> The jsr-305 package failed the mass rebuild due to maven being unavailable at the time. Now that maven is reported to be fixed, I updated the sources to the latest upstream version and tried to rebuild. I'm heading out of town shortly, so I don't have time to diagnose the error I got on x86_64: http://koji.fedoraproject.org/koji/taskinfo?taskID=1210109 The fact that the build succeeded on i586 suggests to me that this is yet another problem with maven or one of its dependencies. If someone recognizes the symptoms, please give me a clue. Otherwise I'll try to figure it out when I get back on Wednesday. Regards, -- Jerry James http://loganjerry.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From choeger at cs.tu-berlin.de Mon Mar 2 15:04:31 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 02 Mar 2009 16:04:31 +0100 Subject: [fedora-java] Just in case i am being totally wrong Message-ID: <1236006271.861.1.camel@choeger6> Hi, just in case my reported bug https://bugzilla.redhat.com/show_bug.cgi?id=488076 is caused 50cm from the monitor. Has anyone encountered this before? Is maven really _that_ useless on fedora nowadays? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dbhole at redhat.com Mon Mar 2 15:30:49 2009 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 2 Mar 2009 10:30:49 -0500 Subject: [fedora-java] Maven linkage error In-Reply-To: <870180fe0902282235o27dc72fdsbc33de551b6bb3a3@mail.gmail.com> References: <870180fe0902282235o27dc72fdsbc33de551b6bb3a3@mail.gmail.com> Message-ID: <20090302153049.GA24713@redhat.com> * Jerry James [2009-03-01 01:36]: > The jsr-305 package failed the mass rebuild due to maven being unavailable at > the time. Now that maven is reported to be fixed, I updated the sources to the > latest upstream version and tried to rebuild. I'm heading out of town shortly, > so I don't have time to diagnose the error I got on x86_64: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1210109 > Hmm, this looks like the same problem that is causing maven rebuild to fail. If you need the package to be rebuilt immediately, and don't need to use gcj, you can always build with openjdk (BR java-1.6.0-openjdk-devel)... Deepak > The fact that the build succeeded on i586 suggests to me that this is yet > another problem with maven or one of its dependencies. If someone recognizes > the symptoms, please give me a clue. Otherwise I'll try to figure it out when > I get back on Wednesday. Regards, > -- > Jerry James > http://loganjerry.googlepages.com/ > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From ismael at olea.org Mon Mar 2 15:54:19 2009 From: ismael at olea.org (Ismael Olea) Date: Mon, 2 Mar 2009 16:54:19 +0100 Subject: [fedora-java] Just in case i am being totally wrong In-Reply-To: <1236006271.861.1.camel@choeger6> References: <1236006271.861.1.camel@choeger6> Message-ID: <22a365930903020754p6e5f1799rf312d23952df113b@mail.gmail.com> have you tried with mvn-jpp? It was mentioned in the list few days ago. 2009/3/2 Christoph H?ger > Hi, > > just in case my reported bug > > https://bugzilla.redhat.com/show_bug.cgi?id=488076 > > is caused 50cm from the monitor. > > Has anyone encountered this before? Is maven really _that_ useless on > fedora nowadays? > > regards > > christoph > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > > -- Ismael Olea http://olea.org/diario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Victor.Vasilyev at Sun.COM Mon Mar 2 16:10:02 2009 From: Victor.Vasilyev at Sun.COM (Victor Vasilyev) Date: Mon, 02 Mar 2009 19:10:02 +0300 Subject: [fedora-java] Maven linkage error In-Reply-To: <20090302153049.GA24713@redhat.com> References: <870180fe0902282235o27dc72fdsbc33de551b6bb3a3@mail.gmail.com> <20090302153049.GA24713@redhat.com> Message-ID: <49AC04DA.40009@sun.com> FYI The simplest ini4j package has been built successfully: http://koji.fedoraproject.org/koji/taskinfo?taskID=1213464 Thanks, Victor From choeger at cs.tu-berlin.de Mon Mar 2 16:23:28 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 02 Mar 2009 17:23:28 +0100 Subject: [fedora-java] Just in case i am being totally wrong In-Reply-To: <22a365930903020754p6e5f1799rf312d23952df113b@mail.gmail.com> References: <1236006271.861.1.camel@choeger6> <22a365930903020754p6e5f1799rf312d23952df113b@mail.gmail.com> Message-ID: <1236011008.861.11.camel@choeger6> Yepp, mvn-jpp goes even worse: [choeger at choeger6 my-app]$ mvn-jpp -X package /usr/lib/jvm/java + Error stacktraces are turned on. Maven version: 2.0.4 [DEBUG] Building Maven user-level plugin registry from: '/home/choeger/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/usr/share/maven2/conf/plugin-registry.xml' [INFO] Scanning for projects... [INFO] ---------------------------------------------------------------------------- [INFO] Building my-app [INFO] task-segment: [package] [INFO] ---------------------------------------------------------------------------- [DEBUG] maven-resources-plugin: using locally installed snapshot [DEBUG] maven-resources-plugin: resolved to version 2.3 from repository central [WARNING] Skipping non filebased repository http://repo1.maven.org/maven2 in full offline mode [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-resources-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.3 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) [INFO] ------------------------------------------------------------------------ [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving version for 'org.apache.maven.plugins:maven-resources-plugin': Unable to read the metadata file for artifact 'org.apache.maven.plugins:maven-resources-plugin:pom': Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.3 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1261) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1011) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:975) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionResolutionException: Error resolving version for 'org.apache.maven.plugins:maven-resources-plugin': Unable to read the metadata file for artifact 'org.apache.maven.plugins:maven-resources-plugin:pom': Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.3 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersionManager.java:684) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:183) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:87) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:158) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) ... 18 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file for artifact 'org.apache.maven.plugins:maven-resources-plugin:pom': Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.3 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:131) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersionManager.java:676) ... 22 more Caused by: org.apache.maven.project.ProjectBuildingException: Error getting POM for 'org.apache.maven.plugins:maven-resources-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.3 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:501) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) ... 23 more Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-resources-plugin:pom:2.3 from the specified remote repositories: __jpp_repo__ (file:///usr/share/maven2/repository), central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:132) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:467) ... 25 more [INFO] ------------------------------------------------------------------------ [INFO] Total time: < 1 second [INFO] Finished at: Mon Mar 02 17:07:23 CET 2009 [INFO] Final Memory: 1M/40M [INFO] ------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From choeger at cs.tu-berlin.de Mon Mar 2 22:34:57 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 02 Mar 2009 23:34:57 +0100 Subject: [fedora-java] maven and eclipse Message-ID: <1236033297.861.16.camel@choeger6> Hi all, so I figured what caused my maven setup to suck. .m2 was corrupted. But now I encounter another small problem. I have a library (page-runtime) which is a dependency of another project (page). When editing page in eclipse I want to have source code and/or javadoc set in .classpath. I could do that manually, but mvn eclipse:eclipse -DdownloadSources=true should do that, but it does not. Any advice on that? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From overholt at redhat.com Fri Mar 6 19:45:07 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 06 Mar 2009 14:45:07 -0500 Subject: [fedora-java] Separate ecj SRPM Message-ID: <1236368707.3456.53.camel@vvvvt> Hi, We'd like to enable an RPM script that mirrors OSGi Require-Bundle, Import-Package, and Export-Package statements into RPM virtual Requires and Provides [0]. While testing this, Alphonse van Assche discovered that our eclipse-ecj package should actually Require eclipse-rcp [1]. eclipse-rcp also includes SWT which itself needs a bunch of GNOME libraries and XULRunner. I don't think we want java-gcj-compat dragging in XULRunner and a bunch of GNOME libraries. Therefore, I think we need to have a separate ecj SRPM/RPM [2]. I have whipped up a simple one for use by java-gcj-compat and put it here: http://overholt.fedorapeople.org/ecj-3.4.2-1.fc10.src.rpm The java-gcj-compat maintainers will have to own it and therefore test it out. I don't anticipate any issues, but please test it ASAP so we can deal with any fallout. Once it's been deemed acceptable, it will have to go through a review which I probably shouldn't do :) Then, the eclipse package will need to: - remove all references to ecj - keep jdtcore symlinks but not ecj symlinks - move jdtcore symlinks to -jdt package and remove -ecj package This is all pretty minor and can be done very quickly. Ideally we'd get it done before the beta freeze on Tuesday. If we can't get it done by then, we could perhaps justify the minor changes for after the freeze or wait until F-12. Thanks, Andrew [0] Having automatic and correct OSGi bundle-level requirements matched in our RPMs will be very nice. We will obviously still need BuildRequires but we'll know at install time if there will be an error with OSGi dependency resolution at runtime. [1] This is because our eclipse-ecj package contains the org.eclipse.jdt.core plugin which needs org.eclipse.core.runtime among other stuff and core.runtime is in the RCP feature. Note that the new ecj package will contain just the batch compiler part of jdt.core -- as opposed to the entire thing like we do now -- so it won't have the dependency on any RCP bundles at the OSGi level (in fact, it won't even be an OSGi bundle). [2] There are other benefits to a standalone ecj SRPM, of course: - we don't need to patch org.eclipse.jdt.core and diverge from upstream - GCCMain -- the gcj driver for ecj -- can go into the ecj JAR and not jdt.core itself - bootstrapping a full gcc SRPM no longer requires the output of building an eclipse SRPM One concern is that RHEL-5 has an unversioned Obsoletes/Provides on "ecj" which should probably get fixed. From david at zarb.org Fri Mar 6 21:06:59 2009 From: david at zarb.org (David Walluck) Date: Fri, 06 Mar 2009 16:06:59 -0500 Subject: [fedora-java] Separate ecj SRPM In-Reply-To: <1236368707.3456.53.camel@vvvvt> References: <1236368707.3456.53.camel@vvvvt> Message-ID: <49B19073.2070507@zarb.org> Andrew Overholt wrote: > One concern is that RHEL-5 has an unversioned Obsoletes/Provides on > "ecj" which should probably get fixed. Fedora eclipse-ecj is also missing an epoch, but only for the ecj Provides and Obsoletes. $ rpm -q --provides eclipse-ecj ecj = 3.4.1-5.fc10 eclipse-ecj = 1:3.4.1-5.fc10 eclipse-ecj(x86-64) = 1:3.4.1-5.fc10 $ rpm -q --obsoletes eclipse-ecj ecj < 3.4.1-5.fc10 I think that this is causing conflicts with the standalone ecj packages currently floating around JPackage and some internal Red Hat builds. Aside from that, I am all for a standalone ecj. I am also for a standalone swt, but that is another can of worms. In either case, it would allow those packages to grow independently of eclipse builds (or their bugs). And as you mentioned, they are much quicker to build and update. -- Sincerely, David Walluck From overholt at redhat.com Fri Mar 6 21:08:55 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 06 Mar 2009 16:08:55 -0500 Subject: [fedora-java] Separate ecj SRPM In-Reply-To: <49B19073.2070507@zarb.org> References: <1236368707.3456.53.camel@vvvvt> <49B19073.2070507@zarb.org> Message-ID: <1236373735.3456.56.camel@vvvvt> On Fri, 2009-03-06 at 16:06 -0500, David Walluck wrote: > Andrew Overholt wrote: > > One concern is that RHEL-5 has an unversioned Obsoletes/Provides on > > "ecj" which should probably get fixed. > > Fedora eclipse-ecj is also missing an epoch, but only for the ecj > Provides and Obsoletes. Yeah, I saw that :) Thanks. > Aside from that, I am all for a standalone ecj. Cool. Andrew From aph at redhat.com Sat Mar 7 08:44:26 2009 From: aph at redhat.com (Andrew Haley) Date: Sat, 07 Mar 2009 08:44:26 +0000 Subject: [fedora-java] Separate ecj SRPM In-Reply-To: <1236373735.3456.56.camel@vvvvt> References: <1236368707.3456.53.camel@vvvvt> <49B19073.2070507@zarb.org> <1236373735.3456.56.camel@vvvvt> Message-ID: <49B233EA.5040702@redhat.com> Andrew Overholt wrote: > On Fri, 2009-03-06 at 16:06 -0500, David Walluck wrote: >> Andrew Overholt wrote: >>> One concern is that RHEL-5 has an unversioned Obsoletes/Provides on >>> "ecj" which should probably get fixed. >> Fedora eclipse-ecj is also missing an epoch, but only for the ecj >> Provides and Obsoletes. > > Yeah, I saw that :) Thanks. > >> Aside from that, I am all for a standalone ecj. > > Cool. Yes, that'll help a lot. Andrew. From choeger at cs.tu-berlin.de Mon Mar 23 18:49:51 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 23 Mar 2009 19:49:51 +0100 Subject: [fedora-java] can java do magic? (possible unwanted caching) Message-ID: <1237834191.28931.22.camel@choeger5.umpa.netz> Hi all, I am currently trying to add incremental parsing (TM) to a java based LR(n) parser. To prove that it works, I have the following test setup: For every given test input file the following steps are run: - parse that file normally - for every token (well, for large files every 100th token or so) in that file, add a test case which assumes that token has changed and runs the incremental parser with that information This gives me for a really large file some 100 test cases and two _really_ strange things. 1. Memory growth from test case to test case: As I add tests dynamically I run a single testsuite which creates all test cases, so I cannot fork a new vm for every test case. That should not make any difference, because in tearDown() I set all fields of the test case to null and manually invoke the garbage collector. Still the heap memory growth about 1 or 2 MB with every test case run, resulting in huge performance holes when the heap runs full and finally a HeapOverflowException - Remember: I set _all_ fields of the test cases to null after the test was run - 2. And this is where the WTF-o-meter goes through the ceiling: On one test the non incremental parser takes 300ms on a 18K input file containing ~ 2800 tokens (which is a nice performance, I think). When I run my incremental parser with the very first token marked as changed it's finished after only 30ms. That would be a very good result if the incremental parser implementation was finished yet, but it is not! Currently that two invocations run exactly the same code path! So I see a reduction to 10% in runtime only by invoking the same code path again. If I would encounter both phenomenons one at a time I would blame (or praise in case of 2.) openjdks jvm for it, but having both leaves me with the guess of some kind of code caching mechanism in the background. Is that some kind of hot feature? And how (for the sake of benchmarking) can I deactivate it? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From Victor.Vasilyev at Sun.COM Wed Mar 25 08:31:10 2009 From: Victor.Vasilyev at Sun.COM (Victor Vasilyev) Date: Wed, 25 Mar 2009 11:31:10 +0300 Subject: [fedora-java] can java do magic? (possible unwanted caching) In-Reply-To: <1237834191.28931.22.camel@choeger5.umpa.netz> References: <1237834191.28931.22.camel@choeger5.umpa.netz> Message-ID: <49C9EBCE.6040308@sun.com> Christoph H?ger wrote: > Hi all, > > I am currently trying to add incremental parsing (TM) to a java based > LR(n) parser. To prove that it works, I have the following test setup: > > For every given test input file the following steps are run: > > - parse that file normally > > - for every token (well, for large files every 100th token or so) in > that file, add a test case which assumes that token has changed and runs > the incremental parser with that information > > This gives me for a really large file some 100 test cases and two > _really_ strange things. > > 1. Memory growth from test case to test case: As I add tests dynamically > I run a single testsuite which creates all test cases, so I cannot fork > a new vm for every test case. That should not make any difference, > because in tearDown() I set all fields of the test case to null and > manually invoke the garbage collector. Still the heap memory growth > about 1 or 2 MB with every test case run, resulting in huge performance > holes when the heap runs full and finally a HeapOverflowException > - Remember: I set _all_ fields of the test cases to null after the test > was run - > > 2. And this is where the WTF-o-meter goes through the ceiling: On one > test the non incremental parser takes 300ms on a 18K input file > containing ~ 2800 tokens (which is a nice performance, I think). When I > run my incremental parser with the very first token marked as changed > it's finished after only 30ms. That would be a very good result if the > incremental parser implementation was finished yet, but it is not! > Currently that two invocations run exactly the same code path! So I see > a reduction to 10% in runtime only by invoking the same code path again. > > If I would encounter both phenomenons one at a time I would blame (or > praise in case of 2.) openjdks jvm for it, but having both leaves me > with the guess of some kind of code caching mechanism in the background. > > Is that some kind of hot feature? And how (for the sake of benchmarking) > can I deactivate it? > > regards > > christoph > 1. I think, the NetBeans Profiler [1] would help you to obtain objective info about described problems. 2. Note, loaded classes of tests won't be collected by GC until their Class Loader is in-use. 3. The Parsing API [2] may be also interesting for you. [1] http://www.netbeans.org/features/java/profiler.html [2] http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-parsing-api/index.html Cheers, Victor From theBohemian at gmx.net Mon Mar 30 10:29:46 2009 From: theBohemian at gmx.net (Robert Schuster) Date: Mon, 30 Mar 2009 12:29:46 +0200 Subject: [fedora-java] RXTX not in Fedora? Message-ID: <49D09F1A.5070107@gmx.net> is it true that the Java library for serial communication RXTX[0] is not part of the distribution? I searched for it using yum and was not successful. Maybe its name is different from what I expected. If it is there, what is the package's nam= e? Regards Robert [0] - http://users.frii.com/jarvi/rxtx/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From overholt at redhat.com Mon Mar 30 13:58:23 2009 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 30 Mar 2009 09:58:23 -0400 Subject: [fedora-java] RXTX not in Fedora? In-Reply-To: <49D09F1A.5070107@gmx.net> References: <49D09F1A.5070107@gmx.net> Message-ID: <1238421503.3476.32.camel@vvvvt> On Mon, 2009-03-30 at 12:29 +0200, Robert Schuster wrote: > is it true that the Java library for serial communication RXTX[0] is not > part of the distribution? You could always submit and maintain it :) Andrew