[gentoo-dev] Changes to the way Java packages are built

[gentoo-dev] Changes to the way Java packages are built

[Joshua Nichols]

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

= Background =

As some might have noticed, Java 1.5 has been package.masked for some
time now. There are a number of issues introduced with 1.5 that have
kept it in package.mask. Please see the Java 1.5 FAQ [1] for more details.

[1] http://www.gentoo.org/proj/en/java/tiger-faq.xml

About a year ago, work was begun on improving our part of the build
system (read: Java related eclasses and our java-config tool) in a way
to make it much more flexible in general, but specifically improve it to
get around the known issues. It took about six months to fully develop.
Unfortunately, the new system was not quite a drop-in replacement. So,
it took from then until now to determine how to migrate from the current
system  to the new one in a sane way.


= The Current System =

To give some proper background, it is worth going over the current
system briefly.

== The Java Virtual Machine ==
Each Java Virtual Machine (VM) installs an environment file into
/etc/env.d/java. These files contain information about where JAVA_HOME
is, the PATH to include, etc.

VMs traditionally get installed at /opt/${P}

We have the concept of a 'system' VM and a 'user' VM. The system VM is
the default VM that will be used for root, and for users who haven't
selected a user VM. The user VM is, as one might guess, selected on a
per user basis. It is worth noting that root always uses the system VM,
and as a result, packages use the system VM when being merged by emerge.

java-config is used to set the system and user VM. When you do so, the
appropriate file from /etc/env.d/java is copied to/etc/env.d/20java for
the system VM or to ~/.gentoo/java-env for the user VM.

java-config's notion of the current VM is tied entirely to the
environment, specifically to JAVA_HOME. Therefore, if you change the
system VM, you'd need to run env-update and then resource /etc/profile.
Likewise, changing the user VM involves sourcing ~/.gentoo/java-env.

The fact that you're tied to the environment is annoying, because as
mentioned, you need re-source the appropriate files. Now imagine you
have a ton of terminals open... you'd have to source the environment
files from each one.

== Packages ==

When a Java package is built, information about it is saved in
/usr/share/${PN}-${SLOT}/package.env (or /usr/share/${PN}/package.env if
SLOT == 0). In particular, the jars that are associated with the package
are recorded, as well as which jars from other packages are used.
java-config can later be used to query for this information.

== Eclasses ==

There are currently 3 eclasses: java, java-pkg, and java-utils.

java.eclass is used for packages which provide a VM.
java-pkg.eclass is used for most Java packages. It provides tools for
querying installed jars, and for installing various Java related files.
java-utils.eclass provides a few utility functions for dealing with Java
stuff.

= The New System =

== The Java Virtual Machine ==
In addition to the concept of a system and a user VM, the new system has
a build VM. As the name implies, the build VM is used for building
packages (instead of the system VM). Sane defaults are defined on a per
platform basis at /usr/share/java-config-2/config/jdk-defaults.conf [3].
The build VM can further be configured by
/etc/java-config-2/build/jdk.conf [4] .

[3]
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk-defaults-x86.conf
[4]
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk.conf

For each Java release (ie 1.3, 1.4, 1.5, etc), you can specify which
vendor and version to use at build time.

In addition to being installed to /opt/${P}, VMs also now have a symlink
in /usr/lib/jvm/${PN}-${SLOT}. The purpose of these symlinks is
explained further down.

The user and system VMs are now represented by symlinks pointing to VMs
located in /usr/lib/jvm/. The system VM lives at
/etc/java-config-2/current-system-vm, and the user VM at
~/.gentoo/java-config-2/current-user-vm . Additionally, an environment
variable, GENTOO_VM, can be used to specify the VM used at a given
instance. GENTOO_VM should be the name of a VM located in /usr/lib/jvm.
So with regard to what VM is used, first GENTOO_VM is checked, then the
user VM (for non-root users), and then lastly the system VM.


All the trusty java binaries, ie java, javac, javadoc, jar, etc, now get
wrappers installed into /usr/bin. These are actually symlinks to
/usr/bin/run-java-tool. This is a script which will figure out which
tool was invoked, and then determine which VM to used using the method
mentioned above.

== Packages ==

