Another weird jpackage/Fedora thing
by Mary Ellen Foster
With the most recent update to Eclipse, I again had the following
sequence. Before this whole process, I had tomcat5-5.5.20-5jpp from
JPackage installed. (NB: I don't actually *use* tomcat, but other
stuff pulls it in)
I attempted "yum update". The dependency-checking output included:
--> Processing Dependency: tomcat5 >= 5.5.17 for package: eclipse-platform
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for tomcat5 to pack into transaction set.
tomcat5-5.5.17-6jpp.2.i38 100% |=========================| 24 kB 00:00
---> Package tomcat5.i386 0:5.5.17-6jpp.2 set to be updated
And the proposed set of resolved dependencies included:
Installing for dependencies:
tomcat5 i386 5.5.17-6jpp.2 core 318 k
After I hit "Y" and all of the packages downloaded, I got:
Transaction Check Error: package tomcat5-5.5.20-5jpp (which is newer
than tomcat5-5.5.17-6jpp.2) is already installed
Well, yes, that's true. But it shouldn't even have tried to install
the older one, should it? The dependency is on ">= 5.5.17" ...
Anyway, to solve this, I did "rpm -e --nodeps tomcat5" and then the
yum update, which correctly downloaded installed tomcat5-5.5.17-6jpp.2
from Core as part of its dependency solving.
Then, when I did a second "yum update", it happily updated me to
tomcat5-5.5.20-5jpp from jpackage again.
So Eclipse and JPackage tomcat seem to be able to coexist happily (at
least at the dependency level) as long as tomcat is updated after
Eclipse. But somehow every time I try to do an update, yum wants to
install the older tomcat again even though it's already got a newer
one it appears to be happy with.
Is this something to do with the fact that the core package is i386
and the JPP one is noarch? Or something else? It seems to be a
yum-level problem, probably, but I just wanted to see if anyone else
had insights.
Thanks!
MEF
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
16 years, 3 months
gnuxml -> xerces/xalan?
by Andrew Overholt
Hi,
From my perspective, a large percentage of our libgcj issues are
xml-related. Is there any way we could put xerces and/or xalan (or
whatever) in the endorsed dir and make those our default for F7?
Andrew
16 years, 3 months
eclipse-cdt-3.1.2 with Autotools 0.0.8 support available
by Jeff Johnston
This is to announce that version 3.1.2 of the Eclipse CDT is now
available for Fedora. The RPMs also contain the latest Autotools plugin
release, 0.0.8.
The Autotools 0.0.8 plug-in has been updated from 0.0.7 to contain an
improved Autoconf editor including outline support and rudimentary
syntax parsing. As this project is under heavy development, we would
greatly appreciate any testing and feedback.
For FC6, the RPMs can be installed from the updates-testing repo. For
F7, the RPMs can be installed from Rawhide.
Any bugs should be submitted to bugzilla.redhat.com for Fedora Core
under component eclipse-cdt.
16 years, 3 months
java specfile reviewfest
by Andrew Overholt
Hi,
Some of us have decided to get together on Monday 12 February to grind
through reviews for both the new packages required for maven2 and those
for the existing core packages.
It'd be great if people could help out with this. We hang out on
#fedora-java on Freenode and will make a point of being there on Monday
all day.
Those of us meeting in the flesh are in EST but I hope that doesn't stop
others in different timezones from participating.
Deepak: can you send out some URLs to the review requests. Potentially
also that list we came up with for order of review?
Thanks,
Andrew
16 years, 3 months
Java APIs for image thumbnail generation
by Joe Desbonnet
Probably a little OT as it's not a Fedora specific question, but this
spills into the JNI area so I though I'd bounce this question of
Fedora Java developers.
Some of my Java server side apps feature image databases and there is
a need to generate thumbnails for the images. Up to now I've been
using the JAI (Java Advanced Imaging) API, but I was never happy with
the results. The ImageMagick "convert" utility always produced much
better results. After Googleing this topic I've come to the
conclusion that despite all the image manipulation APIs in the Java
standard, there is no way to produce a thumbnail of the same quality
as a "convert -geometry 100x100" command. (Am I right in saying
this?).
So I've given up on a pure Java solution and I'm currently forking a
process running convert for thumbnail generation. Apart from
generating superior quality thumbnails, it also seems to be a more
memory-friendly solution. I've also looked at the JMagick JNI wrapper
for ImageMagic, but the simple fork technique has worked well so far
so I'm not sure if there is any huge advantage to using the JNI path
to ImageMagick.
My question is: does anyone have a better solution for thumbnail
generation? A platform neutral solution would be best, but I'm willing
to assume a Linux server failing that. The Java VM must be in headless
mode however as it's running on a server.
Thanks,
Joe.
16 years, 3 months
F7 plan (gcj/java/eclipse/swt/java-gnome/fop/batik/etc)
by Mark Wielaard
Hi,
I saw the following thread about F7 plans and noticed we don't have any
goals for gcj/eclipse/swt/java-gnome/etc
http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/1551
So here are some ideas, deadlines and dependencies that might be nice to
look at for F7 for the various stacks that make up the fedora-devel-java
world. Please reply if you are working on any of this, if I am saying
something silly/wrong or if there are more stack/application issues that
you think are important for F7.
The "important dates" are:
- January 23 - Test1 Development Freeze
- February 20 - Test2 Development Freeze
- March 15 - Test3 Development Freeze
- Release in April
Test2 is just before Fosdem. And since all features should be in by
then, it would be nice to try and create a liveCD with all "our
features" on it to show off at Fosdem (Feb 24/25, Brussel, Belgium).
- 1.5 language & library support in gcj
This seems to be the biggest and most intrusive upgrade. But starting
this early seems like a very good idea. Upstream is cleaning up some
last issues. And it needs lots of testing. Would be good if something
can be cooked up for Test1. Needs help from gcc-toolchain people.
- Separate libgcj-rpm. Would be really nice so we can update the core
class libraries separate from the core gcc compilers. Should also help
with updates/dependencies since libgcj provides the mozilla plugin now
and the awt libraries depend on gtk+. Would be nice if this can be
done before Test2 so we can test an upgrade. Again needs help from
gcc-toolchain people.
- java-gcj-compat
The biggest issue with this, if the 1.5-stack goes through is that
gjdoc isn't 1.5 safe. If we cannot easily update gjdoc, then maybe
sinjdoc could be investigated as replacement.
http://www.cag.lcs.mit.edu/~cananian/Projects/GJ/#sinjdoc
(Do we also need updates for javap and javah replacements?)
- eclipse/swt/rcp stack
3.2 seems already good to go, and 3.3 will not come out till the
middle of 2007. Azureus, RSSOwl also already seem updated.
Andrew Overholt already has written down some plans for the future:
http://overholt.ca/wp/?p=76
Maybe some work can be done to support the JDWP work in libgcj to
get a little debugging going? And it would be nice to make sure that
the ecj from eclipse and that from the gcj 1.5-stack match up.
- java-gnome
There are some rumors about a upgrade/rewrite, but nothing concrete as
far as I have seen. If there is a rewrite that might cause some extra
work for applications like Frysk.
- gcj-compiled DocBook toolchain
It seems we have made lots of progress with FOP and Batik since the
last discussion about this:
http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582
Does anybody know where we are with that at this time?
Would be nice to coordinate with the fedora-docs-list if we can
provide something.
- jpackage. Does it make sense to upgrade all packages to jpp 1.7 if the
1.5-stack goes in?
- OpenOffice 2.2
Listed here since it does have some parts written in java. 2.2 comes
out end of February. Probably needs retesting with the gcj-stack. I
don't know if there are new java language/library dependencies.
Some things that would be nice, but that are probably a lot of work,
maybe better left for Fedora *, unless someone volunteers of course! :)
- OpenJDK
Still lots missing. Hopefully at Fosdem we will learn a bit more about
the encumberments and when which parts of the core libraries will be
liberated fully. But it might be nice to see if javac could be
packaged. Or maybe a brave soul make hotspot work with classpath?
- PhoneME/CACAO/MIDPath/J2MEPolish
The Micro Edition world seems to really have gotten a boost from the
GPL release of PhoneME. A lot of this is pretty early access. But it
would be nice to have parts of this supported to show that Fedora is
also a nice platform to developer for java-based mobile devices.
- JBoss application server, SEAM stack
Not tried yet. Parts like tomcat are already packaged. If we can get
the 1.5-stack going it makes sense to look at this a bit closer. Maybe
other parts can be lifted from jpackage?
- Netbeans
I tried this recently, but it seems still very tight to the Sun java
implementation and I was unable to fully start it up on the free
stack. But some dependencies like JavaHelp have been liberated
(gpl+exception) now (and entered jpackage recently). Also it isn't
clear whether the current license (CDDL) is acceptable (it seems
unacceptable to Debian).
- JOGL and WW2D should work, but I haven't done any testing recently.
- japitools should really be packaged and somehow be tied in with the
build system so developers/packagers can get an easy overview of
whether or not a library upgrade is binary compatible or not.
I am sure there is a lot missing. And as you saw none of the items above
have real deadlines or people responsible, etc. So please feel free to
reply with corrections add those yourself :)
Cheers,
Mark
16 years, 4 months
Why does eclipse now require lucene-devel?
by Mary Ellen Foster
Just curious why the latest eclipse-platform in FC6 update-testing
requires lucene-devel in addition to lucene? When I tried to update
this morning, I got hit by the fact that lucene is 1.9.1 in jpackage
and 1.4.3 in Fedora, and jpackage doesn't have a separate -devel
subpackage; had to force-downgrade and exclude lucene from jpackage to
make this work.
I've bugzilla'd the out-of-date lucene in Fedora:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228141
I know next to nothing about lucene except that it's a dependency of
Eclipse, but I'm just curious what the changes were. No biggie.
MEF
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
16 years, 4 months
Re: [fedora-java] Why does eclipse now require lucene-devel?
by Andrew Overholt
* Ismael Juma <ismael(a)juma.me.uk> [2007-02-10 08:22]:
> Hi,
>
> On Sat, 2007-02-10 at 08:07 -0500, Andrew Overholt wrote:
> [...]
> > We'll have to make sure the new version works with Eclipse. ISTR it not
> > compiling against it but I guess we should investigate. Upstream is
> > reluctant to move their dependencies forward like this.
>
> According to this bug[1], eclipse 3.3 will depend on lucene 1.9.1. They
> can't use lucene 2.0 (or the soon to be released 2.1) because they rely
> on deprecated APIs that were removed from 2.x.
Cool, thanks for letting us know. Perhaps we should look at helping
them move forward. Otherwise, we'll have to have 1.9.1 in F8.
Andrew
16 years, 4 months
