java-devel November 2005

java-devel@lists.fedoraproject.org

18 participants
20 discussions

avalon-framework and doclet classes
by Anthony Green 06 Jan '06

06 Jan '06

Gary - I was trying to build something recently that required org.apache.avalon.framework.logger.Log4JLogger from avalon-framework. The avalon-framework.jar file in FC4 appears to be missing this class. I grabbed the SRPM file from rawhide and attempted to build that instead. The build failed with this... [javadoc] java.lang.ClassNotFoundException: com.sun.tools.doclets.standard.Standard not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} I've seen this before. It seems that our com-sun-javadoc or com-sun-tools-doclets-Taglet jar should be on the default classpath somehow. In any case, I noticed that this build of the jar file includes the proper class, but as far as I can tell, this is the same SRPM that was used in FC4. Why wouldn't the FC4 jar file contain the Log4JLogger class? Thanks! AG

4 9

Release Notes
by Anthony Green 29 Nov '05

29 Nov '05

The current "Java" content for the release notes (from FC4) are pretty slim. I'll quote them below with my comments and questions... > Fedora Core 4 users are advised not to use the Java RPM provided by > Sun. It contains Provides that conflict with names used in packages > provided as part of Fedora Core 4. Because of this, Sun Java might > disappear from an installed system during package upgrade operations. I assume this is still true. Does anybody have a pointer to the details? > Fedora Core 4 users should use either the RPM available from > http://www.jpackage.org/, or manually install the Sun Java tarball > into `/opt/`. I think we should discourage the /opt solution, since it doesn't integrate with out alternatives-based solution. Also, I thought there were problems with using the binary RPM from JPackage, and users _have_ to rebuild from the SRPM. Does anybody know about this? > Sun Java 1.5+ is recommended for stability purposes. Is this really true? What about IBM or BEA? Should we even be making specific recommendations here? Perhaps this is best avoided. Thanks, AG

6 6

Many dependencies for eclipse-cdt
by Orion Poplawski 22 Nov '05

22 Nov '05

Are all of these really necessary? Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: eclipse-cdt i386 1:3.0.0_fc-1.FC4 CoRA 12 M Installing for dependencies: ant-javamail i386 1.6.2-3jpp_8fc CoRA 21 k cryptix noarch 3.2.0-4jpp_1fc CoRA 395 k cryptix-asn1 noarch 20011119-4jpp_1fc CoRA 180 k eclipse-platform i386 1:3.1.1-1jpp_1fc.FC4.4 CoRA 38 M eclipse-rcp i386 1:3.1.1-1jpp_1fc.FC4.4 CoRA 41 k jakarta-commons-dbcp noarch 1.2.1-3jpp_1fc CoRA 108 k jakarta-commons-el i386 1.0-2jpp_3fc CoRA 319 k jakarta-commons-fileupload noarch 1:1.0-3jpp_1fc CoRA 24 k jakarta-commons-launcher noarch 0.9-3jpp_1fc CoRA 42 k jakarta-commons-pool noarch 1.2-2jpp_1fc CoRA 46 k lucene i386 1.4.3-1jpp_3fc CoRA 795 k lucene-demo i386 1.4.3-1jpp_3fc CoRA 130 k puretls noarch 0.9-0.b4.1jpp_2fc CoRA 140 k tomcat5 i386 5.0.30-5jpp_6fc CoRA 3.5 M tomcat5-jasper i386 5.0.30-5jpp_6fc CoRA 970 k tomcat5-servlet-2.4-api i386 5.0.30-5jpp_6fc CoRA 353 k xerces-j2 i386 2.6.2-4jpp_5fc CoRA 2.2 M -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

2 2

missing rebuild-gcj-db and aot-compile-rpm scripts
by Thomas Fitzsimmons 18 Nov '05

18 Nov '05

