I'm in the process of coming up with a package naming policy for our
internal use hence I've been reading these kinds of things:
I've come up with a plan for dealing with FC, Extras and RPMforge and
the like, but then I started thinking about JPackage. I have some questions:
Q1. What are Fedora planning to do in relation to release tag naming and
At the moment Rawhide is using <jpp version>jpp_<fc version>(fc|rh).
This seems a little at odds with the draft Fedora naming guidelines (I
know they've only just been written in draft :-)).
The motivation for this question is to do with our desire to ship local
modifications to jpp packages and still have a sensible upgrade path. Up
to now I've been able to simply tack on a suffix to the jpp version. If
however another upstream repo (FC) is also using the suffix approach
then things start to get interesting :-) (1jpp_3fc vs 1jpp.1.local)
Q2. Are Fedora going to feed packages upstream as a priority then tweak
them for their local purposes afterwards? Another way of asking this is
- will FC Java packages that could also end up in JPackage always going
to have a Xjpp prefix in the release tag? If not then things like this
javafoo-1.2.3-1 (RH put this in fc)
javafoo-1.2.3-1jpp (pushed upstream)
.. then RH want to update javafoo:
Actually this works, but I guess it would be nice to define it.
I have some ideas on this (dropping the underscores for one) but thought
I'd ask first :-)
I just experimented with creating a noarch RPM for libgcj HTML javadoc.
It uses gjdoc to generate HTML from the src.zip rawhide libgcj installs.
I don't know if this is the best way to go about it, but it was
I've placed the SRPM here for comment:
The RPM itself is 16MB, and it seems I'm out of space on
Comments and suggestions welcome....
Some exciting new stuff has landed in rawhide over the past few days:
eclipse-bugzilla, eclipse-changelog, and eclipse-pydev! If you don't have
it already, try something like this:
yum --enablerepo=development install \
eclipse-changelog is a plugin written by Phil Muldoon to write ChangeLog
entries from within Eclipse. This started off as one of those "scratching
an itch" projects that has grown into something incredibly useful. Phil's
doing all his development out of CVS at sources.redhat.com. Jeff Pound was
kind enough to grace the world with his HTML wizardry (it's better than I
could have done :) and has put some instructions and information here:
eclipse-bugzilla is a plugin to interact with Bugzilla systems (duh). It
was started by IBM and is now being developed by Jeff Pound here at Red
Hat. It's a really great plugin and everyone has lots of cool plans for
it. There's still lots of cool additions and integration with other
plugins (like the ChangeLog plugin, for example) that could be done, so
check it out from CVS (see URL above for instructions) and send Jeff
patches and/or ideas.
I've put some screenshots of the ChangeLog and Bugzilla plugins (and this
eclipse-pydev is the PyDev plugin (http://pydev.sourceforge.net/) packaged
up. I haven't had much time to play with it myself, but it looks great and
I know some python developers out there are excited to get started with it.
As usual, if you find bugs, please file them in RH bugzilla under Product:
Fedora Core, Version: devel, Component: eclipse.
In other news, Michael Koch has started an effort to close the gap between
Eclipse and projects that use the autotools. He's calling it antiauto and
you can check it out here:
We've talked about doing an autotools plugin for a long time, but this
fills the gap nicely in the meantime.
I'm a developer at Lime Wire LLC (the gnutella p2p client) and an avid
Fedora fan. Although our product uses Swing heavily and hence won't be
able to run on a free jvm anytime soon, I'm greatly interrested in
helping liberate as much of java as possible.
I'm specifically interrested in the gcj port of Eclipse and will most
likely be contribute to that by testing and whatnot.
java-gcj-compat's javac currently ignores the extensions directory (as
we've both discovered). The Eclipse compiler doesn't have an
extensions directory option either, so we have to expand it manually.
This is similar to what Eclipse's JDTCompilerAdapter class does for ant.
Here's another SRPM for FC consideration....
This package Provides "jta", which is one of the nosrc RPMS in jpackage
that many other things depend on.
libgcj (and GNU Classpath) already include all of the classes and
interfaces found in jta, but not as a separate .jar file. The separate
jar file is important because packages depending on jta usually run
"build-classpath jta" to find the jta jar file.
The SRPM actually contains no source code. It simply extracts the
javax.transaction classes from libgcj-4.0.0.jar and zips them up into
libgcj-jta-4.0.0.jar (with a symlink to jta.jar). We create a simple
noarch RPM since gij will use the native versions in libgcj anyway.
This package should satisfy the needs of all jta users (even for non-gcj
Could somebody please review the spec file and slip it into FC? tomcat5
depends on it, among other things.
Get all the software you ever imagined for wholesale prices!
Our software is 2-10 times cheaper than sold by our competitors.
Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10
All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... To view full list of products go:
To change your mail preferences, go: http://www.softuniverse.biz/uns.htm
Some of you are familiar with limits of applets. Web start (JNLP) allows
for a more of a rich user interface then what we can do w/ Applets and
DHTML. But deploying Java, applets and applications over the internet
can be a challenge, including security warnings for registered
applications and installation of current version of java by non-computer
savvy users of our applications (can your father in law install and
launch a WebStart application?)
The lead of Sun’s Java deployment team and usability experts (Mike
Albers -J2SE UI expert will be there hopefully) will answer your
questions at 11 AM California time and guide you. Here are the details
of how to participate for FREE:
Above link should be enough.
Some people are *boycotting* the chat conference because of issues since
about 2001(it appears that a individuals at Sun believe that they should
PERVENT deployment – that they are doing us a favor, listed here:
One important issue was picked up here (Scary screen for registered
Sun’s stance is that it’s RFE and will not address it with wide
deployment of Java 6 (aka Mustang) in 2007, and not on JRE 1.4.x
updates, and will not do word smiting to clarify the application is
Another issue is deploying/update Java by corporate end users at
organizations that have a LAN admin.
Sample “applets” sites:
One example of RiA is (click to run it)
MacroMedia and MS Longhorn also have RiA kits, you can read this as
intro to RiA:
RiA will be major part of SoA – Services.
Server side Java will be limited w/o Client Side Java.
You want to hear deployment answers from Sun people in charge? OK, tmrw.
11AM CA time (2PM? NY time)