[gentoo-java] problems compiling junit

[gentoo-java] problems compiling junit

[Henrique Ferreiro]

I am using the migration overlay. After installing sun-jdk-1.4 and
sun-jdk-1.5 and setting 1.4 as system vm I have the following problem:

localhost ~ # emerge -1 junit
Calculating dependencies ... done!
>>> Emerging (1 of 1) dev-java/junit-3.8.1-r1 to /
>>> checksums files   ;-) junit-3.8.1-r1.ebuild
>>> checksums files   ;-) files/digest-junit-3.8.1-r1
>>> checksums src_uri ;-) junit3.8.1.zip
 * Enabling generation-2 compatibility ...
 * Using sun-jdk-1.4
[ ok ]>>> Unpacking source...
>>> Unpacking junit3.8.1.zip to /var/tmp/portage/junit-3.8.1-r1/work
Archive:  src.jar
   creating: META-INF/
  inflating: META-INF/MANIFEST.MF
   creating: junit/awtui/
   creating: junit/extensions/
   creating: junit/framework/
   creating: junit/runner/
   creating: junit/swingui/
   creating: junit/swingui/icons/
   creating: junit/textui/
   creating: junit3.8.1/
  inflating: build.xml
  inflating: junit/awtui/AboutDialog.java
  inflating: junit/awtui/Logo.java
  inflating: junit/awtui/ProgressBar.java
  inflating: junit/awtui/TestRunner.java
  inflating: junit/extensions/ActiveTestSuite.java
  inflating: junit/extensions/ExceptionTestCase.java
  inflating: junit/extensions/RepeatedTest.java
  inflating: junit/extensions/TestDecorator.java
  inflating: junit/extensions/TestSetup.java
  inflating: junit/framework/Assert.java
  inflating: junit/framework/AssertionFailedError.java
  inflating: junit/framework/ComparisonFailure.java
  inflating: junit/framework/Protectable.java
  inflating: junit/framework/Test.java
  inflating: junit/framework/TestCase.java
  inflating: junit/framework/TestFailure.java
  inflating: junit/framework/TestListener.java
  inflating: junit/framework/TestResult.java
  inflating: junit/framework/TestSuite.java
  inflating: junit/runner/BaseTestRunner.java
  inflating: junit/runner/ClassPathTestCollector.java
  inflating: junit/runner/excluded.properties
  inflating: junit/runner/FailureDetailView.java
  inflating: junit/runner/LoadingTestCollector.java
  inflating: junit/runner/logo.gif
  inflating: junit/runner/ReloadingTestSuiteLoader.java
  inflating: junit/runner/SimpleTestCollector.java
  inflating: junit/runner/smalllogo.gif
  inflating: junit/runner/Sorter.java
  inflating: junit/runner/StandardTestSuiteLoader.java
  inflating: junit/runner/TestCaseClassLoader.java
  inflating: junit/runner/TestCollector.java
  inflating: junit/runner/TestRunListener.java
  inflating: junit/runner/TestSuiteLoader.java
  inflating: junit/runner/Version.java
  inflating: junit/swingui/AboutDialog.java
  inflating: junit/swingui/CounterPanel.java
  inflating: junit/swingui/DefaultFailureDetailView.java
  inflating: junit/swingui/FailureRunView.java
  inflating: junit/swingui/icons/error.gif
  inflating: junit/swingui/icons/failure.gif
  inflating: junit/swingui/icons/hierarchy.gif
  inflating: junit/swingui/icons/ok.gif
  inflating: junit/swingui/ProgressBar.java
  inflating: junit/swingui/StatusLine.java
  inflating: junit/swingui/TestHierarchyRunView.java
  inflating: junit/swingui/TestRunContext.java
  inflating: junit/swingui/TestRunner.java
  inflating: junit/swingui/TestRunView.java
  inflating: junit/swingui/TestSelector.java
  inflating: junit/swingui/TestSuitePanel.java
  inflating: junit/swingui/TestTreeModel.java
  inflating: junit/textui/ResultPrinter.java
  inflating: junit/textui/TestRunner.java
  inflating: stylesheet.css
>>> Source unpacked.
>>> Compiling source
in /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1 ...
/usr/bin/ant: line 161: arch: command not found
Buildfile: build.xml

init:

versiontag:
     [copy] Copying 1 file
to /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1/junit/runner
     [move] Moving 1 file
to /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1/junit/runner

build:

BUILD FAILED
java.lang.UnsupportedClassVersionError: junit/framework/Test
(Unsupported major.minor version 49.0)


-- 
gentoo-java@gentoo.org mailing list

[gentoo-java] Re: problems compiling junit

[Wiktor Wandachowicz]

Henrique Ferreiro <henrique.ferreiro@...> writes:

> 
> I am using the migration overlay. After installing sun-jdk-1.4 and
> sun-jdk-1.5 and setting 1.4 as system vm I have the following problem:
> 
> localhost ~ # emerge -1 junit
> Calculating dependencies ... done!
> >>> Emerging (1 of 1) dev-java/junit-3.8.1-r1 to /
...
> >>> Compiling source
> in /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1 ...
> /usr/bin/ant: line 161: arch: command not found
> Buildfile: build.xml
> 
> init:
> 
> versiontag:
>      [copy] Copying 1 file
> to /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1/junit/runner
>      [move] Moving 1 file
> to /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1/junit/runner
> 
> build:
> 
> BUILD FAILED
> java.lang.UnsupportedClassVersionError: junit/framework/Test
> (Unsupported major.minor version 49.0)
> 


Well, that's exactly the issue that the new Java handling should solve
(compile time JVM version switching). In your previous post you've said
that you have problems setting the generation-1 system VM. I suspect that
there's something wrong with your setup, even though you might have
followed the instructions closely...

Maybe you could post the output of the following commands?

# java-config-1 -L
# java-config-2 -L
# which java
# java -version
# echo ${PATH}
# emerge -pv =sun-jdk-1.4*
# emerge -pv =sun-jdk-1.5*
# emerge --info

That would clear the situation a bit.

Wiktor

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Henrique Ferreiro]

O Mér, 12-04-2006 ás 11:36 +0000, Wiktor Wandachowicz escribiu:
> Henrique Ferreiro <henrique.ferreiro@...> writes:
> 
> > 
> > I am using the migration overlay. After installing sun-jdk-1.4 and
> > sun-jdk-1.5 and setting 1.4 as system vm I have the following problem:
> > 
> > localhost ~ # emerge -1 junit
> > Calculating dependencies ... done!
> > >>> Emerging (1 of 1) dev-java/junit-3.8.1-r1 to /
> ...
> > >>> Compiling source
> > in /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1 ...
> > /usr/bin/ant: line 161: arch: command not found
> > Buildfile: build.xml
> > 
> > init:
> > 
> > versiontag:
> >      [copy] Copying 1 file
> > to /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1/junit/runner
> >      [move] Moving 1 file
> > to /var/tmp/portage/junit-3.8.1-r1/work/junit3.8.1/junit/runner
> > 
> > build:
> > 
> > BUILD FAILED
> > java.lang.UnsupportedClassVersionError: junit/framework/Test
> > (Unsupported major.minor version 49.0)
> > 
> 
> 
> Well, that's exactly the issue that the new Java handling should solve
> (compile time JVM version switching). In your previous post you've said
> that you have problems setting the generation-1 system VM. I suspect that
> there's something wrong with your setup, even though you might have
> followed the instructions closely...
> 
> Maybe you could post the output of the following commands?
> 
> # java-config-1 -L
[sun-jdk-1.4.2.10] "Sun JDK
1.4.2.10" (/etc/env.d/java/20sun-jdk-1.4.2.10) *
> # java-config-2 -L
1) Sun JDK 1.4.2.10 [sun-jdk-1.4]
(/usr/share/java-config-2/vm/sun-jdk-1.4)
*) Sun JDK 1.5.0.06 [sun-jdk-1.5]
(/usr/share/java-config-2/vm/sun-jdk-1.5)
> # which java
/usr/bin/java
localhost ~ # ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Abr  6 17:00 /usr/bin/java
-> /usr/bin/run-java-tool
> # java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
> # echo ${PATH}
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/sun-jdk-1.4.2.10/bin:/opt/sun-jdk-1.4.2.10/jre/bin:/opt/sun-jdk-1.4.2.10/jre/javaws
> # emerge -pv =sun-jdk-1.4*
[ebuild  NSF  ] dev-java/java-sdk-docs-1.4.2  33,591 kB
[ebuild   Rf  ] dev-java/sun-jdk-1.4.2.10-r13  USE="X alsa doc*
nsplugin* -jce" 0 kB [5]

Total size of downloads: 33,591 kB
Portage overlays:
 [1] /usr/portage/local/layman/portage
 [2] /usr/portage/local/layman/bmg-main
 [3] /usr/portage/local/layman/gentopia
 [4] /usr/portage/local/layman/java-experimental
 [5] /usr/portage/local/layman/migration