Hi, People using Rawhide java-1.4.2-gcj-compat will have noticed that rebuild-gcj-db and aot-compile-rpm get deleted when upgrading from <= 1.4.2.0-40jpp_51rh to >= 1.4.2.0-40jpp_52rh. This was caused by a bug in "update-alternatives --install" where it would remove filenames that no longer appeared in the alternatives database: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173685 Bill Nottingham has built into Rawhide chkconfig-1.3.24-1, which I confirmed fixes the bug. In the meantime you can work around the problem by --force reinstalling java-1.4.2-gcj-compat >= 1.4.2.0-40jpp_52rh and java-1.4.2-gcj-compat-devel >= 1.4.2.0-40jpp_52rh from your yum cache. Tom

1 0

Fedora Core 5 Wishlist
by Thomas Fitzsimmons 16 Nov '05

16 Nov '05

Hi, I tried to send this yesterday but there was a problem with the Fedora list servers. Tom -------- Forwarded Message -------- > From: Thomas Fitzsimmons <fitzsim(a)redhat.com> > To: fedora-devel-java-list(a)redhat.com > Subject: Fedora Core 5 Wishlist > Date: Tue, 13 Sep 2005 21:16:31 -0400 > > Hi, > > I've been thinking about my GCJ-related goals for Fedora Core 5, due out > February 2006. Here's a categorized list: > > java-gcj-compat > =============== > > - GNU Crypto fix for Eclipse extssh support: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > Casey Marshall has already committed a Diffie-Hellman JCE provider to > GNU Classpath so this is just a matter of testing. > > - import all JAWT fixes: > > All the necessary patches are already in GNU Classpath and libgcj so > this is just a matter of testing that JOGL works properly on our > java-1.4.2-gcj-compat RPM. > > - Jessie merged into GNU Classpath > > - GNU Crypto core algorithms merged into GNU Classpath > > - gjdoc merged into GNU Classpath and thus ... > > - an --enable-javadocs option to libgcj > > - gcjx becomes java-gcj-compat's javac and javah commands: > > Not sure if this one is doable in time; I don't mean full gcjx, just > the bytecode-compiler portion of it split off into a standalone javac > executable. > > - include Tritonus or some sound implementation > > AWT > === > > - ImageMagick backend for ImageIO > > - Graphics/Imaging refactoring for GTK 2.8 and Cairo > > - MegaMek packages in Fedora Extras: > > http://megamek.sourceforge.net/ > > This just involves a few AWT bug fixes now. > > - fix all 1.5 japi issues in the java.awt.* packages > > - fix all 1.5 japi issues in the javax.imageio.* packages > > Swing > ===== > > - RHDB tools in Fedora Extras: > > http://sources.redhat.com/rhdb/administrator.html > > http://sources.redhat.com/rhdb/visualexplain.html > > http://sources.redhat.com/rhdb/controlcenter.html > > This will also require updating these tools to support PostgreSQL 8.0. > > - Limewire in Fedora Extras: > > http://www.limewire.org/ > > It would be absolutely awesome to have this Swing app working on the > free stack but I'm not sure it's doable in the FC5 time frame. Would > anyone like to undertake it? ;-) > > SWT > === > > - Azureus in Fedora Extras: > > http://azureus.sourceforge.net/ > > Again, not sure if this is doable before FC5 but this would be awesome > to have. > > gcjwebplugin > ============ > > - implement and test security features in GNU Classpath to allow running > untrusted bytecode > > It's very unlikely that this one will be finished before FC5 but I'd > like to at least have started the implementation by then. > > I'm hoping this list will inspire some volunteers, especially for the > big apps and GNU Classpath's security framework. Most of these items > are very doable and will greatly improve the free JPackage stack on > Fedora. > > Tom >

9 36

Native Eclipse 3.1 doesn't start
by Dominik Łeszyk 16 Nov '05

16 Nov '05

Hello, I'm really fresh to java-fedora stuff so maybe it's the reason for my problem: after compiling Eclipse 3.1 using the script from 'GNU Classpath Wiki' [1] I can't start it. There is an error log: !SESSION Tue Sep 13 13:36:30 GMT+02:00 2005 ------------------------------------ !ENTRY org.eclipse.core.launcher 4 0 2005-09-13 13:36:30.114 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter not found in org.eclipse.core.launcher.MainStartupClassLoader{urls= [file:/home/lechique/eclipse_test/./plugins/org.eclipse.osgi_3.1.0.jar.so], parent=null} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.eclipse.core.launcher.Main.invokeFramework(java.lang.String[], java.net.URL[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.basicRun(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.run(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.main(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) The compilation process went pretty smoothly (without any errors) and path for db file (gnu.gcj.precompiled.db.path) was set correctly. I don't understand but it seems that classloader doesn't see original jar libraries. Am I correct? What should I do? [1] http://developer.classpath.org/mediation/ClasspathShowcase Best Regards, Lechique Pozdrawia, Lechique -- "Mistakes are the portals of discovery" James Joyce

