default vm memory settings for fedora eclipse
by Benjamin Konrath
Hi,
Now that Eclipse requires IcedTea by deault on x86 and x86_64 I'd like
to change the default vm memory settings to be something a little more
sane. Right now the -vmargs option is set to "-Xms40m -Xmx256m". What
should I change it to?
Thanks, Ben
16 years, 2 months
icedtea +fedora 7 x64 build error
by Justin Conover
PLUG IMPORT: sun/dc/pr/Rasterizer$ConsumerDisposer.class
PLUG IMPORT: sun/dc/pr/Rasterizer.class
(cd
/home/justin/Download/icedtea/openjdk-ecj/control/build/linux-amd64/classes
&& /home/justin/Download/icedtea/bootstrap/jdk1.6.0/bin/jar xf
/home/justin/Download/icedtea/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar`/bin/cat
/home/justin/Download/icedtea/openjdk-ecj/control/build/linux-amd64/tmp/java/plugs/dc.clist`)
/bin/mkdir -p
/home/justin/Download/icedtea/openjdk-ecj/control/build/linux-amd64/classes
PLUG IMPORT: gnu
(cd
/home/justin/Download/icedtea/openjdk-ecj/control/build/linux-amd64/classes
&& /home/justin/Download/icedtea/bootstrap/jdk1.6.0/bin/jar xf
/home/justin/Download/icedtea/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar`/bin/cat
/home/justin/Download/icedtea/openjdk-ecj/control/build/linux-amd64/tmp/java/plugs/gnu.clist`)
BinaryPlugs import completed: Mon Sep 24 20:05:42 CDT 2007
make[5]: *** No rule to make target
`/NOT-SET/BUILD_JDK_IMPORT_PATH/linux-amd64/jre/lib/amd64/server/libjvm.so',
needed by
`/home/justin/Download/icedtea/openjdk-ecj/control/build/linux-amd64/lib/amd64/server/libjvm.so'.
Stop.
make[5]: Leaving directory
`/home/justin/Download/icedtea/openjdk-ecj/j2se/make/java/redist'
make[4]: *** [all] Error 1
make[4]: Leaving directory
`/home/justin/Download/icedtea/openjdk-ecj/j2se/make/java'
make[3]: *** [all] Error 1
make[3]: Leaving directory
`/home/justin/Download/icedtea/openjdk-ecj/j2se/make'
make[2]: *** [j2se-build] Error 2
make[2]: Leaving directory
`/home/justin/Download/icedtea/openjdk-ecj/control/make'
make[1]: *** [j2se_only] Error 2
make[1]: Leaving directory
`/home/justin/Download/icedtea/openjdk-ecj/control/make'
make: *** [stamps/icedtea-ecj.stamp] Error 2
16 years, 2 months
Review request: Eclipse Demonstration Screencasts
by Andrew Overholt
Hi,
As part of the Devel SIG initiative, we've been making some .ogg
screencasts of various Eclipse operations. We hope to introduce people
to Eclipse technology available in Fedora and -- over time -- hope to
build up content to ease in new developers.
I've put up a package for review with our initial set of .oggs. I'd
like to include it in the test3 Developer Live image so if someone could
get to it today, I'd really appreciate it :)
https://bugzilla.redhat.com/show_bug.cgi?id=304861
Thanks,
Andrew
16 years, 2 months
java.home/java.library.path etc, what can I rely on ?
by Caolán McNamara
So, for..
class findhome
{
public static void main(String args[])
{
System.out.println(System.getProperty("java.home"));
System.out.println(System.getProperty("gnu.classpath.home.url"));
System.out.println(System.getProperty("java.library.path"));
}
}
javac findhome.java
java findhome
I have (on x86_64) ...
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
file:///usr/lib64
/usr/lib64/gcj-4.1.2
For something like OOo we have two sort of requirements,
at run time we'd like to dlopen libjvm.so, currently the approach I took for gcj
was to stick lib/ARCH/client/libjvm.so onto the value of java.home. I guess from the
output here searching through java.library.path is also plausible ?
The other requirement is at buildtime to link against libjawt.so and to find the
java headers.
but for e.g. suse right now apparently the output of the above (for i386) is..
/usr
file:///usr/lib/gcc/i586-suse-linux/4.2.1
/usr/lib/gcj-4.2.1
So what I'm wondering is if there is a canonical reference to what the various
properties should refer to. i.e. are my assumptions just busted, or is e.g. the
suse gcj misconfigured and if there is more correct way to find libjvm.so. And
while I'm at it is there a good solid cross platform and cross java-impl test
to find the correct include and link path to build against the java headers and
link to libjawt and friends.
C.
16 years, 2 months
Re: [fedora-java] Re: icedtea-plugin rocks!
by Thomas Fitzsimmons
Jesse Keating wrote:
> On Mon, 24 Sep 2007 14:17:52 -0400
> Thomas Fitzsimmons <fitzsim(a)redhat.com> wrote:
>
>> I didn't think IcedTea was suitable for inclusion in comps because I
>> didn't know the compose tools failed gracefully on exclusive-arch
>> packages. OK to commit this patch?
>
> Fine by me.
Committed.
Tom
16 years, 2 months
Re: [fedora-java] Re: icedtea-plugin rocks!
by Thomas Fitzsimmons
Jesse Keating wrote:
> On Mon, 24 Sep 2007 13:56:05 -0400
> Thomas Fitzsimmons <fitzsim(a)redhat.com> wrote:
>
>> This was for gcjwebplugin-on-libgcj. The "icedtea-plugin rocks!"
>> thread is referring to gcjwebplugin-on-IcedTea which is
>> (audit-pending) much more secure. To make gcjwebplugin-on-IcedTea
>> installed and enabled by default as the original poster is proposing,
>> we'd need to have IcedTea available in comps.xml. It's too soon to
>> replace GCJ with IcedTea, because of the architecture coverage
>> issues, but does anyone see a problem with including IcedTea
>> alongside GCJ in the default comps.xml? That would mean that IcedTea
>> and GCJ would be installed by default, and IcedTea would take
>> precedence on architectures where it was available, and GCJ would be
>> the fallback, selectable using alternatives. Then the IcedTea plugin
>> would be installed by default on architectures where it is
>> available. I like this approach because there is demand for IcedTea
>> to be included by default.
>
> I thought this is what was going to be done anyway, that's the Feature
> configuration I voted for.
I didn't think IcedTea was suitable for inclusion in comps because I didn't know
the compose tools failed gracefully on exclusive-arch packages. OK to commit
this patch?
Tom
16 years, 2 months
Re: icedtea-plugin rocks!
by Andrew Overholt
* Rahul Sundaram <sundaram(a)fedoraproject.org> [2007-09-22 11:14]:
> Justin Conover wrote:
>> Thanks for all you work, nice to have a java plugin for x64 browsers now!
>> A great added feature, not sure if it will be a hidden feature or talked
>> about. Any chance of it being installed by default, so new users don't
>> have to think about java and can just be surprised?
>> http://justinconover.com/images/icedtea-plugin_x64.jpg
>
> That was agreed upon here
>
> https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00346....
>
> Jesse Keating, can you make sure we do this before the next test release?
I'm pretty sure it can't be done because IcedTea isn't on ppc{,64} and
we can't have arch-specific comps.xml.
Andrew
16 years, 2 months
Re: icedtea-plugin rocks!
by Neal Becker
Rahul Sundaram wrote:
> Andrew Overholt wrote:
>> * Rahul Sundaram <sundaram(a)fedoraproject.org> [2007-09-22 11:14]:
>>> Justin Conover wrote:
>>>> Thanks for all you work, nice to have a java plugin for x64 browsers
>>>> now! A great added feature, not sure if it will be a hidden feature or
>>>> talked
>>>> about. Any chance of it being installed by default, so new users don't
>>>> have to think about java and can just be surprised?
>>>> http://justinconover.com/images/icedtea-plugin_x64.jpg
>>> That was agreed upon here
>>>
>>> https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00346....
>>>
>>> Jesse Keating, can you make sure we do this before the next test
>>> release?
>>
>> I'm pretty sure it can't be done because IcedTea isn't on ppc{,64} and
>> we can't have arch-specific comps.xml.
>
> I would like to see Iced Tea by default. Don't particularly care about
> the mechanism.
>
> Rahul
>
Can java-icedtea.i386 be installed in parallel to java-icedtea.x86_64?
16 years, 2 months
Eclipse update manager woes
by Andrew Overholt
Hi,
I've been informed that the Eclipse update manager doesn't work with our
3.3 RPMs. Does anyone have time to take a look at it? I'm away next
week at the Equinox Summit in Ottawa. I'm going to try to take a look
this weekend but I don't have that much time.
I suspect this has something to do with the split install we do
(arch-specific fragments in /usr/lib or /usr/lib64 and arch-independent
stuff in /usr/share) for LSB compliance. Supposedly it worked in 3.2.x
and I don't think much changed in the update manager between 3.2.2 and
3.3.0 so it shouldn't be too difficult to narrow down the problem.
Thanks,
Andrew
16 years, 2 months