> # emerge -pv =sun-jdk-1.5*
[ebuild   Rf  ] dev-java/sun-jdk-1.5.0.06-r13  USE="X alsa doc nsplugin
-jce" 0 kB [5]
> # emerge --info
Portage 2.1_pre7-r5 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.4-r1, 2.6.16-suspend2 i686)
=================================================================
System uname: 2.6.16-suspend2 i686 Intel(R) Pentium(R) M processor
1.60GHz
Gentoo Base System version 1.12.0_pre17
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium-m -mtune=pentium-m -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -march=pentium-m -mtune=pentium-m -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildpkg candy ccache collision-protect confcache
digest distlocks fixpackages metadata-transfer sandbox sfperms strict
test userpriv usersandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="gl_ES.UTF-8"
LC_ALL="gl_ES.UTF-8"
LINGUAS="gl es"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/portage /usr/portage/local/layman/bmg-main /usr/portage/local/layman/gentopia /usr/portage/local/layman/java-experimental /usr/portage/local/layman/migration /usr/portage/local/layman/chewi /usr/portage/local/layman/initng /usr/portage/local/layman/gnome-experimental"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa apm avahi avi bash-completion beagle bzip2 cairo
cli ctype cups dba dbus dri dvd dvdr eds emboss encode esd exif expat
fastbuild fbcon firefox foomaticdb force-cgi-redirect fortran ftp gd
gdbm gif gnome gnutls gphoto2 gpm gstreamer gstreamer10 gtk gtk2 gtkhtml
hal imlib isdnlog jpeg lcms libg++ libnotify libwww mad memlimit mikmod
mmx mmxext mp3 mpeg ncurses nls nptl ogg opengl pcre pdf pdflib pic png
posix pppd quicktime readline samba session simplexml soap sockets spell
spl sse sse2 ssl svg test tokenizer truetype truetype-fonts type1-fonts
udev unicode vorbis xml xsl xv zlib elibc_glibc input_devices_evdev
input_devices_mouse input_devices_keyboard input_devices_synaptics
kernel_linux linguas_gl linguas_es userland_GNU video_cards_ati"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS

> That would clear the situation a bit.
> 
> Wiktor
> 

-- 
gentoo-java@gentoo.org mailing list

[gentoo-java] Re: problems compiling junit

[Wiktor Wandachowicz]

Henrique Ferreiro <henrique.ferreiro@...> writes:

> > # java-config-1 -L
> [sun-jdk-1.4.2.10] "Sun JDK
> 1.4.2.10" (/etc/env.d/java/20sun-jdk-1.4.2.10) *

While the above is correct, the latter...

> > # java-config-2 -L
> 1) Sun JDK 1.4.2.10 [sun-jdk-1.4]
> (/usr/share/java-config-2/vm/sun-jdk-1.4)
> *) Sun JDK 1.5.0.06 [sun-jdk-1.5]
> (/usr/share/java-config-2/vm/sun-jdk-1.5)

... explains a bit - you probably shouldn't have a SYSTEM JVM
set to Java 1.5 as of today. You can do so freely on your regular
user account.

> > # which java
> /usr/bin/java
> localhost ~ # ls -l /usr/bin/java
> lrwxrwxrwx 1 root root 22 Abr  6 17:00 /usr/bin/java
> -> /usr/bin/run-java-tool
> > # java -version
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)

The above confirms that fact.

> > # echo ${PATH}
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:
> /usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/sun-jdk-1.4.2.10/bin:
> /opt/sun-jdk-1.4.2.10/jre/bin:/opt/sun-jdk-1.4.2.10/jre/javaws

Here the /usr/bin/java symliked to run-java-tool takes precedence
over the /opt/sun-jdk-1.4.2.10/bin (this is expected).

> > # emerge -pv =sun-jdk-1.4*
> [ebuild  NSF  ] dev-java/java-sdk-docs-1.4.2  33,591 kB
> [ebuild   Rf  ] dev-java/sun-jdk-1.4.2.10-r13  USE="X alsa doc*
> nsplugin* -jce" 0 kB [5]
> 
> Total size of downloads: 33,591 kB
> Portage overlays:
>  [1] /usr/portage/local/layman/portage
>  [2] /usr/portage/local/layman/bmg-main
>  [3] /usr/portage/local/layman/gentopia
>  [4] /usr/portage/local/layman/java-experimental
>  [5] /usr/portage/local/layman/migration

A nice set of overlays ;)
Most probably you've stepped onto a problem similar to the one already
discussed (mixing java-experimental and migration overlays is not always
healthy), see here:
http://thread.gmane.org/gmane.linux.gentoo.java/825/focus=825

However, setting your preferred gen-2 system VM and rebuilding the offensive
packages should help. You can try to find them by using:

# emerge -pvet junit | less

But spotting said packages requires a bit of patience and a good eye :)
However, the situation is fixable, either manually or maybe through
the java-1.5-fixer (http://article.gmane.org/gmane.linux.gentoo.java/839)

BTW, if you choose to try the java-1.5-fixer script, could you please
describe your experiences? I never used this (never needed it, though)
but I'm curious how this could help in such situation.

Wiktor

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Henrique Ferreiro]