2 1

gij and Eclipse CVS checkout finalization
by Andrew Overholt 15 Nov '05

15 Nov '05

Hi Andrew and others, I spent a lot of time a few months ago working on $subj. After many dead ends, I decided it was more prudent to spend my time working on other issues. I have now returned to this issue and would like to pass it off to those who will have more luck than I did figuring out what is going wrong. Background information: ~~~~~~~~~~~~~~~~~~~~~~ RH Bug #161483 [1] CVS checkouts in Eclipse take an extremely long time to finish when run under gij. The issue occurs both when the relevant jars are natively-compiled and when they are not (although the problem is exacerbated when run with only bytecode). I have found a few modules that replicate the issue but the one I have used the most is GNU Classpath. The problem is independent of network issues as checkouts from a local CVS server exhibit the same behaviour. Things to note: ~~~~~~~~~~~~~~ The problem appears to be related to some sort of thread contention. I wrote a headless Eclipse CVS client (using the same code as the GUI CVS client) that does not reproduce the problem. Following the actual checkout of the files from CVS, Eclipse creates synchronization information for the files it has just checked out. Since this is an initial checkout, all folders are considered dirty so it descends into each folder. One of my original theories was that we were incorrectly computing dirty resources (or getting into some sort of recursive loop) but this is not the case. Much println'ing has told me that both gcj and the Sun JVM come up with the same list of dirty folders. Timing information that I have accumulated has shown that we are not spending an inordinate amount of time generating or writing the synchronization information but are instead spending too much time holding locks on the resources. On average we are holding the locks about 100 - 1000 times longer than the Sun JVM. This can be verified by a sysprof [2] sample [3] taken which shows a lot of time in Semaphore.acquire(). OProfile results corroborate this evidence. gnuplot was used at one point to see if the time spent was proportional to the number of files in the directory or to the disk space of said files. No correlation was observed. Note: at one point, I thought the problem was due to missing .sos for some jars because I could not duplicate the problem on my laptop. It turns out that if I changed the CVS compression level [4], I could somehow affect the timing such that it would indeed occur. Hyperthreaded machines seems impervious to this. There appears to be no way to reduce this to a test case so we are unfortunately left with duplicating the symptoms using Eclipse itself. How to duplicate: ~~~~~~~~~~~~~~~~ I have created a version of Anthony's excellent redhat-eclipse-demo RPM that contains a snapshot of GNU Classpath (from a while ago). This RPM will create a local pserver CVS server running on port 2402. It will also create the user anoncvs and put an exploded GNU Classpath checkout (owned by this user) in /var/lib/eclipse-demo-cvsroot. You can retrieve a copy of this RPM here: http://overholt.ca/redhat-eclipse-demo-2.0-1.noarch.rpm http://overholt.ca/redhat-eclipse-demo-2.0-1.src.rpm 1. Install Eclipse from either FC4 or rawhide. gcc versions do not seem to affect this problem and I've done most of my testing with 4.0.2-3 which was current in rawhide until recently. 2. Fire up Eclipse with a new workspace ... something like: eclipse -data ~/testcvsissueworkspace 3. Checkout classpath from your local CVS server: File->Import->Checkout Projects from CVS Next localhost, /var/lib/eclipse-demo-cvsroot anoncvs, anoncvs pserver, 2402, check 'Save password' Next classpath Finish 4. Observe that checkout hangs at final synchronization I am at a bit of a loss as to how to proceed. Any and all help is greatly appreciated. I will provide whatever information is necessary. (I wrote this email while on a plane and lost a bit of revision I had done just before my battery died. If anything's amiss, I blame that ;) Thank you, Andrew [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483 [2] http://www.daimi.au.dk/~sandmann/sysprof/ [3] http://overholt.ca/eclipse/checkout.sysprof [4] Window->Preferences->Team->CVS->Connection->Compression

