Re: [fedora-java] Thoughts on JPackage, Fedora Core, gcj, etc.
by HAWAT.THUFIR＠gmail.com
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
18 years, 5 months
Followup: aot-compile-rpm, rebuild-gcj-db and rebuild-security-providers
by Thomas Fitzsimmons
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
18 years, 5 months
Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat
by Thomas Fitzsimmons
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
18 years, 5 months
Thoughts on JPackage, Fedora Core, gcj, etc.
by Ian Pilcher
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
========================================================================
18 years, 5 months
RE: fedora-devel-java-list Digest, Vol 10, Issue 4
by Dan Thurman
>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
18 years, 5 months
Using Yum Updates with Jpackage.org repos
by Dan Thurman
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
18 years, 5 months
updating from ant-1.6.5-2fc to ant-1.6.5-0jpp_1fc
by Vadim Nasardinov
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...
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
18 years, 5 months
Announce: MKSearch beta 1, done with GCJ
by Phil Shaw
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.
18 years, 5 months