O Mér, 12-04-2006 ás 12:21 +0000, Wiktor Wandachowicz escribiu:
> Henrique Ferreiro <henrique.ferreiro@...> writes:
> 
> > > # java-config-1 -L
> > [sun-jdk-1.4.2.10] "Sun JDK
> > 1.4.2.10" (/etc/env.d/java/20sun-jdk-1.4.2.10) *
> 
> While the above is correct, the latter...
> 
> > > # java-config-2 -L
> > 1) Sun JDK 1.4.2.10 [sun-jdk-1.4]
> > (/usr/share/java-config-2/vm/sun-jdk-1.4)
> > *) Sun JDK 1.5.0.06 [sun-jdk-1.5]
> > (/usr/share/java-config-2/vm/sun-jdk-1.5)
> 
> ... explains a bit - you probably shouldn't have a SYSTEM JVM
> set to Java 1.5 as of today. You can do so freely on your regular
> user account.

The the migration document shoud warm about this. Anyway, I did 

java-config-2 -S sun-jdk-1.4

Now:

$ java -version
java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)

But ant-core continues to build with java-1.5.
> 
> > > # which java
> > /usr/bin/java
> > localhost ~ # ls -l /usr/bin/java
> > lrwxrwxrwx 1 root root 22 Abr  6 17:00 /usr/bin/java
> > -> /usr/bin/run-java-tool
> > > # java -version
> > java version "1.5.0_06"
> > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
> 
> The above confirms that fact.
> 
> > > # echo ${PATH}
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:
> > /usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/sun-jdk-1.4.2.10/bin:
> > /opt/sun-jdk-1.4.2.10/jre/bin:/opt/sun-jdk-1.4.2.10/jre/javaws
> 
> Here the /usr/bin/java symliked to run-java-tool takes precedence
> over the /opt/sun-jdk-1.4.2.10/bin (this is expected).
> 
> > > # emerge -pv =sun-jdk-1.4*
> > [ebuild  NSF  ] dev-java/java-sdk-docs-1.4.2  33,591 kB
> > [ebuild   Rf  ] dev-java/sun-jdk-1.4.2.10-r13  USE="X alsa doc*
> > nsplugin* -jce" 0 kB [5]
> > 
> > Total size of downloads: 33,591 kB
> > Portage overlays:
> >  [1] /usr/portage/local/layman/portage
> >  [2] /usr/portage/local/layman/bmg-main
> >  [3] /usr/portage/local/layman/gentopia
> >  [4] /usr/portage/local/layman/java-experimental
> >  [5] /usr/portage/local/layman/migration
> 
> A nice set of overlays ;)
> Most probably you've stepped onto a problem similar to the one already
> discussed (mixing java-experimental and migration overlays is not always
> healthy), see here:
> http://thread.gmane.org/gmane.linux.gentoo.java/825/focus=825
> 
> However, setting your preferred gen-2 system VM and rebuilding the offensive
> packages should help. You can try to find them by using:
> 
> # emerge -pvet junit | less
> 
> But spotting said packages requires a bit of patience and a good eye :)
> However, the situation is fixable, either manually or maybe through
> the java-1.5-fixer (http://article.gmane.org/gmane.linux.gentoo.java/839)
> 
> BTW, if you choose to try the java-1.5-fixer script, could you please
> describe your experiences? I never used this (never needed it, though)
> but I'm curious how this could help in such situation.
> 
> Wiktor
> 

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Joshua Nichols]

Henrique Ferreiro wrote:
> O Mér, 12-04-2006 ás 12:21 +0000, Wiktor Wandachowicz escribiu:
>   
>> Henrique Ferreiro <henrique.ferreiro@...> writes:
>>
>>     
>>>> # java-config-1 -L
>>>>         
>>> [sun-jdk-1.4.2.10] "Sun JDK
>>> 1.4.2.10" (/etc/env.d/java/20sun-jdk-1.4.2.10) *
>>>       
>> While the above is correct, the latter...
>>
>>     
>>>> # java-config-2 -L
>>>>         
>>> 1) Sun JDK 1.4.2.10 [sun-jdk-1.4]
>>> (/usr/share/java-config-2/vm/sun-jdk-1.4)
>>> *) Sun JDK 1.5.0.06 [sun-jdk-1.5]
>>> (/usr/share/java-config-2/vm/sun-jdk-1.5)
>>>       
>> ... explains a bit - you probably shouldn't have a SYSTEM JVM
>> set to Java 1.5 as of today. You can do so freely on your regular
>> user account.
>>     
>
> The the migration document shoud warm about this. Anyway, I did 
>
> java-config-2 -S sun-jdk-1.4
>
>   
The document doesn't explicitly state it, but java-check-environment
should be upset with you using a 1.5 system vm. In the event that it
doesn't mind... then it's a bug.