5 10

gcj-dbtool --rebuild
by Thomas Fitzsimmons 15 Nov '05

15 Nov '05

Hi, Here's what "gcj-dbtool --rebuild" needs to do: Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into "$prefix/lib/gcj-$gcc_version/classmap.db". Even better for FC5 would be eliminating the need for individual .db files altogether. We could have "gcj-dbtool --rebuild" compare the .sos in /usr/lib with the database contents and add/remove any new/missing entries to/from classmap.db. Shipping a .db file per package is one divergence from JPackage spec files that Fernando's proposal doesn't address but that an improved gcj-dbtool would. Tom

5 8

Enhanced aot-compile script
by Fernando Nasser 15 Nov '05

15 Nov '05

Hi, I was thinking of having a 'aot-compile' command that would perform all tasks related to aot compilation. For instance: aot-compile by itself would perform the additional compilation steps necessary to generate the .so files etc., as currently done. aot-compile --rebuilddb would do the rebuild-gcj-db thing aot-compile --install <install arguments> would allow a conditional installation step and so forth. In addition to that, 'aot-compile' would either work or be a no-op, depending on certain conditions, like the presence of GCJ in the system, and/or some system-wide or local override configuration mechanism. This way, aot-compile statements can be added to an RPM spec file and that same spec file can be used to build bytecode or pre-compiled RPMs, depending on the settings. Adding just this script to jpackage-utils would allow us to eliminate differences between the spec files upstream and in other distros, except for having to remove the "BuildArch: noarch" line. It seems that there are a few cases to consider: 1) gcj is not installed ==> automatic ==> do not precompile 2) gcj is installed, but we don't want to pre-compile ==> override with either system or local config (we could test for "BuildArch: noarch"...) ==> do not precompile 3) gcj is installed, and we want to pre-compile ==> automatic ==> precompile There are perhaps some other conditions, like you want to build the bytecode with another Java and then use gcj to pre-compile... IMPORTANT: please note that aot-compile should not be tied to GCJ, but instead be a characteristic of any Java that is capable of pre-compilation. QUESTION: how to accommodate the differences in pre-compilation mechanisms? In any case, we should try and keep the command names generic so if necessary one day the JVMs that are AOT-capable can provide alternatives for those. Regards to all, Fernando

5 35

GNU Classpath hacker room at FOSDEM 2006
by Mark Wielaard 14 Nov '05

14 Nov '05