We now save more information about the build environment at build time
for each package. This information is saved at
/usr/share/${PN}-${SLOT}/package.env. This is facilitate troubleshooting
bugs. Specially, we collect the VM dependency is (ie >=virtual/jdk-1.4),
what -source and -target were used , and which VM. We also keep track of
where javadocs get installed, and where Java sources get installed,
which are useful for integrating into IDEs like netbeans and eclipse.

== Eclasses ==

For each eclass we previously had, we have a updated version of the
eclass, in addition to a few totally new eclasses.

java-utils-2.eclass
	A utility eclass. All utility functions live here (as opposed to being
spread between java-pkg and java-utils). Among other things, there are
functions for figuring out which VM should be used for building, based
on the DEPEND of a package (ie the virtual/jdk atom), and set GENTOO_VM
accordingly.

java-pkg-2.eclass
	The eclass the Java-only packages should inherit. It uses phase hooks
in order to make sure that the environment is setup properly for each phase.

java-pkg-opt-2.eclass
	Similar to java-pkg-2, except this is for packages that have optional
Java support, ie a USE flag. Phase hooks are again used to ensure the
environment is setup properly for each phase.

java-ant-2.eclass
	Packages that build using ant should inherit this eclass. Essentially,
this is eclass will ensure that build.xml files get rewritten such that
javac tasks have the right source and target attributes. In other words,
it makes sure that the right version bytecode gets compiled.

java-vm-2.eclass
	This is the successor to java.eclass, but more aptly name.

= Letting the Systems Coexist =

Originally, the new eclasses were a replacement for the current
eclasses, ie java-pkg-2 used to still be java-pkg, and java-utils-2 used
to be still be java-utils. Additionally, java-config was unslotted, so
the new version of it replaced the current one. Unfortunately, it was
realized that the new system was not a 100% drop-in replacement for the
current one, so we set forth with the task to find a way to migrate from
one to the other.

The method we decided on was to have the concept of having a
'generation' for each system, where the generation consists of the
eclasses, a version of java-config, and the tools that support it. To
cope with java-config, it is now slotted, and installs
/usr/bin/java-config-<insert generation here> . There is then a wrapper
for java-config at /usr/bin/java-config, which reads a variable
WANT_JAVA_CONFIG to determine which java-config to use, or if not
specified, the most recent version. The eclasses then export the
appropriate value of WANT_JAVA_CONFIG to get the right version of
java-config they need.

The existing eclasses and java-config-1.x will be 'generation 1'. The
new eclasses and java-config-2.x will be 'generation 2'.

The first packages to be migrated to generation 2 will be the VMs. When
installed, they will also install environment files that are compatible
with generation 1. This will allow you to have both a system VM for
generation 1, in addition to the system and build VM for generation 2.
The consequence of this is that ebuilds using generation 1 will continue
to build/run as they previously did, while allowing packages to be
migrated to use generation 2 on a package-by-package basis.  So, all
existing ebuilds will continue to work, and will be replaced
incrementally during our migration.

A note on Java 1.5 here... The 1.5 JDKs don't install a generation-1
compatible environment file. This is to prevent the problems already
describe with 1.5, and should prevent them from happening. At this
point, we should be able to unmask the 1.5 JDKs. So 1.5 will be
available, but only to generation-2 packages.

The next packages to be migrated will be ones that need the features of
the new generation. In particular, this means packages which need Java
1.5 to build and/or run.

Once these packages have been migrated, the rest of the tree which uses
Java will be migrated as expediently as possible. I've written some
notes about how to migrate over on our wiki [5]
[5] https://projects.gentooexperimental.org/expj/wiki/Migrating_packages

= Using the new system =

I have written documentation on switching to the new system, from the
user's perspective, over at our wiki [6]

[6]
https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay

= Feedback =

Obviously, these aren't exactly light changes that need to be made.
Therefore, it's important to get as much feedback as possible, and to
make the upgrade process as smooth as possible.

I'd hope to get these changes put into the tree in the next week or two,
pending feedback. This development has been a long time in the making,
and the Java 1.5 problem has been a thorn in our side for long enough.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFElXOa8ATTzZyw6sMRAnGvAJkBjWKyr35P8JCJ1FNNKHfReQltqgCcCXpY
2QEXi19VASfaRP7ZIo9GLj0=
=8gDY
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Changes to the way Java packages are built