> Now:
>
> $ java -version
> java version "1.4.2_10"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
>
> But ant-core continues to build with java-1.5.
>   
The new system has a separation between the system vm, and the vm used
to compile package (fuller details here [1]) The vm used at build time
is determined by the virtual/jdk dependency of the ebuild and settings
in /etc/java-config-2/build/jdk.conf . In this jdk.conf, you could go like:

*=sun-jdk-1.5

And it would try to build packages that it can with 1.5. If a package
can only be built with 1.4, then the vm would be switched to a 1.4 vm.

So.... this suggests to me that you have a line like the one above in
jdk.conf. Is this the case?
>>>> # which java
>>>>         
>>> /usr/bin/java
>>> localhost ~ # ls -l /usr/bin/java
>>> lrwxrwxrwx 1 root root 22 Abr  6 17:00 /usr/bin/java
>>> -> /usr/bin/run-java-tool
>>>       
>>>> # java -version
>>>>         
>>> java version "1.5.0_06"
>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
>>> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
>>>       
>> The above confirms that fact.
>>
>>     
>>>> # echo ${PATH}
>>>>         
>>> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:
>>> /usr/i686-pc-linux-gnu/gcc-bin/3.4.6:/opt/sun-jdk-1.4.2.10/bin:
>>> /opt/sun-jdk-1.4.2.10/jre/bin:/opt/sun-jdk-1.4.2.10/jre/javaws
>>>       
>> Here the /usr/bin/java symliked to run-java-tool takes precedence
>> over the /opt/sun-jdk-1.4.2.10/bin (this is expected).
>>
>>     
>>>> # emerge -pv =sun-jdk-1.4*
>>>>         
>>> [ebuild  NSF  ] dev-java/java-sdk-docs-1.4.2  33,591 kB
>>> [ebuild   Rf  ] dev-java/sun-jdk-1.4.2.10-r13  USE="X alsa doc*
>>> nsplugin* -jce" 0 kB [5]
>>>
>>> Total size of downloads: 33,591 kB
>>> Portage overlays:
>>>  [1] /usr/portage/local/layman/portage
>>>  [2] /usr/portage/local/layman/bmg-main
>>>  [3] /usr/portage/local/layman/gentopia
>>>  [4] /usr/portage/local/layman/java-experimental
>>>  [5] /usr/portage/local/layman/migration
>>>       
>> A nice set of overlays ;)
>> Most probably you've stepped onto a problem similar to the one already
>> discussed (mixing java-experimental and migration overlays is not always
>> healthy), see here:
>> http://thread.gmane.org/gmane.linux.gentoo.java/825/focus=825
>>
>> However, setting your preferred gen-2 system VM and rebuilding the offensive
>> packages should help. You can try to find them by using:
>>
>> # emerge -pvet junit | less
>>
>> But spotting said packages requires a bit of patience and a good eye :)
>> However, the situation is fixable, either manually or maybe through
>> the java-1.5-fixer (http://article.gmane.org/gmane.linux.gentoo.java/839)
>>
>> BTW, if you choose to try the java-1.5-fixer script, could you please
>> describe your experiences? I never used this (never needed it, though)
>> but I'm curious how this could help in such situation.
>>
>> Wiktor
>>
>>     
>
>   
[1] 
https://projects.gentooexperimental.org/expj/wiki/Old_system_new_system_and_why
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Jon Severinsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>> ... explains a bit - you probably shouldn't have a SYSTEM JVM
>>> set to Java 1.5 as of today. You can do so freely on your regular
>>> user account.
>>>     
>> The the migration document shoud warm about this. Anyway, I did 
>>
>> java-config-2 -S sun-jdk-1.4
I'm running java-1.5 as a *generation 2* system vm without any problems.
The only problem is if you at one point where using 1.5 as a *generation
1* system vm (e.g. before you started using the migration overlay).
You can safely do "java-config-2 -S sun-jdk-1.5", as long as
"java-config-1 -f" doesn't list a 1.5 jdk and
/etc/java-config-2/build/jdk.conf doesn't list a 1.5 jdk for 1.4. (e.g.
doesn't give a version if you use the *=sun-jdk syntax)

> The document doesn't explicitly state it, but java-check-environment
> should be upset with you using a 1.5 system vm. In the event that it
> doesn't mind... then it's a bug.
Again, only when you use it as *generation 1* system. Generation 2 is
1.5 safe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEPenLOOpxqcksWu4RAs7DAKCIoXsXoAtTyx4fU4AGDAqVb2Yj9gCfUIqd
usjiHUqI0wic0UVxYTKTfnc=
=svDs
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Henrique Ferreiro]