Hi all, Like the last couple of years we want to come together with all the projects around GNU Classpath and the various free runtimes, compiler and tool projects to discuss what has happened in the last year in the Free Software community and what the next year will bring us during FOSDEM. The 6th edition of FOSDEM (Free and Opensource Software Developers' European Meeting) will take place on February 25+26 2006 in Brussels (Belgium), at the Solbosch Campus of the ULB (Free University of Brussels). FOSDEM is a free and non-commercial event for the community and organized by the community. See http://www.fosdem.org/ We were thinking of the following setup: - Saturday from 13:00 to 17:30 - "End-User talks" presentations to promote what we all build together to a wider audience that might have heard of what we do, but haven't actually seen it in action/put together. We might also want to have a "lightning" hour with lots of quick Demos of applications running on a completely free stack (5 - 10 minutes per demo). - Sunday from 09:00 to 12:30 - "Developer talks" presentations of things that are in progress and that people want to explain in more depth to get developers of the other projects to join in a share the fun. - Sunday from 13:00 to 17:30 - "The Future" hard core interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. Arnaud Vandyck, Dalibor Topic, Mark Wielaard, Michael Koch and and Tom Tromey will be our "program committee" this year. If you would like to present something, have an idea for a demo or discussion topic please let us know at fosdem-at-developer.classpath.org Please mention the title, a little abstract, which track and whether you want to do a quick demo, a short 30 min talk or full hour talk (we prefer 30 minute talks to give everybody a chance to present something). Deadline for proposals is December 18, so you have a month to think of something cool. Then we make sure to have some kind of "formal program" at the start of January. Examples of presentations and reports from previous years: http://www.gnu.org/software/classpath/events/escape_fosdem05.html http://www.gnu.org/software/classpath/events/fosdem04.html Some ideas for interesting topics: - Free Swing - The Demo! - Your GNU/Linux distro and the free runtimes - package overview. - From 0 to 100 in 15 Minutes: Getting started with GNU Classpath development using Eclipse, JamVM, Mauve, and the ChangeLog plugin! - Integrating with Objectweb through native-(gcj)-JOnAS - Writing OpenOffice.org plugins using a free software stack. - Using GNU Classpath/gcj/kaffe for games - Using free runtimes on Wine and other win32 environments - Embedding GNU Classpath in web browsers and support for JNLP - Security Auditing! - 1.5 language support in GNU Classpath, gcjx and the free runtimes - GNU Classpath/OSGi/J2ME/Library splitting and trimming - Harmony through interfacing. - Beyond JAPI: what is needed to "really finish" GNU Classpath Or, "Beyond Java" -- what we can do when we finish 1.5. Or more generally some kind of presentation about development metrics: bug rates, rates of change in japi/lines of code/tests, email volume, stuff like that. - Debugging, JDWP development efforts. - etc. Hope to see you in Brussels on February 25 and 26 2006, Arnaud, Dalibor, Mark, Michael and Tom -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/

1 0

Re: [fedora-java] Thoughts on JPackage, Fedora Core, gcj, etc.
by HAWAT.THUFIR＠gmail.com 12 Nov '05

12 Nov '05

On Thu, 10 Nov 2005, Ian Pilcher wrote: .. > Certainly, adding them automatically should be a goal. Too painful to > think about, however? It looks like there are about 158 "Java" packages > in Fedora Core 4. Adding > > Provides: gcj(%{name}) = %{epoch}:%{version}-%{release} > > to each package hardly seems like a Herculean task. > > How does Jpackage compare to jikes? -Thufir

1 0

Followup: aot-compile-rpm, rebuild-gcj-db and rebuild-security-providers
by Thomas Fitzsimmons 11 Nov '05

11 Nov '05

Hi, Based on the discussions on this list as well as a phone discussion we just had, here are the plans for these scripts: aot-compile-rpm --------------- We're going to put the logic from this script upstream in the GCC repository. Gary is going to split it into a package-format agnostic "aot-compile" script and an RPM-specific fragment for gleaning settings from an RPM build environment. This location for the "natively compile a set of jars" logic has two advantages: aot-compile can be conveniently reused by other packaging systems (e.g. Debian, Gentoo) and the logic can be conveniently merged bit-by-bit into the gcj front-end itself where it belongs. One downside is the longer release cycle for the GCC RPM but this script is now in bug-fix mode so release frequency isn't as important. rebuild-gcj-db -------------- This script's logic will be moved into a gcj-dbtool --rebuild option. I'm going to suggest we break compatibility (technically) by not providing a replacement rebuild-gcj-db script for use by old RPMS, just in the interest of not maintaining an extra script indefinitely. We haven't decided yet who will do this work; Andrew Haley? rebuild-security-providers -------------------------- I'm going to remove this script from jpackage-utils. I agree with David Walluck's argument that there aren't enough security provider RPMs available to warrant an extra script (and divergence from upstream jpackage-utils). Until Jesse and GNU Crypto are merged into GNU Classpath I'll simply in- line the logic in rebuild-security-providers in those packages. I'm hoping to have them merged before Fedora Core 5 anyway. Tom

2 2

Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat
by Thomas Fitzsimmons 11 Nov '05

11 Nov '05

Hi, Making aot-compile-rpm and rebuild-gcj-db alternatives symlinks was obviously a mistake, but I think putting them in java-gcj-compat at all is also a mistake. I'm currently looking for other places to move them. A comment in aot-compile-rpm raises the possibility of including this script in RPM itself. Gary, do you think this is feasible in the FC5 time frame? I also propose removing rebuild-gcj-db and instead adding a --rebuild argument to gcj-dbtool that implements the current Fedora Core database management policy (which seems to work). Andrew and Tom, thoughts? The last gcj-specific script in our JPackage stack is rebuild-security-providers. I'd also like to get rid of it, but I'd like to know what others think first. I added rebuild-security-providers so that java security provider RPMs could easily make GCJ aware of the new provider. Ideally, JPackage would provide a JVM-neutral mechanism for this, but it seems like it would be a lot of work (i.e. you'd likely need to partition the available providers based on JVM vendor and version -- a global java.security file likely wouldn't work). Do people think it's worth having a gcj-specific script in jpackage-utils to make gcj aware of new security provider RPMs? Do the JPackage people reading this list know of a better, more general solution? (I'm not even sure it's worth worrying about this, since (the few existing) security provider packages could easily manually add/remove themselves to/from whichever java.security file they care about). Anyway, I was considering creating an intermediate java-gcj-compat-scripts package to handle these scripts but looking through them, I think it's better to get rid of them during the push to FC5. Doing so will solve the "missing rebuild-gcj-db" failures. Comments welcome, Tom

5 16

external references to JPackage Bugzilla
by Thomas Fitzsimmons 10 Nov '05

10 Nov '05

Hi, I had Dave Lawrence add jpackage.org/bugzilla to our "External Bugzillas" list. Here's an example of its use: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160327 Tom

1 0

Thoughts on JPackage, Fedora Core, gcj, etc.
by Ian Pilcher 10 Nov '05

10 Nov '05

Something that's been bouncing around in my head for awhile now... What do folks think of adding an additional "provides" to packages that provide gcj libraries. The Fedora Core version of tomcat5, for example, could provide "tomcat5(gcj)" or "gcj(tomcat5)", presumably versioned. This wouldn't do anything by itself, but it would give higher level tools, such as yum, the information needed to apply the policies set by system administrators -- prefering the latest version, prefering gcj versions, etc. Thoughts? -- ======================================================================== Ian Pilcher i.pilcher(a)comcast.net ========================================================================

3 3

RE: fedora-devel-java-list Digest, Vol 10, Issue 4
by Dan Thurman 09 Nov '05

09 Nov '05

>From: fedora-devel-java-list-bounces(a)redhat.com >[mailto:fedora-devel-java-list-bounces@redhat.com]On Behalf Of >fedora-devel-java-list-request(a)redhat.com >Sent: Wednesday, November 09, 2005 9:01 AM >To: fedora-devel-java-list(a)redhat.com >Subject: fedora-devel-java-list Digest, Vol 10, Issue 4 > > >Send fedora-devel-java-list mailing list submissions to > fedora-devel-java-list(a)redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list >or, via email, send a message with subject or body 'help' to > fedora-devel-java-list-request(a)redhat.com > >You can reach the person managing the list at > fedora-devel-java-list-owner(a)redhat.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of fedora-devel-java-list digest..." > > >Today's Topics: > > 1. Using Yum Updates with Jpackage.org repos (Daniel B. Thurman) > 2. Re: Using Yum Updates with Jpackage.org repos (Gary Benson) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 8 Nov 2005 18:04:55 -0800 >From: "Daniel B. Thurman" <dant(a)cdkkt.com> >Subject: [fedora-java] Using Yum Updates with Jpackage.org repos >To: "Fedora Java Development List $E-mail$" > <fedora-devel-java-list(a)redhat.com> >Message-ID: <BD6B49853F5EAB47A824B8A07B13CC1B378B(a)cdkkt.com> >Content-Type: text/plain; charset="iso-8859-1" > > >Hi Folks, > >Got a problem. I stumbled onto this group (jpackage.org) when >I wanted to install the JDK 5.0 on FC4 and in order to do that, >part of the instructions was to install the jpackage repos for Yum. > >I was able to install the JDK 5.0 on FC4. Great! > >But unfortunately, I was not able to use yum update because there >is a dependency conflict regarding jms and this prevents me from >updating FC4 as well. So I am forced to move the jpackage repos >aside until this issue is resolved. > >Here is the yum update output: > >--> Running transaction check >--> Processing Dependency: jms for package: avalon-logkit >--> Finished Dependency Resolution >Error: Missing Dependency: jms is needed by package avalon-logkit > >Can anyone help? > >Thanks, >Dan Thurman > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.1.362 / Virus Database: 267.12.8/162 - Release >Date: 11/5/2005 > > > > >------------------------------ > >Message: 2 >Date: Wed, 9 Nov 2005 09:22:33 +0000 >From: Gary Benson <gbenson(a)redhat.com> >Subject: Re: [fedora-java] Using Yum Updates with Jpackage.org repos >To: "Fedora Java Development List (E-mail)" > <fedora-devel-java-list(a)redhat.com> >Message-ID: <20051109092230.GB5181(a)redhat.com> >Content-Type: text/plain; charset=us-ascii > >Daniel B. Thurman wrote: >> Hi Folks, >> >> Got a problem. I stumbled onto this group (jpackage.org) when I >> wanted to install the JDK 5.0 on FC4 and in order to do that, part >> of the instructions was to install the jpackage repos for Yum. >> >> I was able to install the JDK 5.0 on FC4. Great! >> >> But unfortunately, I was not able to use yum update because there >> is a dependency conflict regarding jms and this prevents me from >> updating FC4 as well. So I am forced to move the jpackage repos >> aside until this issue is resolved. >> >> Here is the yum update output: >> >> --> Running transaction check >> --> Processing Dependency: jms for package: avalon-logkit >> --> Finished Dependency Resolution >> Error: Missing Dependency: jms is needed by package avalon-logkit >> >> Can anyone help? > >Downloading and installing geronimo-specs and geronimo-specs-compat >from rawhide should solve this. Option B would be to build and >install the jms package from JPackage. > >Cheers, >Gary > > Um, forgive me if I am dense, but can you give me some install instructions? I have no idea where "rawhide" is nor where to begin. I tried: yum install geronimo-specs and the jpackage repos are in the yum directory but it was not found. Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/163 - Release Date: 11/8/2005

1 0

Using Yum Updates with Jpackage.org repos
by Dan Thurman 09 Nov '05

09 Nov '05

Hi Folks, Got a problem. I stumbled onto this group (jpackage.org) when I wanted to install the JDK 5.0 on FC4 and in order to do that, part of the instructions was to install the jpackage repos for Yum. I was able to install the JDK 5.0 on FC4. Great! But unfortunately, I was not able to use yum update because there is a dependency conflict regarding jms and this prevents me from updating FC4 as well. So I am forced to move the jpackage repos aside until this issue is resolved. Here is the yum update output: --> Running transaction check --> Processing Dependency: jms for package: avalon-logkit --> Finished Dependency Resolution Error: Missing Dependency: jms is needed by package avalon-logkit Can anyone help? Thanks, Dan Thurman -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 11/5/2005

2 1

updating from ant-1.6.5-2fc to ant-1.6.5-0jpp_1fc
by Vadim Nasardinov 04 Nov '05

04 Nov '05

I recently changed the Ant RPM's Release header from 2fc to 0jpp_1fc in rawhide: https://www.redhat.com/archives/fedora-cvs-commits/2005-November/msg00159.h… Thus, the Ant RPM went through the following three consecutive versions in rawhide: ant-1.6.2-3jpp_14fc ant-1.6.5-2fc ant-1.6.5-0jpp_1fc If you had already updated your rawhide box from ant-1.6.2-3jpp_14fc to ant-1.6.5-2fc, you won't be able to yum update it to ant-1.6.5-0jpp_1fc, because 0jpp_1fc is less than 2fc as far as rpm is concerned. Functionally, there are currently no differences between these two releases. The reason I had to change the release number was to make it possible to resync Fedora's Ant with the future ant-1.6.5-1jpp RPM from JPackage. To undo my screwup, you may have to run the attached script. I apologize for the inconvience. Vadim

1 0

Announce: MKSearch beta 1, done with GCJ
by Phil Shaw 03 Nov '05

03 Nov '05

I have mostly been lurking on these lists over the past year and I have learned a lot from the posts, so thanks very much to the free Java contributors for your part in the MKSearch project. A formal announcement follows, but I thought members of these lists (Mark Wielaard especially) may also be interested in some screen shots of our beta search engine running on Fedora Core 4 with Tomcat 5 in Firefox. https://svn.mkdoc.com/mksearch/doc/design/screenshots/ Best regards, Phil Shaw MKSearch beta 1 release announcement MKDoc Ltd. would like to announce the first beta release of MKSearch, under the GNU General Public Licence. Source and pre-compiled binary downloads are available from the project Web site. http://www.mksearch.mkdoc.org/downloads/ MKSearch is a metadata search engine that indexes structured metadata in Web documents, not free text in the document body. The data acquisition system: * Conforms to the Dublin Core metadata in HTML recommendations [1] * Supports other application profiles, such as the UK e-Government Metadata Standard [2] * Indexes native RDF formats, including RSS 1.0 The MKSearch system has five major components: 1. A Web crawler based on JSpider [3] * Multi-threaded processing * Per-site throttle, user agent, depth and linking rules * Respects the robots.txt exclusion policy * Extensible plug-in based content handling 2. An HTML document validator and formatter based on JTidy [4] * Cleans-up and corrects HTML syntax errors * Converts HTML to XHTML 3. A set of custom indexers based on the Simple API for XML (SAX) * Extracts metadata from HTML meta and link elements * Converts metadata to RDF triple statements * Configurable application profiles 4. An RDF storage and query system based on Sesame [5] * XML/RDF file-based storage * Database storage using PostgreSQL or MySQL * Sophisticated Sesame RDF Query Language (SeRQL) queries * Scope for more semantically rich queries with inferencing 5. A public query interface, provided through a standard servlet container * Simple, expandable query builder form * Configurable application profile-based presentation * Wildcard query handling * Phrase searches * Paged HTML results * Standing RSS results The two main elements of the MKSearch system can be used independently. The data acquisition system can be used to gather large quantities of metadata from the Web and store it as RDF. The query system can be used to provide a typical search engine-style interface to existing RDF content. The MKSearch beta 1 distribution includes sample configurations that crawl a Web site and create: * A mirror of the site on the local file system in valid XHTML * An RDF N-Triple record for each page on the local file system * UK e-Government metadata in a Sesame file-based repository (XML/RDF) This distribution also includes a demonstration of the MKSearch query interface, in the form of a Web Application Archive (WAR) that can be deployed directly to an existing servlet container. The sample search content is from an index of the MKSearch project Web site on 2 November 2005. See the site documentation below: http://www.mksearch.mkdoc.org/documentation/tomcat-on-fc4/ http://www.mksearch.mkdoc.org/howto/ http://www.mksearch.mkdoc.org/plans/beta-1-release- tasks/mksearch-beta-1-release-notes/ System requirements and licence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MKSearch is written in the Java programming language and is designed to run on any platform that supports a Java environment equivalent to the Sun Java 2 language specification. The system has specifically been designed, developed and tested to run on GNU/Linux systems using the GNU Compiler for Java (GCJ) [6] and Apache Tomcat 5 servlet container, as available on Fedora Core 4 [7]. This provision means that MKSearch can be built and run on software systems that are entirely open source and free from proprietary licencing. The system has been tested extensively using the Sun Java SDK 1.5 on Microsoft Windows 2000. JUnit test suites for the MKSearch code base cover 99% of all code branches. If you have any comments or questions about the MKSearch system, please join us on the project mailing list. http://www.email-lists.org/mailman/listinfo/mksearch-dev References ~~~~~~~~~~ [1] http://dublincore.org/documents/2003/11/30/dcq-html/ [2] http://www.govtalk.gov.uk/schemasstandards/metadata_document. asp?docnum=805 [3] http://j-spider.sourceforge.net/ [4] http://jtidy.sourceforge.net/ [5] http://www.openrdf.org/ [6] http://gcc.gnu.org/java/ [7] http://fedora.redhat.com/ -- MKSearch (beta) http://www.mksearch.mkdoc.org/ Free, open source metadata search engine with RDF storage and query.

1 0

Re: Fedora Core 4 Test Update: eclipse-3.1.1-1jpp_1fc.FC4.4
by Andrew Overholt 01 Nov '05

01 Nov '05

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel November 2005