[Duncan]

Joshua Nichols <nichoj@gentoo.org> posted 4495739A.3040603@gentoo.org,
excerpted below, on  Sun, 18 Jun 2006 10:39:06 -0500:

> I have written documentation on switching to the new system, from the
> user's perspective, over at our wiki [6]
> 
> [6]
> https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay

Are there instructions somewhere for keeping to a 100% freedomware
solution?  I've been wondering about installing Java, but don't consider
slaveryware a viable local option, thus the question. (FWIW, in the general
case I couldn't install whatever binary legally if I wanted to, since I
couldn't agree to the EULA, tho I've not examined the Sun/Blackdown EULAs
recently to see if this would apply there, as they still aren't
freedomware and are thus still not an option.)

If it's not yet possible (or no documentation that will work for a non-Java
guy), is there a timetable?  No rush or even pressure to do it if you
aren't, but thought I'd ask while the topic is hot.  I did try the given
URL as well as the Gentoo Java Guide, but the former seemed to presuppose
someone already involved in testing (understandable at this stage), and
the latter didn't seem to mention any of the newer 100% freedomware
alternatives I keep reading about.  Thus, there was no answer I could grok.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changes to the way Java packages are built

[Alec Warner]

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

Duncan wrote:
> Joshua Nichols <nichoj@gentoo.org> posted 4495739A.3040603@gentoo.org,
> excerpted below, on  Sun, 18 Jun 2006 10:39:06 -0500:
> 
>> I have written documentation on switching to the new system, from the
>> user's perspective, over at our wiki [6]
>>
>> [6]
>> https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay
> 
> Are there instructions somewhere for keeping to a 100% freedomware
> solution?  I've been wondering about installing Java, but don't consider
> slaveryware a viable local option, thus the question. (FWIW, in the general
> case I couldn't install whatever binary legally if I wanted to, since I
> couldn't agree to the EULA, tho I've not examined the Sun/Blackdown EULAs
> recently to see if this would apply there, as they still aren't
> freedomware and are thus still not an option.)
> 

May I ask, because I'm very confused, wtf is freedomware?

I can only assume you mean oss/free java?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRJWOSmzglR5RwbyYAQLCRg//d8Xz1zNavhwdy4bpIBl8hNCQYsY8ma4y
gvbC1B6UGddqEgsXIrHLbQP6WnK9BhycKCM3ODCuWdfmlDRbSaQTqC01u+25CB7V
SLmn1oMeorHFmnKiZfySZ669TTZDxho+LsuhDcSYmBQHOmUM7F6q/x/d6SXpgQLT
/lD/FifHu9eZUxsrymVlMoKYsLqNQE7ookyAW4/TQhzsIOSbmr538OF5J0wR99GS
5O4+wI4wXjUlPRyH7WsjwGHPj9XFiVF9nsVS9P26exc4KvYsD6NHo/opcvM6ZGqY
Svnl93O6M5COgKFR82CRuPj98BcvH1leFDztuizZUIEeQl5yLw32ObKrvNAODm/M
ME132GpaCjsja2WPjkeTp+kvLBsi1o98vTBntDcPEO9fn7gcMGy0l9benvDTdQkb
Zc4UrRb2ymwWbsZt/xJsbcluspV1wXV58Q3/m9gEirKgRUXwQ715A8Tl+13l79nl
pYbwdM+eFptR+oHGRpWjuxfnKDdcAwyiuaWX/6Hgo5DT562hmCC9ohGYG9qAVtK0
rAFm3H+5GOP0S5D8gxooUyDGPNaO0nbUzP6QjDDpS9TgAr2NBwLI/erQF4PgJg9P
Y39UgfMPcsFf3GoMnncTZ7w+JfZ+1Lou1nZIKDZQAqds+LX4FyTqoXc9Lg6Z2WjS
5tWvLxx1JXk=
=G5kh
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Changes to the way Java packages are built

[Duncan]

Alec Warner <antarus@gentoo.org> posted 44958E4A.6010000@gentoo.org,
excerpted below, on  Sun, 18 Jun 2006 13:32:58 -0400:

> May I ask, because I'm very confused, wtf is freedomware?
> 
> I can only assume you mean oss/free java?

As distinct from "freeware", and also known as Free or Libre Software,
libre being translated free as in freedom (where freeware in common usage
means free as in beer, or sometimes free as in deliberately public domain,
neither one of which is appropriate here), thus libre software ==
libreware == freedomware (and as opposed to slaveryware aka
another-is-your-master-ware, xref the sig).

Some here don't care.  That's fine -- for them.  It's a bit bigger
than that for me, but they don't ask me to run what is to me slaveryware,
and I won't ask them to give up what is to them "convenienceware".

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Re: Re: Changes to the way Java packages are built

[Bob Young]

> Some here don't care.  That's fine -- for them.  It's a bit bigger
> than that for me, but they don't ask me to run what is to me slaveryware,
> and I won't ask them to give up what is to them "convenienceware".
> 


I certaintly support your right to choose such a standard for yourself, however I don't think the basic premise that "if you use the program, he is your master" actually has any significance in regards to "slaveryware" versus "freedomware," at least as far as most people are concerned. 

The vast majority of "average" people don't have the skill or in most cases, the desire to examine, modify, or understand the inner workings of the software they use. 

So whatever it is that makes "freedomware" free in your opinion, has little impact for the vast majority of users. For them it's still someone else who is the "master" of the program. It really makes little difference exactly who that some one else is.

> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 

-- 
Regards,
Bob Young
Software Engineer
San Jose, CA.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changes to the way Java packages are built

[Joshua Nichols]

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

Duncan wrote:
> Joshua Nichols <nichoj@gentoo.org> posted 4495739A.3040603@gentoo.org,
> excerpted below, on  Sun, 18 Jun 2006 10:39:06 -0500:
> 
>> I have written documentation on switching to the new system, from the
>> user's perspective, over at our wiki [6]
>>
>> [6]
>> https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay
> 
> Are there instructions somewhere for keeping to a 100% freedomware
> solution?  I've been wondering about installing Java, but don't consider
> slaveryware a viable local option, thus the question. (FWIW, in the general
> case I couldn't install whatever binary legally if I wanted to, since I
> couldn't agree to the EULA, tho I've not examined the Sun/Blackdown EULAs
> recently to see if this would apply there, as they still aren't
> freedomware and are thus still not an option.)
> 
> If it's not yet possible (or no documentation that will work for a non-Java
> guy), is there a timetable?  No rush or even pressure to do it if you
> aren't, but thought I'd ask while the topic is hot.  I did try the given
> URL as well as the Gentoo Java Guide, but the former seemed to presuppose
> someone already involved in testing (understandable at this stage), and
> the latter didn't seem to mention any of the newer 100% freedomware
> alternatives I keep reading about.  Thus, there was no answer I could grok.

This is a bit off topic for the subject at hand...

That being said... one of our users has been working on using GCJ to
this end:

https://projects.gentooexperimental.org/expj/wiki/GCJ_as_a_JDK

As for why this hasn't been done already or more work isn't being done,
I believe there are two reasons:

1) We don't have the same restriction as Fedora and Debian do with
regard to licensing. If we did, then we'd have a more pressing need to
use 'free' Java implementations to even distribute Java stuff.

2) No one has stepped up with the desire / motivation / skills to make
it happen. Not only that, but the Java team in generally has been
understaffed for some time now.


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

iD8DBQFElZF98ATTzZyw6sMRAmPRAJ9h/dcuRWayki0wmICgsataMdibOQCeKXMU
PyYu7srJmtjejwJZxQVtFUU=
=ZQQc
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Changes to the way Java packages are built

[Duncan]

Joshua Nichols <nichoj@gentoo.org> posted 4495917D.8000206@gentoo.org,
excerpted below, on  Sun, 18 Jun 2006 12:46:37 -0500:

> That being said... one of our users has been working on using GCJ to
> this end:
> 
> https://projects.gentooexperimental.org/expj/wiki/GCJ_as_a_JDK

Thanks.