O Xov, 13-04-2006 ás 08:03 +0200, Jon Severinsson escribiu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>> ... explains a bit - you probably shouldn't have a SYSTEM JVM
> >>> set to Java 1.5 as of today. You can do so freely on your regular
> >>> user account.
> >>>     
> >> The the migration document shoud warm about this. Anyway, I did 
> >>
> >> java-config-2 -S sun-jdk-1.4
> I'm running java-1.5 as a *generation 2* system vm without any problems.
> The only problem is if you at one point where using 1.5 as a *generation
> 1* system vm (e.g. before you started using the migration overlay).
> You can safely do "java-config-2 -S sun-jdk-1.5", as long as
> "java-config-1 -f" doesn't list a 1.5 jdk and
> /etc/java-config-2/build/jdk.conf doesn't list a 1.5 jdk for 1.4. (e.g.
> doesn't give a version if you use the *=sun-jdk syntax)
Then, the migration document should state how to set the generation-2
system vm. It only tells about java-config-2 -s ...

Anyway I have two problems right now:
1. If I do java-config-2 -S sun-jdk-1.4, ant-core continues to build
with sun-java-1.5
2. Junit does not compile even having compiled ant-core with 1.4 vm (I
had to modify jdk.conf)

> > The document doesn't explicitly state it, but java-check-environment
> > should be upset with you using a 1.5 system vm. In the event that it
> > doesn't mind... then it's a bug.
> Again, only when you use it as *generation 1* system. Generation 2 is
> 1.5 safe.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFEPenLOOpxqcksWu4RAs7DAKCIoXsXoAtTyx4fU4AGDAqVb2Yj9gCfUIqd
> usjiHUqI0wic0UVxYTKTfnc=
> =svDs
> -----END PGP SIGNATURE-----

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Jon Severinsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> I'm running java-1.5 as a *generation 2* system vm without any
>> problems. The only problem is if you at one point where using 1.5 as
>> a *generation 1* system vm (e.g. before you started using the
>> migration overlay).
>> You can safely do "java-config-2 -S sun-jdk-1.5", as long as
>> "java-config-1 -f" doesn't list a 1.5 jdk and
>> /etc/java-config-2/build/jdk.conf doesn't list a 1.5 jdk for 1.4.
>> (e.g. doesn't give a version if you use the *=sun-jdk syntax)
> Then, the migration document should state how to set the generation-2
> system vm. It only tells about java-config-2 -s ...
Perhaps it should. On the other hand you don't have to, it will be set
automatically during the vm update process (which is described).
java-config-2 -s is only mentioned because it differers from the plain
portage case.

>> Anyway I have two problems right now:
>> 1. If I do java-config-2 -S sun-jdk-1.4, ant-core continues to build
>> with sun-java-1.5
Because system vm has nothing to do with emerge. For that you set the
build jdk. Note that system vm can be a jre or a jdk, while compilation
jdk has to be a jdk. This procedure differs from a plain portage
installation, and should perhaps be mentioned somewhere.

>> 2. Junit does not compile even having compiled ant-core with 1.4 vm
>> (I had to modify jdk.conf)
The the default jdk.conf will not make 1.4 sources build with a 1.5 jdk,
so you do not *have* to modify jdk.conf. However, you *must not* changee
jdk.conf to an invalid state, which is currently possible (and you must
have done). Perhaps there should be a warning in the sample file?
(something like "# Warning: Do NOT set a 1.5 jdk for use with anything
but 1.5 sources!")
If Junit doesn't compile after having (re-)emerged all java-packages
with a corrected jdk.conf, file a bugreport. To find all packages you
have to re-emerge use java-1.5-fixer from the list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEPjdQOOpxqcksWu4RAjjqAJ42uRyFXdqavyXNszJvqHOGiB8wTgCgnHsu
wqQylcrz1/tz8ArfaK9ovoM=
=bc0Z
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Jon Severinsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> I did not modify jdk.conf. Every line is commented.
Then ant-core, as well as junit, should be build with 1.4. Is that the case?

>> The only dependency of junit (made with java) is ant-core and it is
>> built with jdk-1.5 with no problems.
Yes, ant-core can be built with 1.4 or 1.5, but if you build ant-core
with 1.5 you must build everything depending on ant-core with 1.5 as
well, and some of those packages can't handle 1.5. That is why ant-core
should be re-built with 1.4 (if you haven't already done that).

>> java-1.5-fixer only tries to rebuild jdbc-mysql and junit and fails with
>> both of them.
OK, then it's probably time to file a bug...
Does it try to build them with 1.4 or 1.5?

- - Jon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEPj6lOOpxqcksWu4RAoB1AJ9VTo/SfxgsWBx6PIWx5L5DoyzY6wCePIxE
BVIPaod9vfLkfkp/BqaCTCQ=
=LOtW
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Henrique Ferreiro]

O Xov, 13-04-2006 ás 14:05 +0200, Jon Severinsson escribiu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >> I did not modify jdk.conf. Every line is commented.
> Then ant-core, as well as junit, should be build with 1.4. Is that the case?
> 
> >> The only dependency of junit (made with java) is ant-core and it is
> >> built with jdk-1.5 with no problems.
> Yes, ant-core can be built with 1.4 or 1.5, but if you build ant-core
> with 1.5 you must build everything depending on ant-core with 1.5 as
> well, and some of those packages can't handle 1.5. That is why ant-core
> should be re-built with 1.4 (if you haven't already done that).
Then if you have not installed ant-core and try to install junit it
cannot as it will be compiled with jdk-1.4 whereas ant-core will be
compiled with jdk-1.5. Should I file a bug?
> 
> >> java-1.5-fixer only tries to rebuild jdbc-mysql and junit and fails with
> >> both of them.
> OK, then it's probably time to file a bug...
> Does it try to build them with 1.4 or 1.5?
With 1.4.
The problem with jdbc-mysql is the same as with junit:
BUILD FAILED
java.lang.UnsupportedClassVersionError: junit/framework/Test
(Unsupported major.minor version 49.0)

> 
> - - Jon
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFEPj6lOOpxqcksWu4RAoB1AJ9VTo/SfxgsWBx6PIWx5L5DoyzY6wCePIxE
> BVIPaod9vfLkfkp/BqaCTCQ=
> =LOtW
> -----END PGP SIGNATURE-----

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Henrique Ferreiro]

> >> I did not modify jdk.conf. Every line is commented.
> Then ant-core, as well as junit, should be build with 1.4. Is that the case?
No. ant-core is being built with jdk-1.5. Anyway junit does not compile using 
1.4 with ant-core.


-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Joshua Nichols]

Henrique Ferreiro wrote:
>>>> I did not modify jdk.conf. Every line is commented.
>> Then ant-core, as well as junit, should be build with 1.4. Is that the case?
> No. ant-core is being built with jdk-1.5. Anyway junit does not compile using 
> 1.4 with ant-core.
> 
> 


Alright... I'm pretty sure what the problem is. If you take a look at
/usr/bin/ant... at some point, it pulls in a bunch of jars from several
packages. This is necessary to make sure that all the ant tasks work
properly. One of these happens to be junit....


So what I believe is happening... you have junit installed (and built
with 1.5), then go to rebuild with 1.4. The ebuild calls ant, which
pulls in junit compiled with 1.5 onto the classpath. When javac tries to
resolve junit classes... it's getting them from the 1.5-built junit,
instead of the junit which is being built. So, the workaround would be
to unmerge junit before trying to rebuidl it with 1.4.

Essentially, this problem comes down to who we handle /usr/bin/ant, and
how it pulls in all its dependencies. It is currently hardcoded to bring
in certain packages, which is less than ideal, because we need to have
fine-grain control over the classpath. In particular, when building
packages, we don't want to include the already-compiled version that is
living on the system.

Aside from this, I recommend you try the java-1.5-fixer I posted in a
different thread. It actually goes through all of ant's dependencies,
and if any were built with 1.5, will unmerge them, and merge them again.

Hope this helps,

Josh
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Henrique Ferreiro]