> As for why this hasn't been done already or more work isn't being done,
> I believe there are two reasons:
> 
> 1) We don't have the same restriction as Fedora and Debian do with
> regard to licensing. If we did, then we'd have a more pressing need to
> use 'free' Java implementations to even distribute Java stuff.
> 
> 2) No one has stepped up with the desire / motivation / skills to make
> it happen. Not only that, but the Java team in generally has been
> understaffed for some time now.

Understood.  As I said, no pressure from me to do it if it's not being
done already.  I just wondered what the status and chances were, thinking
if I was lucky a freedomware config might be one of the choices, and this
answers that to my satisfaction.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to the way Java packages are built

[Francesco Riosa]

I'm surprised from the lack of "Thanks a lot Java Team", so please let
me have the honour to be the first on this ml ;-)

The work done has been impressive, the number of package involved great,
thanks _a_lot_ for all you did.

Francesco R.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to the way Java packages are built

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

First off - good work Java Team :)

On Sun, 18 Jun 2006 10:39:06 -0500
Joshua Nichols <nichoj@gentoo.org> wrote:

> [...] Additionally, an environment
> variable, GENTOO_VM, can be used to specify the VM used at a given
> instance. GENTOO_VM should be the name of a VM located
> in /usr/lib/jvm. So with regard to what VM is used, first GENTOO_VM
> is checked, then the user VM (for non-root users), and then lastly
> the system VM.

A better name for this would be GENTOO_JVM, as the Java VM isn't the
only type of virtual machine out there.

Any chance java-config* could be reworked as one or more eselect
modules?

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] Changes to the way Java packages are built

[Joshua Nichols]

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

Kevin F. Quinn wrote:
> First off - good work Java Team :)
> 
> On Sun, 18 Jun 2006 10:39:06 -0500
> Joshua Nichols <nichoj@gentoo.org> wrote:
> 
>> [...] Additionally, an environment
>> variable, GENTOO_VM, can be used to specify the VM used at a given
>> instance. GENTOO_VM should be the name of a VM located
>> in /usr/lib/jvm. So with regard to what VM is used, first GENTOO_VM
>> is checked, then the user VM (for non-root users), and then lastly
>> the system VM.
> 
> A better name for this would be GENTOO_JVM, as the Java VM isn't the
> only type of virtual machine out there.

Good point. I actually had thoughts of changing it to JAVA_VM, so it'd
be distro-neutral. Changing this should be pretty painless, and mostly
involve doing a few in-place seds.

> Any chance java-config* could be reworked as one or more eselect
> modules?

I forgot to mention, but there is an eseelct module, for selecting /
displaying the user and system VM.

Josh.

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

iD8DBQFElosr8ATTzZyw6sMRAi1GAJ0YW0tH2jqpm0lqayXjUOSOcgp0sQCfe1vq
VI1vPfTqQFmVNvuHfQAtqWE=
=Ym0O
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to the way Java packages are built

[Joshua Nichols]

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

Joshua Nichols wrote:
> = Background =
> 
> As some might have noticed, Java 1.5 has been package.masked for some
> time now. There are a number of issues introduced with 1.5 that have
> kept it in package.mask. Please see the Java 1.5 FAQ [1] for more details.
> 
> [1] http://www.gentoo.org/proj/en/java/tiger-faq.xml
> 
> About a year ago, work was begun on improving our part of the build
> system (read: Java related eclasses and our java-config tool) in a way
> to make it much more flexible in general, but specifically improve it to
> get around the known issues. It took about six months to fully develop.
> Unfortunately, the new system was not quite a drop-in replacement. So,
> it took from then until now to determine how to migrate from the current
> system  to the new one in a sane way.
> 
> 
> = The Current System =
> 
> To give some proper background, it is worth going over the current
> system briefly.
> 
> == The Java Virtual Machine ==
> Each Java Virtual Machine (VM) installs an environment file into
> /etc/env.d/java. These files contain information about where JAVA_HOME
> is, the PATH to include, etc.
> 
> VMs traditionally get installed at /opt/${P}
> 
> We have the concept of a 'system' VM and a 'user' VM. The system VM is
> the default VM that will be used for root, and for users who haven't
> selected a user VM. The user VM is, as one might guess, selected on a
> per user basis. It is worth noting that root always uses the system VM,
> and as a result, packages use the system VM when being merged by emerge.
> 
> java-config is used to set the system and user VM. When you do so, the
> appropriate file from /etc/env.d/java is copied to/etc/env.d/20java for
> the system VM or to ~/.gentoo/java-env for the user VM.
> 
> java-config's notion of the current VM is tied entirely to the
> environment, specifically to JAVA_HOME. Therefore, if you change the
> system VM, you'd need to run env-update and then resource /etc/profile.
> Likewise, changing the user VM involves sourcing ~/.gentoo/java-env.
> 
> The fact that you're tied to the environment is annoying, because as
> mentioned, you need re-source the appropriate files. Now imagine you
> have a ton of terminals open... you'd have to source the environment
> files from each one.
> 
> == Packages ==
> 
> When a Java package is built, information about it is saved in
> /usr/share/${PN}-${SLOT}/package.env (or /usr/share/${PN}/package.env if
> SLOT == 0). In particular, the jars that are associated with the package
> are recorded, as well as which jars from other packages are used.
> java-config can later be used to query for this information.
> 
> == Eclasses ==
> 
> There are currently 3 eclasses: java, java-pkg, and java-utils.
> 
> java.eclass is used for packages which provide a VM.
> java-pkg.eclass is used for most Java packages. It provides tools for
> querying installed jars, and for installing various Java related files.
> java-utils.eclass provides a few utility functions for dealing with Java
> stuff.
> 
> = The New System =
> 
> == The Java Virtual Machine ==
> In addition to the concept of a system and a user VM, the new system has
> a build VM. As the name implies, the build VM is used for building
> packages (instead of the system VM). Sane defaults are defined on a per
> platform basis at /usr/share/java-config-2/config/jdk-defaults.conf [3].
> The build VM can further be configured by
> /etc/java-config-2/build/jdk.conf [4] .
> 
> [3]
> https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk-defaults-x86.conf
> [4]
> https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk.conf
> 
> For each Java release (ie 1.3, 1.4, 1.5, etc), you can specify which
> vendor and version to use at build time.
> 
> In addition to being installed to /opt/${P}, VMs also now have a symlink
> in /usr/lib/jvm/${PN}-${SLOT}. The purpose of these symlinks is
> explained further down.
> 
> The user and system VMs are now represented by symlinks pointing to VMs
> located in /usr/lib/jvm/. The system VM lives at
> /etc/java-config-2/current-system-vm, and the user VM at
> ~/.gentoo/java-config-2/current-user-vm . Additionally, an environment
> variable, GENTOO_VM, can be used to specify the VM used at a given
> instance. GENTOO_VM should be the name of a VM located in /usr/lib/jvm.
> So with regard to what VM is used, first GENTOO_VM is checked, then the
> user VM (for non-root users), and then lastly the system VM.
> 
> 
> All the trusty java binaries, ie java, javac, javadoc, jar, etc, now get
> wrappers installed into /usr/bin. These are actually symlinks to
> /usr/bin/run-java-tool. This is a script which will figure out which
> tool was invoked, and then determine which VM to used using the method
> mentioned above.
> 
> == Packages ==
> 
> We now save more information about the build environment at build time
> for each package. This information is saved at
> /usr/share/${PN}-${SLOT}/package.env. This is facilitate troubleshooting
> bugs. Specially, we collect the VM dependency is (ie >=virtual/jdk-1.4),
> what -source and -target were used , and which VM. We also keep track of
> where javadocs get installed, and where Java sources get installed,
> which are useful for integrating into IDEs like netbeans and eclipse.
> 
> == Eclasses ==
> 
> For each eclass we previously had, we have a updated version of the
> eclass, in addition to a few totally new eclasses.
> 
> java-utils-2.eclass
> 	A utility eclass. All utility functions live here (as opposed to being
> spread between java-pkg and java-utils). Among other things, there are
> functions for figuring out which VM should be used for building, based
> on the DEPEND of a package (ie the virtual/jdk atom), and set GENTOO_VM
> accordingly.
> 
> java-pkg-2.eclass
> 	The eclass the Java-only packages should inherit. It uses phase hooks
> in order to make sure that the environment is setup properly for each phase.
> 
> java-pkg-opt-2.eclass
> 	Similar to java-pkg-2, except this is for packages that have optional
> Java support, ie a USE flag. Phase hooks are again used to ensure the
> environment is setup properly for each phase.
> 
> java-ant-2.eclass
> 	Packages that build using ant should inherit this eclass. Essentially,
> this is eclass will ensure that build.xml files get rewritten such that
> javac tasks have the right source and target attributes. In other words,
> it makes sure that the right version bytecode gets compiled.
> 
> java-vm-2.eclass
> 	This is the successor to java.eclass, but more aptly name.
> 
> = Letting the Systems Coexist =
> 
> Originally, the new eclasses were a replacement for the current
> eclasses, ie java-pkg-2 used to still be java-pkg, and java-utils-2 used
> to be still be java-utils. Additionally, java-config was unslotted, so
> the new version of it replaced the current one. Unfortunately, it was
> realized that the new system was not a 100% drop-in replacement for the
> current one, so we set forth with the task to find a way to migrate from
> one to the other.
> 
> The method we decided on was to have the concept of having a
> 'generation' for each system, where the generation consists of the
> eclasses, a version of java-config, and the tools that support it. To
> cope with java-config, it is now slotted, and installs
> /usr/bin/java-config-<insert generation here> . There is then a wrapper
> for java-config at /usr/bin/java-config, which reads a variable
> WANT_JAVA_CONFIG to determine which java-config to use, or if not
> specified, the most recent version. The eclasses then export the
> appropriate value of WANT_JAVA_CONFIG to get the right version of
> java-config they need.
> 
> The existing eclasses and java-config-1.x will be 'generation 1'. The
> new eclasses and java-config-2.x will be 'generation 2'.
> 
> The first packages to be migrated to generation 2 will be the VMs. When
> installed, they will also install environment files that are compatible
> with generation 1. This will allow you to have both a system VM for
> generation 1, in addition to the system and build VM for generation 2.
> The consequence of this is that ebuilds using generation 1 will continue
> to build/run as they previously did, while allowing packages to be
> migrated to use generation 2 on a package-by-package basis.  So, all
> existing ebuilds will continue to work, and will be replaced
> incrementally during our migration.
> 
> A note on Java 1.5 here... The 1.5 JDKs don't install a generation-1
> compatible environment file. This is to prevent the problems already
> describe with 1.5, and should prevent them from happening. At this
> point, we should be able to unmask the 1.5 JDKs. So 1.5 will be
> available, but only to generation-2 packages.
> 
> The next packages to be migrated will be ones that need the features of
> the new generation. In particular, this means packages which need Java
> 1.5 to build and/or run.
> 
> Once these packages have been migrated, the rest of the tree which uses
> Java will be migrated as expediently as possible. I've written some
> notes about how to migrate over on our wiki [5]
> [5] https://projects.gentooexperimental.org/expj/wiki/Migrating_packages
> 
> = Using the new system =
> 
> I have written documentation on switching to the new system, from the
> user's perspective, over at our wiki [6]
> 
> [6]
> https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay
> 
> = Feedback =
> 
> Obviously, these aren't exactly light changes that need to be made.
> Therefore, it's important to get as much feedback as possible, and to
> make the upgrade process as smooth as possible.
> 
> I'd hope to get these changes put into the tree in the next week or two,
> pending feedback. This development has been a long time in the making,
> and the Java 1.5 problem has been a thorn in our side for long enough.

My apologies if I didn't make it clear, but I should point out that
these changes are slightly disruptive to the end-user. By this, I mean
there are actions that the user would need to take aside from just doing
an emerge world. The steps needed are outlined in the
using_migration-overlay wiki page [1]

[1]
https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay

So... I really would like as much feedback in particular on switching
over to the new system from the user's perspective. I'd like to get the
process as streamlined as to suppress as much pain and suffering as
possible...

Regards,

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

iD8DBQFElzzD8ATTzZyw6sMRAnbrAJ9dmcuXTNeKeD8DjhwSNlEDAGUHRQCfbIrQ
DfNSwV4XbWbU+69o2dxshMY=
=YH4V
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list