Thank you very much. I unmerged and merged junit successfully.

I am using java-1.5-fixer from migration overlay. It seems that it does
not unmerge the offending packages first. When are you going to do
another release?

O Xov, 13-04-2006 ás 20:29 -0500, Joshua Nichols escribiu:
> Henrique Ferreiro wrote:
> >>>> I did not modify jdk.conf. Every line is commented.
> >> Then ant-core, as well as junit, should be build with 1.4. Is that the case?
> > No. ant-core is being built with jdk-1.5. Anyway junit does not compile using 
> > 1.4 with ant-core.
> > 
> > 
> 
> 
> Alright... I'm pretty sure what the problem is. If you take a look at
> /usr/bin/ant... at some point, it pulls in a bunch of jars from several
> packages. This is necessary to make sure that all the ant tasks work
> properly. One of these happens to be junit....
> 
> 
> So what I believe is happening... you have junit installed (and built
> with 1.5), then go to rebuild with 1.4. The ebuild calls ant, which
> pulls in junit compiled with 1.5 onto the classpath. When javac tries to
> resolve junit classes... it's getting them from the 1.5-built junit,
> instead of the junit which is being built. So, the workaround would be
> to unmerge junit before trying to rebuidl it with 1.4.
> 
> Essentially, this problem comes down to who we handle /usr/bin/ant, and
> how it pulls in all its dependencies. It is currently hardcoded to bring
> in certain packages, which is less than ideal, because we need to have
> fine-grain control over the classpath. In particular, when building
> packages, we don't want to include the already-compiled version that is
> living on the system.
> 
> Aside from this, I recommend you try the java-1.5-fixer I posted in a
> different thread. It actually goes through all of ant's dependencies,
> and if any were built with 1.5, will unmerge them, and merge them again.
> 
> Hope this helps,
> 
> Josh

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Joshua Nichols]

Henrique Ferreiro wrote:
> Thank you very much. I unmerged and merged junit successfully.
>
>   
I'm glad that fixed the problem.

> I am using java-1.5-fixer from migration overlay. It seems that it does
> not unmerge the offending packages first. When are you going to do
> another release?
>   
I hope to do an update to java-config-wrapper (which contains
java-1.5-fixer over the weekend. The most up-to-date version will
continue to live at:

http://svn.gentooexperimental.org/svn/java/java-config-wrapper/trunk/src/shell/java-1.5-fixer


- Josh
-- 
gentoo-java@gentoo.org mailing list

[gentoo-java] Re: problems compiling junit

[Wiktor Wandachowicz]

Joshua Nichols <nichoj@...> writes:

> So what I believe is happening... you have junit installed (and built
> with 1.5), then go to rebuild with 1.4. The ebuild calls ant, which
> pulls in junit compiled with 1.5 onto the classpath. When javac tries to
> resolve junit classes... it's getting them from the 1.5-built junit,
> instead of the junit which is being built. So, the workaround would be
> to unmerge junit before trying to rebuidl it with 1.4.

That's exactly what I did [manually] when I've found that having a 1.5 system
JVM is not healthy... I've listed all packages depending on jdk, unmerged them
and used "emerge -1" to get them back with 1.4 jdk. (It was so long ago that
I almost forgot about that solution: unmerge/emerge. If I remembered better
I'd suggest that to Henrique sooner - anyway, good analysis Joshua!)

Then I've found the axxo-overlay and later the migration-overlay.
The rest is history. :)

Cheers,


-- 
gentoo-java@gentoo.org mailing list

[gentoo-java] Re: problems compiling junit

[Wiktor Wandachowicz]

Henrique Ferreiro <henrique.ferreiro@...> writes:

> 
> BUILD FAILED
> java.lang.UnsupportedClassVersionError: junit/framework/Test
> (Unsupported major.minor version 49.0)
> 

OTOH after some thought, this error simply means that while currently
you have 1.4 system JVM, some libraries were compiled with 1.5 JVM.
This is unfortunate, because Java 1.4 cannot use 1.5 classes (their
internal file format is different).

Maybe you should look into java-1.5-fixer, previously posted by Joshua
on the same list? (http://article.gmane.org/gmane.linux.gentoo.java/839)

It's also possible to rebuild the offending packages by hand, but you
will have to find them manually (it may take some time, though...)
The first step is to determine the packages that depends on Java and
then remerge them. I've done it once, so I know it's at least possible :)

# emerge -avu gentoolkit    ### If you don't have equery, that is
# equery depends virtual/jdk | tee ~/java-packages.txt | less

HTH,
Wiktor

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: problems compiling junit

[Joshua Nichols]

Wiktor Wandachowicz wrote:
> Henrique Ferreiro <henrique.ferreiro@...> writes:
>
>   
>> BUILD FAILED
>> java.lang.UnsupportedClassVersionError: junit/framework/Test
>> (Unsupported major.minor version 49.0)
>>
>>     
>
> OTOH after some thought, this error simply means that while currently
> you have 1.4 system JVM, some libraries were compiled with 1.5 JVM.
> This is unfortunate, because Java 1.4 cannot use 1.5 classes (their
> internal file format is different).
>
> Maybe you should look into java-1.5-fixer, previously posted by Joshua
> on the same list? (http://article.gmane.org/gmane.linux.gentoo.java/839)
>
> It's also possible to rebuild the offending packages by hand, but you
> will have to find them manually (it may take some time, though...)
> The first step is to determine the packages that depends on Java and
> then remerge them. I've done it once, so I know it's at least possible :)
>
> # emerge -avu gentoolkit    ### If you don't have equery, that is
> # equery depends virtual/jdk | tee ~/java-packages.txt | less
>
> HTH,
> Wiktor
>
>   

java-1.5-fixer actually is installed now to /usr/bin/java-1.5-fixer.

As for the problem you're having, it says in the documentation that if
you were using 1.5 as a system vm, you will need to run java-1.5-fixer
in order to get your system in tip-top-shape.

Unfortunately, the script isn't flawless, as I previously mentioned on
the list [1]. In particular, if something that depends is used by ant is
compiled with 1.5, the script will choke up on it. The workaround is to
try to figure out what classes are still compiled with 1.5, unmerge them
all, then remerge them.

[1] http://article.gmane.org/gmane.linux.gentoo.java/829

- Josh
-- 
gentoo-java@gentoo.org mailing list