diff options
| author |   Patrice Clement <monsieurp@gentoo.org> | 2015-06-18 21:19:31 +0000 |
|---|---|---|
| committer | Patrice Clement <monsieurp@gentoo.org> | 2015-06-18 21:19:31 +0000 |
| commit | 9f443d8001eb04146130eef2a105fda4fd51c292 (patch) | |
| tree | adc5b4f543101080ad4c6d6e33664b40f9c716a7 /xml | |
| parent | fix patch (diff) | |
| download | gentoo-9f443d8001eb04146130eef2a105fda4fd51c292.tar.gz gentoo-9f443d8001eb04146130eef2a105fda4fd51c292.tar.bz2 gentoo-9f443d8001eb04146130eef2a105fda4fd51c292.zip | |
Proceed with wiki migration and delete old site content for good. Keep meeting minutes around until they get moved over to projects.g.o. See bug 538354.
Diffstat (limited to 'xml')
| -rw-r--r-- | xml/htdocs/proj/en/java/ant-guide.xml | 306 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/bugs.xml | 86 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/getting-involved.xml | 265 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/index.xml | 233 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/java-devel.xml | 1078 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/java-upgrade.xml | 199 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/tiger-faq.xml | 94 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/tomcat-guide.xml | 427 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/tomcat6-guide.xml | 415 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/why-build-from-source.xml | 92 | ||||
| -rw-r--r-- | xml/htdocs/proj/en/java/why-we-need-java-14.xml | 165 |
11 files changed, 0 insertions, 3360 deletions
diff --git a/xml/htdocs/proj/en/java/ant-guide.xml b/xml/htdocs/proj/en/java/ant-guide.xml deleted file mode 100644 index 60bb1ceb46..0000000000 --- a/xml/htdocs/proj/en/java/ant-guide.xml +++ /dev/null @@ -1,306 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide lang="en"> - <title>Ant Guide</title> - - <author title="Author"> - <mail link="caster@gentoo.org">Vlastimil Babka</mail> - </author> - <author title="Editor"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> - </author> - <abstract> - This document provides information on using Apache Ant on Gentoo - </abstract> - - <!-- The content of this document is licensed under the CC-BY-SA license --> - <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> - <license/> - - <version>1.5</version> - <date>2008-01-18</date> - - <chapter> - <title>Split-Ant</title> - <section> - <body> - <p> - Since version 1.7.0, the way of packaging and using optional tasks - in Apache Ant has changed substantionally. Previously, Ant was split - into ant-core (the core .jar files) and ant-tasks (.jar files for - all the optional tasks, most of which have quite a number of external - package dependencies). Ant-tasks symlinked its jars into the - ant-core/lib to be loaded. Dependencies of these optional tasks were - hardcoded into the ant startup script and tried to be loaded even if - they (or ant-tasks) were not installed. This way they would pollute - the classpath for building and cause packages that also depend on - some of these to build even without the dependencies recorded in - ebuild and package.env. - </p> - <p> - With the new split-ant setup, each .jar file that made up ant-tasks - package is installed as separate package (named ant-* as the jar - file itself), specifying just the dep(s) it itself needs. The jars - are not symlinked to ant-core/lib but instead, the presence of the - package is recorded by touching a file named - <path>/usr/share/ant/tasks-${PV}/${PN}</path>. Ant startup script is - modified so that by default it looks into this directory and loads - the tasks and their deps for backwards compatibility. But the real - power lies in the ANT_TASKS variable (used in ebuild or by ant user) - which can override this default behaviour and specify only the tasks - you want it to load. To sum up, the advantages of new layout are: - </p> - <dl> - <dd> - <ul> - <li> - Reduced dependencies of packages that need more than ant-core - (instead of depending in whole ant-tasks with its almost 20 - direct dependencies, you specify only those you want) - </li> - <li> - Less classpath pollution, no hardcoded dependencies inside ant - startup script (see above) - </li> - <li> - Easy to find if you need more than ant-core to build a package - (with old setup you would have to unmerge ant-tasks to test if - package fails without them) - </li> - <li> - Allows us to have junit3 and junit4 in separate slots and - choose which one to load in ant - </li> - <li> - Better controlled build of the jars, instead of a - manifest-only jar it will fail if there's something wrong with - the dependency package - </li> - <li> - Full backward compatibility with existing ebuilds - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>End User Documentation</title> - <section> - <title>Migrating to Ant 1.7.0</title> - <body> - <p> - To make the transition possible, dev-java/ant-core-1.7.0 needs to - block on older versions of dev-java/ant-tasks and dev-java/ant. So - when you encounter this block, just unmerge ant-tasks and ant, and - reissue the emerge command that caused it. If you don't use Ant - yourself, that's all you need to know. - </p> - </body> - </section> - - <section> - <title>Working with new setup</title> - <body> - <p> - If you use ant for your own Java development, you should be aware of - few things. If you use only the tasks provided by Ant, there will not - be any difference if you install the whole dev-java/ant meta-package. - But the external libraries that used to symlink their .jar files into - <path>/usr/share/ant-core/lib</path> to be loaded, will soon stop - creating these symlinks. In order to load these libraries, you will - now need to use the new ANT_TASKS environment variable, which takes - space-separated list of packages to load. - </p> - <p> - Example of ant invocation with pmd and checkstyle libraries: - <c>ANT_TASKS="pmd checkstyle" ant</c> - </p> - <p> - You can also use this variable to load libraries that didn't - previously symlink into ant-core/lib, without the need to pass the - full path with the -lib <path>/path/to/jar</path> parameter. - </p> - </body> - </section> - </chapter> - - - <chapter> - <title>Ebuild Developer Guide</title> - <section> - <body> - <p> - A developer writing ebuilds has to generally take care about two - things - dependencies and ANT_TASKS variable. For dependencies, if - you previously needed only dev-java/ant-core (which is added by - java-ant-2 eclass automatically), nothing changes. But if your ebuild - needed full dev-java/ant or dev-java/ant-tasks to compile, you should - figure out which exact optional tasks are needed (more on that later) - and specify them in DEPEND. Then, you need to list the tasks in - ANT_TASKS variable before calling eant (can be different for each - eant call). In the most simple case, the tasks you need don't depend - on useflags, you don't care about specific versions and all eant() - calls in your ebuild need the same set of tasks. Then you just list - the tasks you need in WANT_ANT_TASKS variable *before* inheriting - java-ant-2.eclass, and it will fill the DEPEND and ANT_TASKS for - you. In the more complex cases, you have to specify all the depends - yourself (maybe based on USE flags) and ANT_TASKS for each eant call - (also maybe based on USE flags). Typically you do this with test - flag and ant-junit. - </p> - </body> - </section> - - <section> - <title>Env variables to use and know how they work</title> - <body> - <dl> - <dd> - <ul> - <li> - ANT_TASKS - $IFS-separated list of optional tasks (ant-foo) or - even external libraries ant can use (xjavac...) to load. Used - by eant. You can't set this in ebuild global scope, use only - inside <c>src_compile()</c> or <c>src_test()</c> - </li> - <li> - WANT_ANT_TASKS - like ANT_TASKS, but you specify this before - inheriting java-ant-2 and it can contain only ant-* tasks. Will - be translated into dev-java/ant-* in DEPEND and used as default - ANT_TASKS if you don't set (override) it yourself. - </li> - <li> - EANT_ANT_TASKS - if you use the default <c>src_compile()</c> of - java-pkg-2, and can't use WANT_ANT_TASKS for some reason, - set this in the global scope to pass ANT_TASKS value to it. - </li> - <li> - JAVA_PKG_FORCE_ANT_TASKS - like ANT_TASKS, but you don't use - this in ebuild, but in the env, overrides any ANT_TASKS and - WANT_ANT_TASKS set in the ebuild (in eant, does not bring the - deps, because of portage dep caching). Can be used to easily - hash out which tasks you need when writing the ebuild, without - need to alter it each time. - </li> - </ul> - </dd> - </dl> - <p> - Here are the order of how eant() processes these variables to - export the final ANT_TASKS for calling the ant script, from highest - lowest priority of overriding. - </p> - <dl> - <dd> - <ul> - <li> - JAVA_PKG_FORCE_ANT_TASKS (set in the environment) - </li> - <li> - ANT_TASKS (set in the src_* function calling <c>eant()</c>) - </li> - <li> - EANT_ANT_TASKS (for java-pkg-2 default <c>src_compile()</c>) - </li> - <li> - WANT_ANT_TASKS (set in the ebuild global scope before inherit) - </li> - <li> - "none" (the default) - </li> - </ul> - </dd> - </dl> - </body> - </section> - - <section> - <title>Typical workflow</title> - <body> - <p> - Usually you start with dev-java/ant-core as dependency - ( added automatically with java-ant-2 eclass ) and see - if you can compile the package. If it fails, see what class was - missing and see the next section to determine what ant-* package you - need to use. The failure looks like this: - </p> -<pre caption="Sample missing task error"> -[junitreport] java.lang.ClassNotFoundException?: org.apache.tools.ant.taskdefs.optional.TraXLiaison -</pre> - <p> - Here you can see that the failing task was junitreport, and the - class it was missing. - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Implementation details (dev-java/ant* maintainer notes)</title> - <section> - <title>Build system (build.xml) changes</title> - <body> - <p> - All ant-* ebuild share the same source tarball. Upstream's build.xml - is already building different .jar files based on the classes - dependencies, and there are selectors for the right source files. But - it's using <available> statements to determine if dependency - is present on classpath, and if not, it builds a manifest-only jar - (or no jar at all, there's now a property for that in 1.7). We modify - the build.xml to have separate target for core jars and target for - the optional jars, where a property tells it which jar we want - (easier to add 20 target differing just in name). We also make sure - that only the source we want in the jar is compiled, and used for - resolving internal class dependencies. Rest of these dependencies - (for the optional jars) is resolved from symlinked ant.jar from the - ant-core already installed on system, and in some cases also from - ant-nodeps.jar (ant-nodeps package). This makes sure that all - internal dependencies are represented with DEPEND variable in the - ebuild and package.env. - </p> - </body> - </section> - - <section> - <title>Launcher script changes</title> - <body> - <p> - Ant's launcher script now recognizes ANT_TASKS environment variable. - The value is IFS-separated list of packages (in our usual - package-slot format as recognized by java-config -p) that are - translated to list of jar files (using java-config) and passed to - ant with -lib parameter. There are also special values "none" and - "all" (the default if not defined at all or empty). If "none" is - specified, the only jars loaded by ant are those in - <path>/usr/share/ant-core/lib</path>. This means no optional tasks, - since they no longer symlink to here. Value of "all" will make the - script load all tasks registered in - <path>/usr/share/ant/tasks(-version)</path>. The value of list can - specify any ant-* tasks that are part of the ant distro itself, but - also any external packages providing ant tasks (xjavac, - ant-owanttasks) or in fact any package that provides something ant - tasks can use (rhino for script tasks...). - </p> - </body> - </section> - - <section> - <title>Eclasses</title> - <body> - <p> - We added one new eclass - ant-tasks.eclass used by the ant-* - packages. Makes use of the shared build system, so ebuilds themselves - only have to define few specific things. Is pretty well commented, - so no details needed here. Few other java eclasses were modified to - make use of the new features in other ebuilds. This is mostly about - handling the ANT_TASKS variable and its friends WANT_ANT_TASKS and - JAVA_PKG_FORCE_ANT_TASKS - see the developer docs. All changes and - additions here are also commented. - </p> - </body> - </section> - </chapter> -</guide> diff --git a/xml/htdocs/proj/en/java/bugs.xml b/xml/htdocs/proj/en/java/bugs.xml deleted file mode 100644 index 122fa3dcf1..0000000000 --- a/xml/htdocs/proj/en/java/bugs.xml +++ /dev/null @@ -1,86 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> - -<guide lang="en"> -<title>Gentoo Java Bugs</title> -<author title="Author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> -</author> - -<abstract>This guide discusses bugs which belong to the Java project</abstract> -<version>1.0</version> -<date>2005-12-17</date> - -<chapter> -<title>Introduction</title> -<section> -<body> -<p>The purpose of this guide is to provide background information for some of the outstanding Java bugs on Gentoo. There currently are around 180 open bugs, which might be a little overwhelming for your weekend bug squasher. So, we hope to divide the bugs into categories, and provide some background information.</p> -</body> -</section> -</chapter> - -<chapter> -<title>Metabugs</title> -<section> -<body> - <p>Coming soon...</p> -</body> -</section> -</chapter> - - -<chapter> - <title>Useful Queries</title> - <section> - <body> - - <table> - <tr> - <th>All Java bugs:</th> - <ti></ti> - <ti><uri link="http://tinyurl.com/n9qb">list</uri></ti> - </tr> - <tr> - <th>Java bugs, by priority</th> - <ti></ti> - <ti> - <uri link="http://tinyurl.com/au29a">P1</uri>, - <uri link="http://tinyurl.com/b8xbv">P2</uri>, - <uri link="http://tinyurl.com/8jfns">P3</uri>, - <uri link="http://tinyurl.com/98bt4">P4</uri>, - <uri link="http://tinyurl.com/bfa2n">P5</uri> - </ti> - </tr> - <tr> - <th>Bundled jars:</th> - <ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=69972">metabug</uri></ti> - <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=blocked&type0-0-0=anywordssubstr&value0-0-0=69972&field0-0-1=bug_id&type0-0-1=equals&value0-0-1=69972">list</uri> </ti> - </tr> - <tr> - <th>Maven:</th> - <ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=63285">metabug</uri></ti> - <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=blocked&type0-0-0=anywordssubstr&value0-0-0=63285&field0-0-1=bug_id&type0-0-1=equals&value0-0-1=63285">list</uri></ti> - </tr> - <tr> - <th>JBoss:</th> - <ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=64795">metabug</uri></ti> - <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=blocked&type0-0-0=anywordssubstr&value0-0-0=64795&field0-0-1=bug_id&type0-0-1=equals&value0-0-1=64795">list</uri></ti> - </tr> - <tr> - <th>Ebuild submissions:</th> - <ti></ti> - <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=EBUILD&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=maintainer-wanted%40gentoo.org&emailcc2=1&emailtype2=substring&email2=java%40gentoo.org&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">list</uri></ti> - </tr> - <tr> - <th>Ebuild requests:</th> - <ti></ti> - <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=REQUEST&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=maintainer-wanted%40gentoo.org&emailcc2=1&emailtype2=substring&email2=java%40gentoo.org&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">list</uri></ti> - </tr> - </table> - - </body> - </section> -</chapter> -</guide> -<!-- vim: set expandtab ts=2 --> diff --git a/xml/htdocs/proj/en/java/getting-involved.xml b/xml/htdocs/proj/en/java/getting-involved.xml deleted file mode 100644 index aefee2258c..0000000000 --- a/xml/htdocs/proj/en/java/getting-involved.xml +++ /dev/null @@ -1,265 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide lang="en"> - <title>Getting Involved</title> - - <author title="Author"> - <mail link="betelgeuse@gentoo.org">Petteri Raty</mail> - </author> - <author title="Author"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> - </author> - - <abstract> - This document provides information on how one can get involved and - help out with the Gentoo Java Project. - </abstract> - - <!-- The content of this document is licensed under the CC-BY-SA license --> - <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> - <license/> - - <version>1.7</version> - <date>2008-01-31</date> - - <chapter> - <title>Overview</title> - <section> - <body> - <p> - This document aims to provide information on how one can get - involved and help out with the Gentoo Java Project. The following - are ideas of areas and ways one can help out. Due to the volume of - inquiries at times. It's more effective and efficient to provide - those looking to get involved with some detailed guidance via this - document. - </p> - <p> - This document is just a guide, not a how to. For questions not - address in this document. Please get in touch with the active - developers and contributors via participation on either IRC or our - mailing list. - </p> - <p> - Comments, thoughts, and feedback on this document is greatly - appreciated and welcomed. - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Testing</title> - <section> - <body> - <dl> - <dd> - <ul> - <li> - Compile them with a bunch of jdks (at least stable marked - ibm-jdk-bin and sun-jdk versions should be installed locally). - Here's a simple script to - <uri link="http://overlays.gentoo.org/proj/java/browser/scripts/compile-with-all-jdks">compile with all jdks</uri> - . - </li> - <li> - Check with USE="doc" that javadocs install to - <path>/usr/share/doc/${PF}/html/api</path> - If the ebuild installs them elsewhere for example to keep html - documentation links working, there should still be a symlink - </li> - <li> - run <c>FEATURES="test" USE="test" ebuild <ebuild> clean install</c> - (not all java packages have unit tests) - </li> - <li> - compile all reverse dependencies if we are talking about a - version bump (<c>!rdep <pkg></c> to jeeves on IRC for example) - </li> - <li> - Check - <uri link="http://overlays.gentoo.org/proj/java/browser/testcases">source:testcases</uri> - if the package has testcases in our svn. - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Development</title> - <section> - <body> - <p> - The most obvious way to help out is with development. This means - improving existing ebuilds, updating ebuilds for new versions of - packages, and working on ebuilds for new packages. - </p> - <dl> - <dd> - <ul> - <li> - Create ebuilds for ebuild request bugs or for packages you use - and/or need packaged. Attaching contributed ebuild and/or patch - as an attachment to any bugs. - </li> - <li> - File bugs with patches attached for any existing ebuilds that - are outdated and/or need to be bumped to the latest release. - </li> - <li> - Test out contribute to completing packages in java overlays. - Usually java-experimental overlay which is not available - via layman. It must be checked out manually. - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Bugs</title> - <section> - <title>Reporting</title> - <body> - <p> - Software is bound to have bugs. Reporting bugs found is very - important, because there may be some USE cases or scenarios that - developers may not have accounted for. Without reporting the - bugs might go unnoticed and never be fixed. Leaving it for - others to run into just as you have. - </p> - </body> - </section> - <section> - <title>Squashing</title> - <body> - <p> - The number of open bugs assigned to the Java team is a bit - astounding. Any help with squashing them is always appreciated. - </p> - <p> - <uri link="http://tinyurl.com/n9qb">Bugs assigned to the Java Team</uri> - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Community</title> - <section> - <title>IRC</title> - <body> - <p> - Hang around #gentoo-java. It small, yet bustling little channel in - our corner of freenode. The primary developers of Java on Gentoo are - there most of the time. The channel is like the pulse of the Java - team, where most interaction takes place. This means you'll see - development as it is happening. - </p> - <p> - Simply being around showing support is nice. Contributing to - discussions that come up, or troubleshooting bugs that arise would - be even better. - </p> - </body> - </section> - <section> - <title>Mailing List</title> - <body> - <p> - Joining our - <uri link="http://www.gentoo.org/main/en/lists.xml"> - gentoo-java mailing list - </uri> and asking/answering questions. - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Documentation</title> - <section> - <title>Writing</title> - <body> - <p> - Helping us write documentation is always appreciated. - </p> - </body> - </section> - <section> - <title>Reading</title> - <body> - <p> - Useful documentation for people wanting to help can be found in: - </p> - <dl> - <dd> - <ul> - <li> - <uri>http://devmanual.gentoo.org/</uri> - </li> - <li> - <uri>http://www.gentoo.org/proj/en/devrel/quiz/</uri> - </li> - </ul> - </dd> - </dl> - </body> - </section> - <section> - <title>Documentation on Java ebuild writing</title> - <body> - <p> - Useful documentation for people wanting to write Java ebuilds: - </p> - <dl> - <dd> - <ul> - <li> - <uri link="java-devel.xml">Gentoo Java Developer Guide</uri> - </li> - <li> - <uri link="ant-guide.xml">Gentoo Ant Guide</uri> - </li> - <li> - <uri link="http://overlays.gentoo.org/proj/java/wiki/Migrating_packages">Differences between Generation 1 and 2</uri> - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Evangelism</title> - <section> - <body> - <p> - Spreading the word about Gentoo as a Java development platform. - </p> - </body> - </section> - </chapter> - - <chapter> - <title>More</title> - <section> - <body> - <p> - So you want to do more eh? Well you can always put in the effort to - become a official Gentoo Developer. Please refer to - <uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2"> - Becoming a Developer</uri> in the - <uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml"> - Gentoo Developer Handbook</uri>. - </p> - </body> - </section> - </chapter> -</guide> diff --git a/xml/htdocs/proj/en/java/index.xml b/xml/htdocs/proj/en/java/index.xml deleted file mode 100644 index 16d552cd17..0000000000 --- a/xml/htdocs/proj/en/java/index.xml +++ /dev/null @@ -1,233 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?> -<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> -<!DOCTYPE project SYSTEM "/dtd/project.dtd"> -<project> -<name>Java</name> -<longname>The Java Project</longname> -<date>2013-05-08</date> - -<author title="author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> -</author> - -<author title="author"> - <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail> -</author> - -<author title="author"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> -</author> - -<description> -The Java Project handles all Gentoo-related Java things. -</description> - -<longdescription> -<p> -The Java Team maintains most packages related to Java development in the -Portage tree, which at the present time of writing encompass over 350 -different packages. -</p> - -<p> -Highlights include the Apache Java Projects, -JDK/JREs from <uri link="http://www.blackdown.org/">Blackdown</uri>, <uri link="http://java.sun.com/j2se/">Sun</uri>, -<uri link="http://www-106.ibm.com/developerworks/java/jdk/">IBM</uri>, <uri link="http://h18012.www1.hp.com/java/">Compaq</uri>, -<uri link="http://www.jrockit.com/">BEA</uri>, and of course <uri link="http://www.kaffe.org/">Kaffe</uri>. - -We also package some alternative languages for the JVM, -such as <uri link="http://groovy.codehaus.org/">Groovy</uri>, <uri link="http://jruby.sourceforge.net/">JRuby</uri>, and <uri link="http://www.jython.org/">Jython</uri>. - -We package IDEs such as <uri link="http://www.eclipse.org/">Eclipse</uri>, and <uri link="http://www.netbeans.org/">NetBeans</uri>. -And of course, there is a wide variety of Java libraries and applications. -</p> -</longdescription> - - <recruitment> - <job> - <summary>General package maintainer</summary> - <details> - General java package maintainer to help out with managing the herd. - Along with java packages in other herds. Revision bumping, bug - filing/fixing, stabilizing, updating ebuilds per eclass or syntax - changes, etc. - </details> - <requirements> - Experience with Java on Linux, ideally Gentoo. Building java - applications from source. Some experience with ant, build.xmls, - patching java sources, and package build systems. - </requirements> - <contact>java@gentoo.org</contact> - </job> - <job> - <summary>Glassfish package maintainer</summary> - <details> - Package from source and maintain - <uri link="https://glassfish.dev.java.net/">Glassfish</uri> - and related packages. Due to the size of Glassfish, many ebuilds will - need to be created for the various pieces. Possibly even a eclass. - Along with maintaining it all for at least 1 year or longer. Which - includes keeping package current with upstream. Glassfish has several - dependenies required to build from source that will also need to be - packaged and maintained as well. - </details> - <requirements> - 6 months - 1 year experience with Glassfish. Ideally in a production - environment running Gentoo or some flavor of Linux. Ability to work - with Glassfish sources, and build it from source. - </requirements> - <contact>java@gentoo.org</contact> - </job> - <job> - <summary>JBoss package maintainer</summary> - <details> - Package from source and maintain - <uri link="http://www.jboss.com/products/platforms/application">JBoss</uri> - and related packages. Due to the size of JBoss, many ebuilds will - need to be created for the various pieces. Possibly even a eclass. - Along with maintaining it all for at least 1 year or longer. Which - includes keeping package current with upstream. JBoss has several - dependenies required to build from source that will also need to be - packaged and maintained as well. - </details> - <requirements> - 6 months - 1 year experience with JBoss. Ideally in a production - environment running Gentoo or some flavor of Linux. Ability to work - with JBoss sources, and build it from source. - </requirements> - <contact>java@gentoo.org</contact> - </job> - <job> - <summary>Tomcat package maintainer</summary> - <details> - Maintain - <uri link="http://tomcat.apache.org/">Tomcat</uri> - and related packages. Its already packaged and working with a few open - bugs with the effors of William L. Thomson Jr. The volunteer will take - over his work since he will retire soon. Tomcat has several dependenies - required to build from source that will also need to be maintained as well. - </details> - <requirements> - 6 months - 1 year experience with Tomcat. Ideally in a production - environment running Gentoo or some flavor of Linux. Ability to work - with Tomcat sources, and build it from source. - </requirements> - <contact>java@gentoo.org</contact> - </job> - <job> - <summary>Jetty package maintainer</summary> - <details> - Package from source and maintain - <uri link="http://www.mortbay.org/">Jetty</uri> - and related packages. Along with maintaining it all for at least 1 - year or longer. Which includes keeping package current with upstream. - </details> - <requirements> - 6 months - 1 year experience with Jetty. Ideally in a production - environment running Gentoo or some flavor of Linux. Ability to work - with Jetty sources, and build it from source. - </requirements> - <contact>java@gentoo.org</contact> - </job> - <job> - <summary>Maven package maintainer and portage integrator</summary> - <details> - Package from source and maintain - <uri link="http://maven.apache.org/">Maven</uri> - and related packages. Maven itself is packaged from source in the - java-overlay, but needs to be updated, maintained, and added to tree. - At which time Maven, along with Maven repositories need to be - integrated with Gentoo's Java build system. Which presently is designed - entirely around ant. Then maintaining it all for at least 1 year or - longer. Which includes keeping package current with upstream. Most - all dependenies required to build from source have been package - in the java-overlay. They will need to be added to tree and maintained - as well. - </details> - <requirements> - 6 months - 1 year experience with Maven on Gentoo or some flavor - of Linux. Ability to work with Maven sources, and build it from source. - Experience with the Gentoo Java build system and our Java specific - eclasses. - </requirements> - <contact>java@gentoo.org</contact> - </job> - </recruitment> - -<dev role="member" description="General helper">betelgeuse</dev> -<dev role="member" description="Handling ant-related stuff, help with migration, bug squasher">caster</dev> -<dev role="member" description="Minecraft and hopefully more">chewi</dev> -<dev role="member" description="General package maintainer">ercpe</dev> -<dev role="member" description="Maintainer of Netbeans, caring of related packages too">fordfrog</dev> -<dev role="member" description="General package maintainer">sera</dev> -<dev role="member" description="General Java application maintainer and bug squasher.">serkan</dev> - -<resource link="/doc/en/java.xml">User Guide</resource> -<resource link="java-devel.xml">Developer Guide</resource> -<resource link="java-upgrade.xml">Java Upgrade Guide</resource> -<resource link="tiger-faq.xml">Java 1.5 FAQ</resource> -<resource link="tomcat6-guide.xml">Guide for Tomcat 6.0.x on Gentoo</resource> -<resource link="tomcat-guide.xml">Guide for Tomcat 5.x on Gentoo</resource> -<resource link="http://overlays.gentoo.org/proj/java/wiki/overlays">Java Overlays</resource> -<resource link="http://overlays.gentoo.org/proj/java/wiki/">Java Wiki</resource> -<resource link="/main/en/lists.xml">Java Mailing List (gentoo-java)</resource> -<resource link="bugs.xml">Java Bugs</resource> -<resource link="http://news.gmane.org/gmane.linux.gentoo.java">Java Mailing List Archives</resource> -<resource link="irc://irc.freenode.org/#gentoo-java">#gentoo-java on irc.freenode.org</resource> -<resource link="why-build-from-source.xml">Why Build From Source</resource> -<resource link="why-we-need-java-14.xml">Why We Need Java 1.4</resource> -<resource link="getting-involved.xml">Getting Involved</resource> - -<extraproject name="java-config"> - Java environment configuration tool -</extraproject> - -<extraproject name="javatoolkit"> - Gentoo-specific tools for Java -</extraproject> - -<herd name="java"></herd> - -<!-- TODO move to separate file --> -<extrachapter> -<title>Call for help!</title> -<section> -<body> -<p> - We are always looking for more help. We barely have enough - manpower to maintain our 350+ packages. Not to mention packages that - require a dedicated maintainer like Eclipse, Netbeans, Tomcat, Resin, - and several others that are no longer in true for this very reason. - Specifically JBoss and Jetty. Others like Glassfish, Jasper Reports, - OpenJDK/IcedTea, etc. -</p> - -<p> - On top of all that we need time and energy to extend our offering into new - areas. Such as natively compiled Java packages using gcj, providing an all - open source from source Java vm, developing a framework for packaging - webapps, packaging popular webapps themselves, or creation of a stable and - complete J2EE development platform. -</p> - -<p> - There are lots of areas we are in need. We are always seeking new team - members, be it contributors or developers. All efforts are voluntary. - We do not assign tasks or do much deligation of duties. Pretty much - jump in and start helping out is our motto. -</p> - -<p> - If you have any interest in helping please read - <uri link="getting-involved.xml">Getting Involved</uri>. Then get moving on - the ideas suggested in that document. The Java Team members are more - than happy to help at any point along the way. -</p> - -</body> -</section> -</extrachapter> - -</project> -<!-- vim: set expandtab ts=2 --> diff --git a/xml/htdocs/proj/en/java/java-devel.xml b/xml/htdocs/proj/en/java/java-devel.xml deleted file mode 100644 index de597af4e1..0000000000 --- a/xml/htdocs/proj/en/java/java-devel.xml +++ /dev/null @@ -1,1078 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/java/Attic/java-devel.xml,v 1.42 2012/10/28 15:21:08 swift Exp $ --> - -<guide> -<title>Gentoo Java Packaging Guide</title> - -<author title="Author"> - <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail> -</author> - -<author title="Author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> -</author> - -<author title="Author"> - <mail link="betelgeuse@gentoo.org">Petteri Räty</mail> -</author> - -<abstract> -This document serves two purposes. The first is to discuss the specifics of how Gentoo handles the Java platform. The second is to discuss how to package Java packages for Gentoo. This document assumes you are familiar with the Java User Guide. -</abstract> - -<!-- The content of this document is licensed under the CC-BY-SA license --> -<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> -<license/> - -<version>1.0.6</version> -<date>2008-01-18</date> - -<chapter> -<title>Background</title> - -<section> -<body> -<p> -Before going into details of how Java is handled on Gentoo, it is worthwhile to take a few moments to discuss current trends in the Java programming world. -</p> -</body> -</section> - -<section> -<title>Java Build Systems</title> -<body> - -<p> -There are a few build systems commonly used for Java projects. Apache's <c>ant</c> (Another Neat Tool) is by far the most common. It is a task oriented system. This means that you give Ant instructions on what tasks to perform and how to perform them to build your project. For example, compile these source files using this class path, create a jar of these classes, and so on. It is fairly easy to get up and running with Ant. Unfortunately, it leaves a lot of room for variation, so Ant scripts are terribly inconsistent from one project to the next. -</p> - -<p> -<c>Maven</c> is another Apache project which has been gaining popularity. In contrast to <c>ant</c>, it is a project based system. This means that you give maven information about your project, and once that's established, you can do many things without any further configuration. For example, you tell <c>maven</c> your project's name and where your source is, and you can then tell <c>maven</c> "Hey <c>maven</c>, make me a jar and some javadocs too!" Another feature of maven is its ability take care of making a project's dependencies available by downloading them from mirrors. -</p> - -<p> -You can also find a number of packages using the classic combination of autoconf and automake. They will mostly be found on projects that interact with existing C and C++ libraries. Unfortunately, automake and autoconf are used mostly dealing with the non-Java bits, leaving the Java bits wedged where it can fit. -</p> -<p> -Lastly, you may find custom scripts which will attempt to run <c>javac</c>, <c>jar</c>, and <c>javadoc</c> itself, or it may just be a wrapper for ant to properly prepare the build environment. -</p> - -</body> -</section> - -<section> -<title>Bundled Dependencies</title> -<body> - -<p> -One of the features of Java has always been "compile once, run everywhere." A consequence of this is that Java developers traditionally bundle all library dependencies with their project's distribution. While this might be convenient for the end-user, it rapidly becomes problematic from a packager's point of view. -</p> - -<p> -For example, project A depends on C, and project B depends on C, and you have project A and B installed, then you'd have two copies of C installed to support it. And if there's new release of C with a bug or security fix , you would want both A and B to take advantage of it. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Java on Gentoo</title> - -<section> -<body> -<p> -This section will give you more insight into how Gentoo handles Java. You should be familiar with the Java User Guide before proceeding. -</p> -</body> -</section> - -<section> -<title>Virtual Machines (VMs)</title> -<body> -<p> -As discussed in the User Guide, there are several VMs available from portage. -</p> - -<p> -Testing all packages to ensure they build and run with every VM is a huge undertaking, and there simply are not enough resources to guarantee every package will build and run with every VM. -</p> -<p> -We now maintain a list of "supported virtual machines" for each architecture. These are the VMs we will test the packages against before committing changes to portage. When you emerge a package, it will by default try to use the best "supported virtual machine." -</p> - -<p> -Of course, Gentoo and Linux in general are about choice, so if you prefer a different VM over the "supported virtual machines", you can easily use that VM instead. However, you should also know that bugs reported with one of the non-"supported virtual machine" will get a low priority if it isn't present using a "supported virtual machine". -</p> -</body> -</section> - -<section> -<title>Configuring which VM to Use</title> -<body> - -<p> -You can choose which VM to use on a per-user basis, and which VM to use for the system (ie when running things as root). Both of these are configured using java-config. -</p> - -<p> -A user's current VM is represented by a symlink located at <path>~/.gentoo/java-config-2/current-user-vm</path>, if existing. This symlink points to the <c>JAVA_HOME</c> of the chosen VM. Similarly, the system VM is represented by a symlink at <path>/etc/java-config-2/current-system-vm</path>. -</p> - -<p> -The current VM can also be changed on the fly. This can be accomplished setting the environment <c>GENTOO_VM</c> to contain the name of a VM that java-config knows about. -</p> - -</body> -</section> - -<section> -<title>Java Tools</title> -<body> - -<p> -The traditional Java tools, ie, <c>java</c>, <c>javac</c>, <c>javadoc</c>, etc, are all located in /usr/bin. They are actually all symlinks to the <c>run-java-tool</c> script. This script will call the appropriate tool, depending on how the script is invoked, from the current VM. <c>GENTOO_VM</c> is first checked, then the user VM, and lastly the system VM. -</p> - -</body> -</section> - -<section> -<title>Build-time VM Switching</title> -<body> - -<p> -As outlined in the User Guide, and mentioned briefly earlier, the VM will switch at build time to accommodate the needs of the package. The VM to use is first determined by <c>JAVA_PKG_FORCE_VM</c>, then <path>/etc/java-config-2/build/jdk.conf</path>, and lastly the system VM. -</p> - -</body> -</section> - -<section id="compatibility"> -<title>Bytecode Compatibility</title> -<body> - -<p> -The default behavior of <c>javac</c> is to compile bytecode that will compatible with the current VM version and higher (ie forward compatible). This becomes particularly problematic when trying to use a lower versioned VM. For example, source compiled with 1.4 will be compatible with 1.4 and 1.5 and later, and source compiled with 1.5 will only be compatible with 1.5 and later, but not 1.4. This makes it particularly difficult to revert to an earlier VM. -</p> -<p> -It is possible to specify which VM to compile for to provide the best compatibility. -</p> -<p> -At build time, the <c>DEPEND</c> and <c>RDEPEND</c> will determine what VM to compile for based on virtual/jdk and virtual/jre. Additionally, this can be controlled by the environment variables <c>JAVA_PKG_WANT_SOURCE</c> and <c>JAVA_PKG_WANT_TARGET</c>. -</p> -<p> -There is a wrapper for <c>javac</c>, <c>ejavac</c>, which will use the appropriate VM's <c>javac</c>, and then specify the appropriate -target and -source. For projects that use <c>ant</c>, the build.xml can be translated to specify the appropriate -target and -source. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Gentoo Java Packaging Policy</title> - -<section> -<body> -<p> -In addition to other Gentoo policies, there are a few unique to Java packages, or that need special attention. -</p> -</body> -</section> - -<section> -<title>Why build from source?</title> -<body> - -<p> -We should strive to only accept ebuilds that build from source code. For -reasons why, please refer to -<uri link="why-build-from-source.xml">Why Build From Source</uri>. -</p> - -</body> -</section> - -<section> -<title>Filesystem Layout</title> -<body> - -<p> -In general, the directory policies are handled for you by the helper functions -in the <uri link="#java-utils-2.eclass">java-utils-2</uri> eclass. -</p> - -<p> -These functions adhere to the following path name conventions: -</p> - -<ul> - <li> - /usr/share/${PN}-${SLOT}/package.env contains information about the package - </li> - - <li> - .jar files created from source code are installed to /usr/share/${PN}-${SLOT}/lib/ - </li> - - <li> - .jar pre-built files not compiled by the ebuild are installed to /opt/${PN}-${SLOT}/lib - </li> - - <li> - Javadoc documentation is installed to /usr/share/doc/${PF}/html/api/ - </li> - - <li> - Source archives are installed to /usr/share/${PN}-${SLOT}/source/ - </li> - - <li> - User-executable scripts are installed to /usr/bin - </li> - - <li> - System-wide environment files are in installed to /usr/env.d/java - </li> - - <li> - User-specific environment files can be put into ${HOME}/.gentoo/env.d/ - </li> -</ul> - -</body> -</section> -<section> -<title>Slotting</title> -<body> - -<p> -Libraries should be slotted according to the API they provide. If two version have the same API, or if a new version is fully compatible with the previous version, then they should be in the same SLOT. -</p> - -<p> -Java libraries have a tendency to sometimes break API and ABI between minor revisions, ie from 2.1.1 to 2.1.2. As a result, it is necessary to slot early, and slot often. -</p> - -<p> -For applications, it is mostly sufficient to keep only the latest version. If the application comes in series, such as Eclipse, we want to keep the latest revision in each series. Very old series may eventually be dropped completely. -</p> - -</body> -</section> - -<section> -<title>Dependencies</title> -<body> - -<p> - Packages should not use bundled jars. Instead, they should make use of jars from already installed packages. -</p> - -<p> -When depending on a package, take care that you depend on a sufficiently recent version, and explicitly ensure at building time that the providing package gives you the correct interface, i.e. the correct <c>SLOT</c>. -</p> - -</body> -</section> - -</chapter> - -<chapter id="writing_the_ebuild"> -<title>Writing the ebuild</title> -<section id="general_guidelines"> -<title>General Guidelines</title> -<body> - -<p> -In addition to standard Gentoo ebuild guidelines, there are a number specific for Java packages: -</p> - -<ul> - <li>In RDEPEND, use ">=virtual/jre-[minimal-version]". If you need a JDK for normal operation, like www-servers/tomcat used to, then you should use ">=virtual/jdk-[minimal-version]". The jre atom MUST have a version.</li> - - <li>In DEPEND, use ">=virtual/jdk-[minimal-version]", unless the ebuild is not compiling source. The jdk atom MUST have a version.</li> - - <li>For packages that use Ant to build, try to DEPEND on just dev-java/ant-core when possible instead of dev-java/ant. - dev-java/ant-core is automatically added to DEPEND if you inherit java-ant-2. - If the package makes use of 'optional' ant tasks, you'll need to DEPEND on dev-java/ant or - add WANT_ANT_TASKS="ant-task" before inherit. The latter is of course preferred. see the - <uri link="ant-guide.xml">Ant Guide</uri> for details.</li> - - <li>For packages that are distributed as zip, you need to DEPEND on app-arch/unzip to unpack</li> - - <li>Always use slot dependencies (EAPI 1 or later) as jars are installed to slot specific paths. Your DEPEND and RDEPEND should look like dev-java/some-library:1.2 or dev-java/another:0.</li> - - <li>Avoid using bundled .jar files at all costs for source-based packages. Instead, they should use system installed versions with the help of our eclass functions.</li> - - <li>If you only need the path to installed libraries, you can use java-pkg_getjar(s). Don't call java-config directly, because it will not be recorded as a dependency in the package env.</li> - - <li>Always provide an easily understandable reason after 'die', so that end-users will provide the maintainers with sensible feedback if the build should fail.</li> - - <li> - Avoid cluttering up the environment by adding environment files to /etc/env.d/. Instead, store your env file in /etc/env.d/java/, and then have user scripts source its environment file when it launches. Otherwise, developers, who regularly override CLASSPATH, CATALINA_HOME and other env vars, will have problems running regular apps. If you use the <uri link="#launcher">launcher</uri> it will also automatically source the appropriate env file. -</li> - - <li>Make sure you always compile with correct a source/target. This is important to ensure future and backwards <uri link="#compatibility">compatibility</uri>. If the packages use ant, this can be done for you automatically. See <uri link="#java-ant-2.eclass">java-ant-2.eclass</uri>. If not you will have to patch it to pass <uri link="#func_query">$(java-pkg_javac-args)</uri> to javac.</li> - - <li>Do no install jars which contain versions in their filename, ie castor-0.9.7.jar. Use java-pkg_newjar to rename and install versioned jars to not contain the version in their filename.</li> - -</ul> - -</body> -</section> - -<section> -<title>USE flags</title> -<body> - -<p> - If a manual or other extensive documentation is available, it should be installed using the doc USE flag. If the build system can, you should build javadocs also using the <c>doc</c> USE flag. If it does not, you should consider patching it to do so, and provide the patch upstream. HTML documentation should be installed using <uri link="http://devmanual.gentoo.org/function-reference/install-functions/index.html">dohtml</uri> and javadocs using <uri link="#func_install">java-pkg_dojavadoc</uri>. -</p> - -<p> -If the program provides examples, in the form of source code or some other format, and you think they may be worthwhile for some users to have, install them optionally with the examples use flag using the <uri link="#func_install">java-pkg_doexamples</uri> function. -</p> - -<p> -If you want to go all the way, add the source USE flag that installs the -complete source code as a .zip file. Use <uri -link="#func_install">java-pkg_dosrc</uri> for this purpose. This allows IDEs -such as Eclipse and NetBeans to do complete source-level debugging. You will need to also DEPEND="source? ( app-arch/zip )" or add JAVA_PKG_IUSE="source" before inherit. Using JAVA_PKG_IUSE means that we can remove the app-arch/zip requirement in the future and use for example jar provided by virtual/jdk. -</p> - -<p> -If your package comes with unit tests, you can enable these using the test -FEATURE, in src_test. If you need extra dependencies for the testing you can -pull these in with the test useflag (for example dev-java/junit). -We will no longer use the junit use flag for this. -</p> - -</body> -</section> - -<section> -<title>Typical Examples</title> -<body> - -<p> -Without further ado, here are a few examples. -</p> - -<pre caption="Example: Pure java package"> - -EAPI="2" -JAVA_PKG_IUSE="doc examples source" - -inherit eutils java-pkg-2 java-ant-2 - -DESCRIPTION="Fictional example ebuild." -HOMEPAGE="http://www.gentoo.org/" -SRC_URI="mirror://gentoo/${P}-src.tar.gz" - -LICENSE="Apache-2.0" -SLOT="0" -KEYWORDS="~x86 ~sparc ~ppc ~amd64 ppc64" -IUSE="" - -COMMON_DEP=" - dev-java/xerces:2 - >=dev-java/log4j-1.2.8:0" - -RDEPEND=">=virtual/jre-1.4 - ${COMMON_DEP}" - -DEPEND=">=virtual/jdk-1.4 - ${COMMON_DEP}" - -S=${WORKDIR}/${P}-src - -java_prepare() { - cd "${S}/lib" - rm -v *.jar || die - - java-pkg_jar-from xerces-2 - java-pkg_jar-from log4j log4j.jar log4j-1.2.8.jar -} - -src_install() { - java-pkg_newjar target/${P}-dev.jar ${PN}.jar - - use doc && java-pkg_dojavadoc dist/api - use source && java-pkg_dosrc src/java/org - use examples && java-pkg_doexamples src/java/examples -} -</pre> - -<pre caption="Example: Optional java support"> - -EAPI="2" - -inherit eutils java-pkg-opt-2 - -DESCRIPTION="Fictional example ebuild" -HOMEPAGE="http://www.gentoo.org/" -SRC_URI="mirror://gentoo/${P}.tar.gz" - -LICENSE="LGPL-2.1" -SLOT="0" -KEYWORDS="~amd64 ~ia64 ~ppc ~ppc64 ~sparc ~x86" -IUSE="java doc nls" - -DEPEND="java? ( >=virtual/jdk-1.4 )" -RDEPEND="java? ( >=virtual/jre-1.4 )" - -java_prepare() { - epatch "${FILESDIR}/${P}.patch" -} - -src_compile() { - local myconf="$(use_enable java)" - if use java; then - myconf="${myconf} --with-javac-args=\"$(java-pkg_javac-args)\"" - fi - - econf $(use_enable nls) ${myconf} || die - - emake || die -} - -src_install() { - make install DESTDIR=${D} || die - - if use java; then - java-pkg_newjar build/java/${P}.jar ${PN}.jar - - if use doc; then - java-pkg_dohtml -r doc/java - fi - fi -} -</pre> - -</body> -</section> -</chapter> - -<chapter> -<title>Java Eclass Reference</title> -<section> -<title>Overview</title> -<body> - -<p> -Currently there are six Java related eclasses. -</p> - -<table> -<tr> - <th>Eclass</th><th>Usage</th> -</tr> -<tr> - <ti><uri link="#java-pkg-2.eclass">java-pkg-2.eclass</uri></ti> - <ti>Any and all java based packages</ti> -</tr> -<tr> - <ti><uri link="#java-pkg-opt-2.eclass">java-pkg-opt-2.eclass</uri></ti> - <ti>Package that have optional java support</ti> -</tr> -<tr> - <ti><uri link="#java-ant-2.eclass">java-ant-2.eclass</uri></ti> - <ti>Ant based packages (see also the <uri link="ant-guide.xml">Ant Guide</uri>)</ti> -</tr> -<tr> - <ti><uri link="#java-utils-2.eclass">java-utils-2.eclass</uri></ti> - <ti> - Inherited by the java-pkg* eclasses and contains all the functions and dark - voodoo - </ti> -</tr> -<tr> - <ti><uri link="#java-vm-2.eclass">java-vm-2.eclass</uri></ti> - <ti>Helper functions for packages that provide a VM</ti> -</tr> -<tr> - <ti><uri link="#java-osgi.eclass">java-osgi.eclass</uri></ti> - <ti>Helper functions for packages that need to be OSGi compliant (special manifest inside the jar)</ti> -</tr> -</table> - -</body> -</section> -<section id="java-pkg-2.eclass"> -<title>java-pkg-2.eclass</title> -<body> - -<p> -This is the eclass you should use for any package using Java. -It inherits java-utils-2, and gives you all the needed function. -It also depends on the correct version of java-config the eclass -needs to do its work. -It also exports the pkg_setup phase, where it switchs the vm -and setup the environment for your VM. -</p> - -</body> -</section> -<section id="java-pkg-opt-2.eclass"> -<title>java-pkg-opt-2.eclass</title> -<body> - -<p> -This is the eclass you should use for packages with optional java support. -It does the same as java-pkg-2.eclass but only when the 'java' USE flag is on. -The USE flag that is used to enable Java features can be changed by setting -JAVA_PKG_OPT_USE before inheriting this eclass. -</p> - -</body> -</section> -<section id="java-vm-2.eclass"> -<title>java-vm-2.eclass</title> -<body> - -<p> -This eclass should be inherited by all packages that provide a VM. If no -system-vm can be found it will set the one currently being merged as the -system-vm. It also has a function to install the env file and create all -necessary symlinks. -</p> - -<ul> - <li><c>set_java_env</c> - <ul> - <li> - Takes the env file, fills with with the appropriate variables (ie name, version, etc) and places it in /etc/env.d/java, then - creates the jvm symlink in /usr/lib/jvm/ - </li> - <li>Takes the base env file as argument</li> - </ul> - </li> - <li><c>install_mozilla_plugin</c> - <ul> - <li>Creates a symlink for the mozilla plugin</li> - <li>Takes the path to the oij plugin</li> - </ul> - </li> -</ul> - -</body> -</section> -<section id="java-ant-2.eclass"> -<title>java-ant-2.eclass</title> -<body> - -<p> -You should inherit this eclass when your package uses ant. This eclass automatically rewrites the build.xml unless JAVA_PKG_BSFIX is set to off. -fex: Add source/target attributes to javac calls. -</p> -<p> -The rewriting is done in java-ant-2_src_configure for EAPI 2 or eant for earlier EAPIs. -</p> -<p> -Some variables you can set from your ebuild. (Usually not needed) -</p> - -<ul> - <li><c>JAVA_PKG_BSFIX</c> - <ul> - <li> - After src_unpack, should we try to 'fix' ant build files to include (the - correct) target and source attributes - </li> - <li>Default: on</li> - </ul> - </li> - <li><c>JAVA_PKG_BSFIX_ALL</c> - <ul> - <li>Should we try to fix all build files we can find</li> - <li>Default: yes</li> - </ul> - </li> - <li><c>JAVA_PKG_BSFIX_NAME</c> - <ul> - <li>The name or names(space separated) of the build xml we should fix</li> - <li>Default: build.xml</li> - </ul> - </li> - <li><c>JAVA_PKG_BSFIX_TARGET_TAGS</c> - <ul> - <li>Tags to add the target attribute to</li> - <li>Default: javac xjavac javac.preset</li> - </ul> - </li> - <li><c>JAVA_PKG_BSFIX_SOURCE_TAGS</c> - <ul> - <li>Tags to add the source attribute to</li> - <li>Default: javadoc javac xjavac javac.preset</li> - </ul> - </li> -</ul> - -</body> -</section> - -<section id="java-osgi.eclass"> - <title>java-osgi.eclass</title> - <body> - - <p> - You should inherit this eclass when your package needs to be OSGi compliant. This eclass contains functions similar to those those in java-utils-2, but that create a jar containing a manifest with special values. This manifest will allow the jar to be used as an OSGi bundle in applications based on OSGi, for example Eclipse. - </p> - <p> - If a package is using this eclass, it means that another Gentoo package based on OSGi needs it. Thus, version bumps of the package should still use the install functions from this eclass. - </p> - <p> - Some of the functions in this eclass request a Manifest file. In this case, be careful about the file you provide. It's usually best to copy the Manifest from a safe source, eg. from Eclipse's bundled jars for example. Note that upstream Eclipse creates those files manually. - </p> - - <ul> - <li><c>java-osgi_dojar</c> - <ul> - <li> - Similar to java-pkg_dojar. Installs a jar, and records it in the package env. Make sure the jar name does not contain a version. The manifest in the jar will be filled with headers populated from the arguments given to this function. - </li> - <li>Takes four parameters: - <ul> - <li>path to the jar (like in java-pkg_dojar)</li> - <li>bundle symbolic name</li> - <li>bundle name</li> - <li>export-package-header. This is the most important thing, you must provide a valid OSGi export header. Refer to the OSGi documentation for help with this.</li> - </ul> - </li> - </ul> - </li> - <li><c>java-osgi_newjar</c> - <ul> - <li> - Similar to java-pkg_newjar. Use this if you need to rename the jar. The manifest in the jar will be filled with headers populated from the arguments given to this function. - </li> - <li>Takes four or five parameters: - <ul> - <li>path to the jar (like in java-pkg_newjar)</li> - <li>(Optional) name of the renamed jar. If absent, it will be ${PN}.jar</li> - <li>bundle symbolic name</li> - <li>bundle name</li> - <li>export-package-header. This is the most important thing, you must provide a valid OSGi export header. Refer to the OSGi documentation for help with this.</li> - </ul> - </li> - </ul> - </li> - <li><c>java-osgi_dojar-fromfile</c> - <ul> - <li> - Similar to java-osgi_dojar, except that instead of creating the manifest from the given arguments, it takes a path to a Manifest file. - </li> - <li>Takes three or four parameters: - <ul> - <li>(Optional) --no-auto-version. This option disables automatic rewriting of the version in the Manifest file. If not present, the Gentoo package version will be written to the Manifest.</li> - <li>path to the jar</li> - <li>path to the Manifest file</li> - <li>bundle name</li> - </ul> - </li> - </ul> - </li> - <li><c>java-osgi_newjar-fromfile</c> - <ul> - <li> - Similar to java-osgi_newjar, except that instead of creating the manifest from the given arguments, it takes a path to a Manifest file. - </li> - <li>Takes from three to five parameters: - <ul> - <li>(Optional) --no-auto-version. This option disables automatic rewriting of the version in the Manifest file. If not present, the Gentoo package version will be written to the Manifest.</li> - <li>path to the jar</li> - <li>(Optional) name of the renamed jar. If absent, it will be ${PN}.jar</li> - <li>path to the Manifest file</li> - <li>bundle name</li> - </ul> - </li> - </ul> - </li> - </ul> - - </body> -</section> - -</chapter> - -<chapter id="java-utils-2.eclass"> -<title>java-utils-2.eclass</title> -<section id="eant / ejavac"> -<title>eant/ejavac</title> -<body> - -<p> -Since a lot of people prefer to compile their packages with jikes or -eclipse-ecj, and it was becoming a hassle to add these in every ebuild we -provide 2 wrapper scripts to call either ant with that compiler or that -compiler itself. -</p> - -<p> -It will read the file <path>/etc/java-config/compilers.conf</path> and try the -entries front to end until it find an available(installed) compiler, and use -it. It can contain any combination of: 'ecj' 'jikes' and 'javac'. -</p> - -<p> -You should only use this if the package is known to work all 3 of the -compilers, if later on a problem does occur with one of them, you can set -JAVA_PKG_FILTER_COMPILER to it in the ebuild, and it will no longer try to use -it. -</p> - -<p> -It also listens to the JAVA_PKG_FORCE_COMPILER environment variable to force -one of them, this can be useful when testing a new ebuild with every compiler. -</p> - -</body> -</section> -<section id="func_install"> -<title>Install functions</title> -<body> - -<ul> - <li><c>java-pkg_dojar</c> - <ul> - <li> - Installs a jar, and records it in the package env. Make sure the jar name - does not contain a version. - </li> - <li>Takes one or more paths to a jars</li> - <li>will die on errors</li> - </ul> - </li> - <li><c>java-pkg_newjar</c> - <ul> - <li> - If you need to rename the jar, since we don't allow versions in the jar - name, then calls _dojar. - </li> - <li>If you only pass one argument it will name it ${PN}.jar</li> - <li>will die on errors</li> - </ul> - </li> - <li><c>java-pkg_dowar</c> - <ul> - <li> - Installs a war into a packages webapps directory. - </li> - <li>War is not recorded within package.env and is not integrated with java-config or any servlet container (e.g. Tomcat)</li> - <li>Takes one or more paths to a war</li> - <li>will die on errors</li> - </ul> - </li> - <li><c>java-pkg_dohtml</c> - <ul> - <li>Deprecated, use dohtml now. - </li> - </ul> - </li> - <li><c>java-pkg_dojavadoc</c> - <ul> - <li> - Installs javadoc documentation and records it to package.env - </li> - <li>Takes only one argument namely the directory of the javadoc root.</li> - <li>Will die if the argument is not a directory or does not exist.</li> - </ul> - </li> - <li><c>java-pkg_doexamples</c> - <ul> - <li> - Installs examples to the standard location - </li> - <li>Takes multiple arguments.</li> - <li>If given only one directory, installs dir/* into examples/.</li> - <li>Will die on errors</li> - </ul> - </li> <li><c>java-pkg_addcp</c> - <ul> - <li>Sometimes you need specials things on the package's classpath</li> - <li>Classpath string</li> - </ul> - </li> - <li><c>java-pkg_regjar</c> - <ul> - <li>record an already installed jar in he packages env</li> - <li>Takes one or more paths to a jars. Will strip ${D}</li> - <li>will die on error</li> - </ul> - </li> - <li><c>java-pkg_doso</c> - <ul> - <li>Install a jni library, and register its location it the package env</li> - <li>Takes one or more path to a library</li> - <li>will die on error</li> - </ul> - </li> - <li><c>java-pkg_regso</c> - <ul> - <li>record an already installed library in the package env</li> - <li>takes one or more paths to a library</li> - <li>will die on error</li> - </ul> - </li> - <li><c>java-pkg_jarinto</c> - <ul> - <li>Change the location java-pkg_dojar installs to</li> - </ul> - </li> - <li><c>java-pkg_sointo</c> - <ul> - <li>Change the location java-pkg_doso installs to</li> - </ul> - </li> - <li><c>java-pkg_dosrc</c> - <ul> - <li> - Install a zip containing the source, so it can used in IDE's like - Eclipse or Netbeans. - </li> - <li>Takes a list of paths to the base of the source directories like com or org.</li> - <li>Will die on error</li> - </ul> - </li> - <li><c>java-pkg_dolauncher</c> - <ul> - <li> - Makes a wrapper script to launch/start this package.<br/> - This wrapper will (attempt to) automatically figure out the dependency - and build up the classpath and library path when needed. It will also - make sure it uses a vm that is capable of running the package and every - dependency. - </li> - <li>You can call the function without any arguments if the ebuild only installs one jar. - In that case the function uses ${PN} as the binary name and the jar is launched using the Main-class - attribute (the same as running with java -jar). Otherwise use the following arguments. - <ul> - <li><c>--main</c> The class to start</li> - <li><c>--jar</c> The jar to launch (this will ignore classpath)</li> - <li><c>--java_args</c> Extra arguments to pass to java</li> - <li><c>--pkg_args</c> Extra arguments to pass to the package</li> - <li><c>--pwd</c> Directory it should launch the app from</li> - <li><c>-into</c> Directory where it should put the launch wrapper</li> - <li><c>-pre</c> Location of a (bash) script to include and run prior to launching</li> - </ul> - </li> - </ul> - </li> -</ul> - -</body> -</section> -<section id="func_query"> -<title>Query functions</title> -<body> - -<ul> - <li><c>java-pkg_jar-from</c> - <ul> - <li>Creates symlinks to the jars of a package in the cwd</li> - <li>Can be called with - <ul> - <li>A comma separated list of packages</li> - <li>A single package and the jar name you want from that package</li> - <li>A single package, the jar name, and the name of symlink</li> - </ul> - </li> - <li>Will die on errors</li> - </ul> - </li> - <li><c>java-pkg_getjars</c> - <ul> - <li>echos the classpath, and record the dependency</li> - <li>Takes a comma separated list of packages</li> - <li>Does not die on errors, returns 1</li> - </ul> - </li> - <li><c>java-pkg_getjar</c> - <ul> - <li>echos the classpath of the jar, and records the dependency</li> - <li>A single package, and the name of the jar</li> - <li>Does not die on errors, returns 1</li> - </ul> - </li> -</ul> - -</body> -</section> -<section id="func_other"> -<title>Other functions</title> -<body> - -<ul> - <li><c>eant</c> - <ul> - <li>Wrapper to call ant and use the preferred compiler</li> - <li>Will pass any args to ant</li> - <li>Will die on error</li> - <li> - Affected by the ANT_TASKS and related variables - see the - <uri link="ant-guide.xml">Ant Guide</uri> for details. - </li> - </ul> - </li> - <li><c>ejavac</c> - <ul> - <li>Wrapper to call the preferred compiler</li> - <li>Will pass any args to javac</li> - <li>Will die on error</li> - </ul> - </li> - <li><c>ejunit</c> - <ul> - <li>Wrapper start junit.textui.TestRunner</li> - <li>Will pass on any args</li> - <li>Appends junit and full recorded deptree to -cp or -classpath</li> - <li>Will die on error</li> - </ul> - </li> - <li><c>java-pkg_get-source</c> - <ul> - <li>Get the -source value</li> - </ul> - </li> - <li><c>java-pkg_get-target</c> - <ul> - <li>Get the -target value</li> - </ul> - </li> - <li><c>java-pkg_javac-args</c> - <ul> - <li>Get the arguments that should be passed to javac</li> - </ul> - </li> - <li><c>java-pkg_switch-vm</c> - <ul> - <li>Attempts to switch to the best vm</li> - </ul> - </li> - <li><c>java-pkg_ensure-vm-version-sufficient</c> - <ul> - <li>die if the current vm cannot build this package</li> - <li>Takes a version: 1.4 1.5</li> - </ul> - </li> - <li><c>java-pkg_ensure-vm-version-eq</c> - <ul> - <li>die if the current vm's version isn't equal to ${1}</li> - <li>Takes a version: 1.4 1.5</li> - </ul> - </li> - <li><c>java-pkg_is-vm-version-eq</c> - <ul> - <li>test is the active vm's version equals $1</li> - <li>Takes a version: 1.4 1.5</li> - </ul> - </li> - <li><c>java-pkg_ensure-vm-version-ge</c> - <ul> - <li>die if the current vm's version isn't at least ${1}</li> - <li>Takes a version: 1.4 1.5</li> - </ul> - </li> - <li><c>java-pkg_is-vm-version-ge</c> - <ul> - <li>test if the active vm's version is at least $1</li> - <li>Takes a version: 1.4 1.5</li> - </ul> - </li> - <li><c>java-pkg_register-dependency</c> - <ul> - <li>Register runtime dependency on a package</li> - <li>Useful for binary packages and things loaded by custom classloading</li> - <li>Takes a package list: xerces-2,xalan</li> - <li>Or one jar from a package: ant-core ant.jar</li> - </ul> - </li> - <li><c>java-pkg_register-optional-dependency</c> - <ul> - <li>Same as register-dependency but the package is not expected to be installed at runtime</li> - </ul> - </li> -</ul> - -</body> -</section> -<section id="ext_vars"> -<title>External variables</title> -<body> - -<p> -Some variables that can come in handy, you are <e>not</e> allowed to use these -from an ebuild. -</p> - -<ul> - <li><c>JAVA_PKG_ALLOW_VM_CHANGE</c> - <ul> - <li> - Allow the eclass to switch the vm at merge time. If you set this to no, - it will die when the active vm isn't sufficient - </li> - <li>Default: yes</li> - </ul> - </li> - <li><c>JAVA_PKG_WANT_TARGET</c> - <ul> - <li>Ignore what DEPEND claims it needs, and use the value of this var for -target</li> - <li>Default: unset</li> - </ul> - </li> - <li><c>JAVA_PKG_WANT_SOURCE</c> - <ul> - <li>Ignore what DEPEND claims it needs, and use the value of this var for -source</li> - <li>Default: unset</li> - </ul> - </li> - <li><c>JAVA_PKG_FORCE_VM</c> - <ul> - <li>Force a specific jdk at build time.</li> - <li>Default: unset</li> - </ul> - </li> - <li><c>JAVA_PKG_FORCE_COMPILER</c> - <ul> - <li>Force a specific compiler to use at build time.</li> - <li>Default: unset</li> - </ul> - </li> - <li><c>JAVA_PKG_DEBUG</c> - <ul> - <li>Turn on very verbose output in for example build.xml rewriting and ant.</li> - <li>Default: unset</li> - </ul> - </li> - <li><c>JAVA_PKG_STRICT</c> - <ul> - <li>Enables additional checks in Java eclasses. This variable must be set when developing Java ebuilds.</li> - <li>Default: unset</li> - </ul> - </li> -</ul> - -</body> -</section> -</chapter> - -<chapter> -<title>External Resources</title> -<section> -<body> -<ul> - <li> - <uri link="/proj/en/devrel/handbook/handbook.xml">Developer Handbook</uri> - </li> - <li> - <uri link="http://devmanual.gentoo.org">Devmanual</uri> - </li> -</ul> -</body> -</section> -</chapter> - -</guide> diff --git a/xml/htdocs/proj/en/java/java-upgrade.xml b/xml/htdocs/proj/en/java/java-upgrade.xml deleted file mode 100644 index ebf64300ec..0000000000 --- a/xml/htdocs/proj/en/java/java-upgrade.xml +++ /dev/null @@ -1,199 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/java/Attic/java-upgrade.xml,v 1.25 2012/10/28 15:21:08 swift Exp $ --> - -<guide lang="en"> -<title>Gentoo Java Upgrade Guide</title> - -<author title="Author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> -</author> -<author title="Author"> - <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail> -</author> -<author title="Editor"> - <mail link="nightmorph@gentoo.org">Josh Saddler</mail> -</author> - -<abstract> -This guide shows you how to upgrade Java to the new generation of Java on -Gentoo, along with related concepts and tools. -</abstract> - -<!-- The content of this document is licensed under the CC-BY-SA license --> -<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> -<license/> - -<version>1.1</version> -<date>2008-08-25</date> - -<chapter> -<title>Introduction</title> - -<section> -<body> -<p> -Hello and welcome. About now, you may be asking 'why would I want to upgrade my Java?' Or perhaps, you began the process and got directed to this page by an error during a merge? Regardless, the purpose of this document is to help you along with upgrading to the new Java system. Ah, but what is up with this new Java system? -</p> -</body> -</section> - -<section> -<title>The new Java system</title> -<body> -<p> -For those not familar with the new Java system, here is a laundry list of new features: -</p> - -<ul> -<li>Ability to switch the current VM on the fly</li> -<li>Changes to the user and system VM take effect immediately, and no longer are tied to the shell environment (ie no more running env-update && source /etc/profile after switching the sytem VM)</li> -<li>Now has the concept of a 'build VM', which is used to emerge packages, and is configured independently of the system VM.</li> -<li>For each version of Java, ie 1.3, 1.4, 1.5, etc, the build vm can configured as to which vendor and version of a VM to use</li> -<li>The VM at emerge time will be switched on the fly according to its configuration, as well as the dependency of the package. For example, some packages won't compile with 1.5. In these cases, a 1.4 VM will be used at build time.</li> -<li>Java packages which build with ant will have their build.xml rewritten at build time, in order to ensure that the correct version of Java bytecode is compiled.</li> -<li>Java 1.5 is unmasked, after some time being package.masked</li> -<li>Java 1.6 will be made available as soon as it is released.</li> -</ul> -</body> -</section> - -<section> -<title>Terminology / Concepts</title> -<body> - -<p> -Now that you have an idea of what you're getting to... here are a few terms and concepts you might find useful before starting. -</p> - -<dl> - <dt>Generation</dt> - <dd> - This is a new concept. The idea is that a generation is a set of tools - and eclasses for building Java packages. So at some point, we begin - migrating from the existing generation to a new one. During this time, - both generations coexist on your system and in the portage tree. So, for example, you would have a system vm - set for Generation 1 <e>and</e> a system vm for Generation 2. By - doing this, packages that use Generation 1 and Generation 2 can - coexist while migrating to the new generation. - </dd> - <dt>Generation 1</dt> - <dd> - This generation consists of the existing eclasses (java-pkg, java-utils, and java) and - <c>java-config-1.</c> Generation 1 is legacy system that is being phased out. - </dd> - <dt>Generation 2</dt> - <dd> - This generation consists of the new eclasses (java-pkg-2, java-pkg-opt-2, java-ant-2, and java-utils-2) and the new version of java-config. This is the generation that we are migrating towards. - </dd> - <dt>Generation 1 System VM</dt> - <dd> - This is the VM that is used to emerge Java packages using the eclasses - from Generation 1. It is set using <c>java-config-1 --set-system-vm <choice of - vm></c>. - </dd> - <dt>Generation 2 System VM</dt> - <dd> - With Generation 2, the system VM is only used for root and for users - that haven't set a user VM. - </dd> - <dt>Generation 2 Build VM</dt> - <dd> - Generation 2 introduces a new class of VM. The Build VM is used at - merge time for building Java packages. It is changed as necessary - depending on the package. For example, if a package only compiles - with 1.4, a 1.4 VM will be used. Defaults are defined at - <path>/usr/share/java-config-2/config/jdk-defaults.conf</path>. - Additionally, the Build VM can be configured by - <path>/etc/java-config-2/build/jdk.conf</path>. - </dd> -</dl> - -</body> -</section> -</chapter> - -<chapter> -<title>Update java-config</title> -<section> -<body> - -<p> -A new package, <c>java-config-wrapper</c>, is blocked by old versions of -<c>java-config</c>, so we should remove that first: -</p> - -<pre caption="Remove old java-config"> -# <i>emerge -C java-config</i> -</pre> - -<p> -Now we should install the new versions of <c>java-config</c>: -</p> - -<pre caption="Install new java-config"> -# <i>emerge -1 java-config:0 java-config:2</i> -</pre> - -</body> -</section> -</chapter> - -<chapter> -<title>Check your environment</title> -<section> -<body> - -<p> -We now provide a new script, <c>java-check-environment</c>. This, as -the name may imply, checks the health of your system's Java environment. It then suggests what actions -that you should take to fix any problems found. So now run: -</p> - -<pre caption="Check your environment"> -# <i>java-check-environment</i> -</pre> - -<p> -If java-check-environment encounters a problem, it will stop and tell you about it, and how to fix it. Follow the advice given, and then rerun java-check-environment until it does not find any other problems. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Upgrade... complete!</title> -<section> -<body> -<p> -If you've gotten this far, then you have succesfully upgraded to the new Java system. Congratulations! -</p> - -<p> -Now that you've upgraded, you may want to take a look at our updated documentation: -</p> - -<ul> - <li><uri link="/doc/en/java.xml">User Guide</uri></li> - <li><uri link="java-devel.xml">Developer Guide</uri></li> -</ul> -</body> - -</section> -</chapter> - -<chapter> -<title>Common Issues and Questions</title> -<section> -<body> -<p> -To address common problems experienced when upgrading, the Java team has -setup a wiki page <uri link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">here</uri>. Before seeking help or reporting -issues elsewhere, please refer to this page. -</p> -</body> - -</section> -</chapter> -</guide> diff --git a/xml/htdocs/proj/en/java/tiger-faq.xml b/xml/htdocs/proj/en/java/tiger-faq.xml deleted file mode 100644 index b4efb61a1f..0000000000 --- a/xml/htdocs/proj/en/java/tiger-faq.xml +++ /dev/null @@ -1,94 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/java/Attic/tiger-faq.xml,v 1.26 2012/10/28 15:21:08 swift Exp $ --> - -<guide lang="en"> -<title>Gentoo Java 1.5 FAQ</title> - -<author title="Author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> -</author> - -<author title="Author"> - <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail> -</author> - -<abstract> -This FAQ covers issues related to Java 1.5 support on Gentoo. -</abstract> - -<!-- The content of this document is licensed under the CC-BY-SA license --> -<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> -<license/> - -<version>1.2</version> -<date>2006-07-24</date> - -<chapter> -<title>Why was Java 1.5 hard-masked for so long?</title> -<section> -<body> - -<p> - Java 1.5 was hard masked forever because there were a number of issues which - made it unsafe to use a 1.5 JDK as your system VM. -</p> - -<p> - The first issue with Java 1.5 was backwards compatibility. If - you compile packages with a 1.5 JDK, the default behavior is that - the compiled classes can only be used in a 1.5 or above VM. -</p> - -<p> - The other significant issue is that there are packages which are not - compatible with JDK 1.5, as they currently exist in the portage tree. For - example, several abstract classes and interfaces now have new abstract - methods in 1.5. This means that packages would need to be patched to - override these abstract methods. Failing that, you could also try using - 1.4 to compile the offending package. However, due to the backwards - compatibility problem mentioned above, you wouldn't be able to use - external libraries, because they were compiled only for 1.5. -</p> - -</body> -</section> -</chapter> - - -<chapter> -<title>What is the status of Java 1.5?</title> -<section> -<body> - <p> - The good news is that work is that support for 1.5 is here! - </p> - - <p> - To begin using it, you will need to follow the <uri - link="java-upgrade.xml">upgrade guide</uri>. - </p> - - <p> - The Java documentation has been updated for the usage of this new system, - and is available at: - </p> - - <ul> - <li><uri link="/doc/en/java.xml">User Guide</uri></li> - <li><uri link="java-devel.xml">Developer Guide</uri></li> - </ul> - <p> - Additional material can be found at the following, under the - 'Migration' section: - </p> - - <ul> - <li><uri link="https://overlays.gentoo.org/proj/java/">The Gentoo Java Wiki</uri></li> - </ul> - -</body> -</section> -</chapter> -</guide> diff --git a/xml/htdocs/proj/en/java/tomcat-guide.xml b/xml/htdocs/proj/en/java/tomcat-guide.xml deleted file mode 100644 index 7a0b455966..0000000000 --- a/xml/htdocs/proj/en/java/tomcat-guide.xml +++ /dev/null @@ -1,427 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide lang="en"> - <title>Tomcat Guide</title> - - <author title="Author"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> - </author> - <author title="Editor"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> - </author> - <abstract> - This guide provides information on the layout, usage, and other things related to - Tomcat version 5.0.28, 5.5.x and later on Gentoo Linux. - </abstract> - - <!-- The content of this document is licensed under the CC-BY-SA license --> - <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> - <license/> - - <version>1.9</version> - <date>2007-02-03</date> - - <chapter> - <title>Introduction</title> - <section> - <body> - <p> - Some aspects of Tomcat on Gentoo are slightly different than - how upstream handles it. This document aims to provide some - information on how it differs. This document is based on - Tomcat versions 5.0.28, 5.5.x and later. Versions of Tomcat - older than 5.5.x should not be used, as it is discouraged by - upstream. Which includes Tomcat 5.0.28. Only use that version - if your application requires it. Otherwise please use 5.5.x or - later when released. - </p> - <p> - The biggest initial difference on Gentoo is Tomcat being spread across - multiple directories. That is because applications on Gentoo strive to - comply FHS, in addition to Gentoo-specific standards. Another major differences - is that Tomcat is compiled from source, along with the latest versions of any - dependencies and bundled libraries, which will also be compiled from source. - There are a number of smaller details, which will be covered in this guide. - </p> - <p> - This document will not cover <uri link="http://java.sun.com/products/servlet/"> - Java Servlet Specifications</uri>, nor general - <uri link="http://tomcat.apache.org/">Tomcat configuration</uri>. - This document assumes the reader has a basic understanding of what a Java - Web Application is, consists of, and basics of how to configure a container for the - web application. - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Layout</title> - <section> - <title>Standard Tomcat Layout</title> - <body> - <p> - The root directory of a typical Tomcat binary distribution is laid out as illustrated - in the following listing. - </p> - <pre caption="Standard Tomcat Root Directory Layout"> -/opt/tomcat-x.y/bin -/opt/tomcat-x.y/common -/opt/tomcat-x.y/conf -/opt/tomcat-x.y/logs -/opt/tomcat-x.y/server -/opt/tomcat-x.y/shared -/opt/tomcat-x.y/temp -/opt/tomcat-x.y/webapps -/opt/tomcat-x.y/work - </pre> - <note> - Substitute either 5, or 5.5 for x.y - </note> - </body> - </section> - - <section> - <title>Gentoo Tomcat Layout</title> - <body> - <p> - To comply with FHS and Gentoo standards, Tomcat has been dissected - and installed into the following locations. - </p> - <pre caption="Gentoo Tomcat Layout"> -/usr/share/tomcat-x.y/bin -/usr/share/tomcat-x.y/common -/etc/tomcat-x.y -/var/log/tomcat-x.y/logs -/usr/share/tomcat-x.y/server -/var/lib/tomcat-x.y/shared -/var/tmp/tomcat-x.y -/var/lib/tomcat-x.y/webapps -/var/run/tomcat-x.y -</pre> - </body> - </section> - - <section> - <title>Configuration Files</title> - <body> - <p> - In addition to simply moving the Tomcat <path>/conf</path> directory under - <path>/etc</path>. There is a Gentoo-specific Tomcat configuration file - <path>etc/conf.d/tomcat-x.y</path>, which contains Tomcat variables that are - sourced by <path>/etc/init.d/tomcat-x.y</path>. These variables are: - </p> - <dl> - <dd> - <ul> - <li> - JAVA_HOME: default is to be set to <c>$(java-config --jdk-home)</c>. - Changing this variable allows Tomcat to run with a VM other than the - system VM - </li> - <li> - CATALINA_HOME: default is <path>/usr/share/tomcat-x.y</path> - </li> - <li> - CATALINA_BASE: default is <path>/var/lib/tomcat-x.y</path> - </li> - <li> - CATALINA_USER: default is tomcat - </li> - <li> - CATALINA_LIBDIR: default is typically - <path>/usr/share/tomcat-x.y/server/lib</path> - </li> - <li> - CLASSPATH: default is <c>${CATALINA_LIBDIR}</c> - </li> - <li> - CATALINA_TMPDIR: default is <path>/var/tmp/tomcat-*</path> - </li> - <li> - TOMCAT_START: default is "start", with alternatives being "debug", - "start -security", "debug -security", or "jpda start" - </li> - <li> - TOMCAT_STOP: default is "stop" - </li> - <li> - CATALINA_OPTS: not set by default , can be used to pass options to Java or - Tomcat - </li> - </ul> - </dd> - </dl> - <p> - The Gentoo init script is also installed into <path>/etc</path>, at - <path>/etc/init.d/tomcat-x.y</path> . Tomcat on Gentoo no longer uses - or modifies catalina.sh. - </p> - </body> - </section> - - <section> - <title>Web Applications</title> - <body> - <p> - The <path>/var/lib/tomcat-x.y/</path> contains a symlinks to other Tomcat - directories, and the <path>webapps/</path> directory where actual web - applications go. This directory serves as the hub and is referenced by Tomcat - as the CATALINA_BASE. - </p> - <pre caption="Gentoo Tomcat Base and webapp location"> -conf -> /etc/tomcat-x.y -logs -> /var/log/tomcat-x.y -shared -temp -> /var/tmp/tomcat-x.y -webapps -work -> /var/run/tomcat-x.y</pre> - </body> - </section> - - <section> - <title>Runtime Files</title> - <body> - <p> - These directories hold logs, temp, and working files used by Tomcat. - </p> - <dl> - <dd> - <ul> - <li> - <path>/var/tmp/tomcat-x.y</path> Tomcat's temporary directory - </li> - <li> - <path>/var/run/tomcat-x.y</path> Tomcat's working directory, - where JSPs Java sources and resulting class files live - </li> - <li> - <path>/var/log/tomcat-x.y</path> Tomcat's logging directory - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Installation</title> - <section> - <title>Tomcat's USE flags</title> - <body> - <p> - Tomcat's USE flags are not any different from USE flags for any package on - Gentoo. Most are self-explanatory like doc, sources, and test. They are for - documentation, sources, and running unit tests, correspondingly. - </p> - <p> - The admin USE flag determines if Tomcat's admin webapp will be built and - installed. Using this flag also adds struts as a dependency to Tomcat. - </p> - <p> - The examples USE flag should be used for anyone new to Tomcat, - Java Web Application development, or just about anything beyond - deploying existing applications. When set, the examples USE flag - will install the example web applications. Most all can safely - ignore this USE flag, unless you are starting out. - </p> - <p> - The java5 USE flag will build a Java 1.5 byte code version of - Tomcat 5.5.x. It will also reduce a consdierable amount of - dependencies since mx4j is dropped as a dependency when the - java5 USE flag is enabled. - </p> - </body> - </section> - - <section> - <title>Emerge Tomcat</title> - <body> - <p> - Once you have the desired USE flags set in <path>/etc/make.conf</path> - or <path>/etc/portage/package.use</path> and added packages names to - <path>/etc/portage/package.keywords</path> it's time to actually install - Tomcat. Tomcat, like every other package on Gentoo, is installed by doing: - </p> - <pre caption="Command to download, compile, and install Tomcat"> -emerge tomcat</pre> - <warn> - Because Tomcat is compiled from source, along with all its - dependencies, a lot of packages may be pulled in at emerge time. - Good news is, since it's Java, aside from download time, should - compile rather quickly even on older machines. - </warn> - <note> - Tomcat 5.x versions have allot of questionable dependencies. Tomcat - calls them optional core packages. Good news is Tomcat 6.0.x has - a fraction of the dependencies of Tomcat 5.x. - </note> - </body> - </section> - </chapter> - - <chapter> - <title>Usage</title> - <section> - <title>Configuring Tomcat</title> - <body> - <p> - Depending on what Tomcat will be used for, one may or may not need to - finely configure Tomcat. If Tomcat is just a dependency of another - application, one might be able to simple start - Tomcat, and request the application via a browser or etc at - http://127.0.0.1:8080/. - </p> - <p> - For most others, particularly developers, running more than one site under Tomcat, or etc. will need to edit Tomcat's main configuration file - <path>/etc/tomcat-x.y/server.xml</path>. The syntax of that file, - and configuration of Tomcat is beyond the scope of this document. - Please refer to - <uri link="http://tomcat.apache.org/">Tomcat documentation</uri> - for more information. - </p> - </body> - </section> - - <section> - <title>Using a Specific VM</title> - <body> - <p> - By default, Tomcat will use the system VM controlled by - <c>java-config</c> as-per the JAVA_HOME variable in - <path>/etc/conf.d/tomcat-x.y</path>. One can - change that variable to point to any VM that is capable of - running Tomcat. Then, when Tomcat is started, it will use the - specified VM. - </p> - </body> - </section> - - <section> - <title>Logging</title> - <body> - <p> - With 5.5.x Logging has changed a bit. Tomcat no longer uses log4j by default. - Applications can still use log4j, however the jars have to be put onto the classpath manually. - Log4j is not used by a Tomcat install by default, same as upstream. For more - information please refer to Tomcat's documentation on logging. Despite this - change log4j is still a compile time dependency for now. - <uri>http://jakarta.apache.org/commons/logging/tech.html</uri> - </p> - <warn> - log4j.jar MUST be in the same directory as commons-logging.jar. The lowest - classloader level they should be put in is common/lib. The recommended is - shared/lib, or in a specific webapp's WEB-INF/lib directory. - </warn> - </body> - </section> - - <section> - <title>Starting/Stopping Tomcat</title> - <body> - <p> - Tomcat is started and stopped the same as any service on Gentoo. - </p> - <pre caption="Start Stop Restart Tomcat"> -/etc/init.d/tomcat-x.y [ start | stop | restart ]</pre> - </body> - </section> - - <section> - <title>Tomcat's Standard Web Applications</title> - <body> - <p> - By default we do not install Tomcat's admin, docs, or examples web - application. - We do, however, install Tomcat's ROOT and manager applications. - However per upstream Tomcat policy, no usernames or passwords are - configured by default. <path>/etc/tomcat-x.y/tomcat-users.xml</path> - should be modified to add users - </p> - <pre caption="ROOT and Manager Web Application URLs"> -http://127.0.0.1:8080/ -http://127.0.0.1:8080/manager/html/ - </pre> - </body> - </section> - - <section> - <title>Missing Jar - naming-factory-dbcp.jar</title> - <body> - <p> - Currently the naming-factory-dbcp.jar is not build by default. To build that jar - Tomcat robs .java source files from 3 other commons packages, collections, - pool, and dbcp. There is no clean solution to compiling this jar at this time. - Suggestions, patches, or any assistance on compiling that jar is greatly - appreciated. - </p> - <p> - There are alternatives to this jar. You can use commons-dbcp.jar, or - use the factory provided by most all jdbc drivers. - </p> - <note> - For the time being anyone who needs that jar should fetch it from a binary release - of Tomcat 5.0.x or 5.5.x. Just place the jar into common/lib and you will be all set. - </note> - </body> - </section> - </chapter> - - <chapter> - <title>Future</title> - <section> - <title>Future possibilities for Tomcat on Gentoo</title> - <body> - <p> - These are some features which are either in consideration, under development, - or are only a dream. Ideally to be implemented in the order listed below. - </p> - <dl> - <dd> - <ul> - <li> - Gentoo Web Application integration support per - <uri link="http://www.gentoo.org/proj/en/glep/glep-0011.html">GLEP 11</uri> - </li> - <li> - Documentation on Tomcat's connectors and using them to connect to - Apache on Gentoo Linux. - </li> - <li> - Replace init script with one developed by a Tomcat developer<br /> - <uri>http://www.webdroid.org:8080/repo/viewcvs.cgi/tomcat-package/trunk/bin/</uri> - </li> - <li> - Modify Tomcat init script or ebuild to use JSVC so Tomcat can run on - unprivileged ports. This might not happen, as in there are other ways to do - this. We are working with upstream on this but are far from an ideal solution. - <br /> - <uri>http://bugs.gentoo.org/show_bug.cgi?id=75224</uri> - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Problems</title> - <section> - <title>Where and who to report what to</title> - <body> - <p> - If you have problems, please stop and think if the problem is - Gentoo related, or Tomcat specific. If you are not sure, please start - with the Gentoo Java community and Team, which can be reached via - the gentoo-java mailing list, or - #gentoo-java IRC channel on irc.freenode.net. Please file and - report Gentoo related bugs, feature enhancement requests, and etc to - <uri>http://bugs.gentoo.org/</uri> - </p> - </body> - </section> - </chapter> - -</guide> diff --git a/xml/htdocs/proj/en/java/tomcat6-guide.xml b/xml/htdocs/proj/en/java/tomcat6-guide.xml deleted file mode 100644 index ee7feae48b..0000000000 --- a/xml/htdocs/proj/en/java/tomcat6-guide.xml +++ /dev/null @@ -1,415 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide lang="en"> - <title>Tomcat Guide</title> - - <author title="Author"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> - </author> - <author title="Editor"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> - </author> - <abstract> - This guide provides information on the layout, usage, and other things - related to Tomcat version 6.0.x and later on Gentoo Linux. - </abstract> - - <!-- The content of this document is licensed under the CC-BY-SA license --> - <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> - <license/> - - <version>1.1</version> - <date>2007-02-04</date> - - <chapter> - <title>Introduction</title> - <section> - <body> - <p> - Some aspects of Tomcat on Gentoo are slightly different than - how upstream handles it. This document aims to provide some - information on how it differs. This document is based on - Tomcat versions 6.0.x and later. Versions of Tomcat - older than 5.5.x should not be used, as it is discouraged by - upstream. Otherwise please use 6.0.x or - later when released. - </p> - <p> - The biggest initial difference on Gentoo is Tomcat being spread across - multiple directories. That is because applications on Gentoo strive to - comply FHS, in addition to Gentoo-specific standards. Another major differences - is that Tomcat is compiled from source, along with the latest versions of any - dependencies and bundled libraries, which will also be compiled from source. - There are a number of smaller details, which will be covered in this guide. - </p> - <p> - This document will not cover <uri link="http://java.sun.com/products/servlet/"> - Java Servlet Specifications</uri>, nor general - <uri link="http://tomcat.apache.org/">Tomcat configuration</uri>. - This document assumes the reader has a basic understanding of what a Java - Web Application is, consists of, and basics of how to configure a container for the - web application. - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Layout</title> - <section> - <title>Standard Tomcat Layout</title> - <body> - <p> - The root directory of a typical Tomcat binary distribution is laid out as illustrated - in the following listing. - </p> - <pre caption="Standard Tomcat Root Directory Layout"> -/opt/tomcat-x.y/bin -/opt/tomcat-x.y/conf -/opt/tomcat-x.y/logs -/opt/tomcat-x.y/lib -/opt/tomcat-x.y/shared -/opt/tomcat-x.y/temp -/opt/tomcat-x.y/webapps -/opt/tomcat-x.y/work - </pre> - <note> - Substitute 6 for x.y - </note> - </body> - </section> - - <section> - <title>Gentoo Tomcat Layout</title> - <body> - <p> - To comply with FHS and Gentoo standards, Tomcat has been dissected - and installed into the following locations. - </p> - <pre caption="Gentoo Tomcat Layout"> -/usr/share/tomcat-x.y/bin -/etc/tomcat-x.y -/var/log/tomcat-x.y/logs -/usr/share/tomcat-x.y/lib -/var/lib/tomcat-x.y/shared -/var/tmp/tomcat-x.y -/var/lib/tomcat-x.y/webapps -/var/run/tomcat-x.y - </pre> - </body> - </section> - - <section> - <title>Configuration Files</title> - <body> - <p> - In addition to simply moving the Tomcat <path>/conf</path> directory under - <path>/etc</path>. There is a Gentoo-specific Tomcat configuration file - <path>/etc/conf.d/tomcat-x.y</path>, which contains Tomcat variables that are - sourced by <path>/etc/init.d/tomcat-x.y</path>. These variables are: - </p> - <dl> - <dd> - <ul> - <li> - JAVA_HOME: default is to be set to <c>$(java-config --jdk-home)</c>. - Changing this variable allows Tomcat to run with a VM other than the - system VM - </li> - <li> - CATALINA_HOME: default is <path>/usr/share/tomcat-x.y</path> - </li> - <li> - CATALINA_BASE: default is <path>/var/lib/tomcat-x.y</path> - </li> - <li> - CATALINA_USER: default is tomcat - </li> - <li> - CATALINA_LIBDIR: default is typically - <path>/usr/share/tomcat-x.y/lib</path> - </li> - <li> - CLASSPATH: default is <c>${CATALINA_LIBDIR}</c> - </li> - <li> - CATALINA_TMPDIR: default is <path>/var/tmp/tomcat-x.y</path> - </li> - <li> - TOMCAT_START: default is "start", with alternatives being "debug", - "start -security", "debug -security", or "jpda start" - </li> - <li> - TOMCAT_STOP: default is "stop" - </li> - <li> - CATALINA_OPTS: not set by default , can be used to pass options to Java or - Tomcat - </li> - </ul> - </dd> - </dl> - <p> - The Gentoo init script is also installed into <path>/etc</path>, at - <path>/etc/init.d/tomcat-x.y</path> . Tomcat on Gentoo no longer uses - or modifies catalina.sh. - </p> - </body> - </section> - - <section> - <title>Web Applications</title> - <body> - <p> - The <path>/var/lib/tomcat-x.y/</path> contains <path>shared</path> for - shared libraries, <path>webapps</path> for web applications, and symlinks - to other Tomcat directories. This directory serves as the hub and is - referenced by Tomcat as the CATALINA_BASE. - </p> - <pre caption="Gentoo Tomcat Base and webapp location"> -conf -> /etc/tomcat-x.y -logs -> /var/log/tomcat-x.y -shared -temp -> /var/tmp/tomcat-x.y -webapps -work -> /var/run/tomcat-x.y</pre> - </body> - </section> - - <section> - <title>Runtime Files</title> - <body> - <p> - These directories hold logs, temp, and working files used by Tomcat. - </p> - <dl> - <dd> - <ul> - <li> - <path>/var/tmp/tomcat-x.y</path> Tomcat's temporary directory - </li> - <li> - <path>/var/run/tomcat-x.y</path> Tomcat's working directory, - where JSPs Java sources and resulting class files live - </li> - <li> - <path>/var/log/tomcat-x.y</path> Tomcat's logging directory - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Installation</title> - <section> - <title>Tomcat's USE flags</title> - <body> - <p> - Tomcat's USE flags are not any different from USE flags for any package on - Gentoo. Most are self-explanatory like doc, source, and test. They are for - documentation, sources, and running unit tests, correspondingly. - </p> - <p> - The examples USE flag should be used for anyone new to Tomcat, - Java Web Application development, or just about anything beyond - deploying existing applications. When set, the examples USE flag - will install the example web applications. Most all can safely - ignore this USE flag, unless you are starting out. - </p> - </body> - </section> - - <section> - <title>Emerge Tomcat</title> - <body> - <p> - Once you have the desired USE flags set in <path>/etc/make.conf</path> - or <path>/etc/portage/package.use</path> and added packages names to - <path>/etc/portage/package.keywords</path> it's time to actually install - Tomcat. Tomcat, like every other package on Gentoo, is installed by doing: - </p> - <pre caption="Command to download, compile, and install Tomcat"> -emerge tomcat</pre> - <warn> - Because Tomcat is compiled from source, along with all its - dependencies, a lot of packages may be pulled in at emerge time. - Good news is, since it's Java, aside from download time, should - compile rather quickly even on older machines. - </warn> - </body> - </section> - </chapter> - - <chapter> - <title>Usage</title> - <section> - <title>Configuring Tomcat</title> - <body> - <p> - Depending on what Tomcat will be used for, one may or may not need to - finely configure Tomcat. If Tomcat is just a dependency of another - application, one might be able to simple start - Tomcat, and request the application via a browser or etc at - http://127.0.0.1:8080/. - </p> - <p> - For most others, particularly developers, running more than one site under Tomcat, or etc. will need to edit Tomcat's main configuration file - <path>/etc/tomcat-x.y/server.xml</path>. The syntax of that file, - and configuration of Tomcat is beyond the scope of this document. - Please refer to - <uri link="http://tomcat.apache.org/">Tomcat documentation</uri> - for more information. - </p> - </body> - </section> - - <section> - <title>Using a Specific VM</title> - <body> - <p> - By default, Tomcat will use the system VM controlled by - <c>java-config</c> as-per the JAVA_HOME variable in - <path>/etc/conf.d/tomcat-x.y</path>. One can - change that variable to point to any VM that is capable of - running Tomcat. Then, when Tomcat is started, it will use the - specified VM. - </p> - </body> - </section> - - <section> - <title>Logging</title> - <body> - <p> - As of 5.5.x Logging has changed a bit. Tomcat no longer uses log4j by default. - Applications can still use log4j, however the jars have to be put onto the classpath manually. - For more information please refer to Tomcat's documentation on logging. - <uri>http://jakarta.apache.org/commons/logging/tech.html</uri> - </p> - <warn> - log4j.jar MUST be in the same directory as commons-logging.jar. The lowest - classloader level they should be put in is /usr/share/tomcat-x.y/lib. The recommended is - /var/lib/tomcat-x.y/shared, or in a specific webapp's WEB-INF/lib directory. - </warn> - </body> - </section> - - <section> - <title>Starting/Stopping Tomcat</title> - <body> - <p> - Tomcat is started and stopped the same as any service on Gentoo. - </p> - <pre caption="Start Stop Restart Tomcat"> -/etc/init.d/tomcat-x.y [ start | stop | restart ]</pre> - </body> - </section> - - <section> - <title>Tomcat's Standard Web Applications</title> - <body> - <p> - By default we do not install Tomcat's admin, docs, or examples web - application. - We do, however, install Tomcat's ROOT and manager applications. - However per upstream Tomcat policy, no usernames or passwords are - configured by default. <path>/etc/tomcat-x.y/tomcat-users.xml</path> - should be modified to add users - </p> - <pre caption="ROOT and Manager Web Application URLs"> -http://127.0.0.1:8080/ -http://127.0.0.1:8080/manager/html/ - </pre> - <note> - As of 6.0.x the admin webapp is no longer shipped or developed. - It's not in the sources, nor available as a binary for download. - </note> - </body> - </section> - - <section> - <title>Missing Jar - tomcat-dbcp.jar</title> - <body> - <p> - Currently the tomcat-dbcp.jar is not build by default. To build that jar - Tomcat robs .java source files from 3 other commons packages, collections, - pool, and dbcp. There is no clean solution to compiling this jar at this time. - Suggestions, patches, or any assistance on compiling that jar is greatly - appreciated. - </p> - <p> - There are alternatives to this jar. You can use commons-dbcp.jar, or - use the factory provided by most all jdbc drivers. - </p> - <note> - For the time being anyone who needs that jar should fetch it from a binary release - of Tomcat 6.0.x. Just place the jar into /lib and you will be all set. - </note> - <p> - For more information on the missing jar, please refer to - <uri>http://bugs.gentoo.org/show_bug.cgi?id=144276</uri> - </p> - </body> - </section> - </chapter> - - <chapter> - <title>Future</title> - <section> - <title>Future possibilities for Tomcat on Gentoo</title> - <body> - <p> - These are some features which are either in consideration, under development, - or are only a dream. Ideally to be implemented in the order listed below. - </p> - <dl> - <dd> - <ul> - <li> - Gentoo Web Application integration support per - <uri link="http://www.gentoo.org/proj/en/glep/glep-0011.html">GLEP 11</uri> - </li> - <li> - Documentation on Tomcat's connectors and using them to connect to - Apache on Gentoo Linux. - </li> - <li> - Replace init script with one developed by a Tomcat developer<br /> - <uri>http://www.webdroid.org:8080/repo/viewcvs.cgi/tomcat-package/trunk/bin/</uri> - </li> - <li> - Modify Tomcat init script or ebuild to use JSVC so Tomcat can run on - unprivileged ports. This might not happen, as in there are other ways to do - this. We are working with upstream on this but are far from an ideal solution. - <br /> - <uri>http://bugs.gentoo.org/show_bug.cgi?id=75224</uri> - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>Problems</title> - <section> - <title>Where and who to report what to</title> - <body> - <p> - If you have problems, please stop and think if the problem is - Gentoo related, or Tomcat specific. If you are not sure, please start - with the Gentoo Java community and Team, which can be reached via - the gentoo-java mailing list, or - #gentoo-java IRC channel on irc.freenode.net. Please file and - report Gentoo related bugs, feature enhancement requests, and etc to - <uri>http://bugs.gentoo.org/</uri> - </p> - </body> - </section> - </chapter> - -</guide> diff --git a/xml/htdocs/proj/en/java/why-build-from-source.xml b/xml/htdocs/proj/en/java/why-build-from-source.xml deleted file mode 100644 index e7b3d28799..0000000000 --- a/xml/htdocs/proj/en/java/why-build-from-source.xml +++ /dev/null @@ -1,92 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide lang="en"> - <title>Why Build From Source</title> - - <author title="Author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> - </author> - <author title="Editor"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> - </author> - <abstract> - This document provides information on why one should and why we do build - FOSS Java applications from source instead of shipping pre-compiled - binaries. - </abstract> - - <!-- The content of this document is licensed under the CC-BY-SA license --> - <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> - <license/> - - <version>1.1</version> - <date>2006-12-08</date> - - <chapter> - <title>Why build from source?</title> - <section> - <body> - <dl> - <dd> - <ul> - <li> - Building from source ensures that the source exists and - compiles properly, which is the basis of regular open-source - development. - </li> - <li> - Bugs may be found and fixed between upstrem releases. By - compiling from source, we are able to isolate patches to - address such problems, without having to wait for upstream. - </li> - <li> - When security flaws are found, we want to be able to issue fix - as soon as possible. It is not always feasible to wait for the - upstream project to make a new release. With binary-only - packages, the only fix we can offer is disabling the software - entirely by masking it. - </li> - <li> - For immature library packages, where documentation is often - scanty, the user can easily run javadoc on the sources, as a - stop-gap measure, without needing to dig out the source code - from upstream. - </li> - <li> - Although bytecode runs on every vm that supports the version of - the bytecode in question it does not mean that the bytecode - produced by different compilers is equal. Bytecode can be - optimized too. By building from source, we make it easy to - switch the compiler used to compile your installed java - programs. - </li> - <li> - In the future building, native compiling from Java source code - using gcj could become a serious option. If we try to add all - packages to the tree in a way where they are getting built from - their source code, we could make it possible in the future to - create native binaries from Java packages. With binary packages - this wouldn't be possible if upstream doesn't provide natively - compiled packages. - </li> - <li> - USE flags will normally impact on which features are to be - compiled in, and which dependencies are brought in. - </li> - <li> - End-users may want to manually patch or tweak the sources - between src_unpack and src_compile. - </li> - <li> - It is common that we need to apply Gentoo-specific tweaks and - intermediary patches when upstream takes a long time to issue a - new release, which is almost always only possible when we - compile from sources. - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> -</guide> diff --git a/xml/htdocs/proj/en/java/why-we-need-java-14.xml b/xml/htdocs/proj/en/java/why-we-need-java-14.xml deleted file mode 100644 index 5056570e0e..0000000000 --- a/xml/htdocs/proj/en/java/why-we-need-java-14.xml +++ /dev/null @@ -1,165 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide lang="en"> - <title>Why We Still Need Java 1.4</title> - - <author title="Author"> - <mail link="nichoj@gentoo.org">Joshua Nichols</mail> - </author> - <author title="Editor"> - <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail> - </author> - <abstract> - This document provides information on why we still need Java 1.4 on - Gentoo - </abstract> - - <!-- The content of this document is licensed under the CC-BY-SA license --> - <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> - <license/> - - <version>1.0</version> - <date>2006-12-08</date> - - <chapter> - <title>Primary Reasons</title> - <section> - <body> - <p> - There are two primary reasons for requiring Java 1.4, with regards - to Gentoo and building packages. - </p> - <dl> - <dd> - <ol> - <li> - There are still packages which don't compile when built with - Java 1.5. In these cases, the new Java build system switches to - a 1.4 JDK for building - </li> - <li> - It is needed for packages that haven't been migrated to use - the new Java system. This is necessary, otherwise we encounter - the same exact problems that prompted the initial package.mask - of Java 1.5. - </li> - </ol> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>1.5 package.mask recap</title> - <section> - <title>Unable to build/compile</title> - <body> - <p> - Just to recap why Java 1.5 was package was package.mask'd.... It - really comes down to backwards compatibility, and that Java 1.5 isn't - 100% backwards compatible with Java 1.4. Things that ran with Java - 1.4 should still run with Java 1.5... but some things that once - built with Java 1.4 no longer compile with Java 1.5. - </p> - <dl> - <dd> - <ol> - <li> - There's a new reserved keyword with Java 1.5, enum. So where - you used to be able to use enum as a variable name, you no - longer can in 1.5. - </li> - <li> - A number of new methods have been introduced to some abstract - classes and interfaces. If a particular implementation doesn't - implement the new methods, then it won't compile against Java - 1.5. - </li> - </ol> - </dd> - </dl> - </body> - </section> - - <section> - <title>UnsupportedClassVersionError</title> - <body> - <p> - Now, say you're using Java 1.5 to build all your packages, and then - you come up to a package that can't compile for one of these reasons? - It'd fail for one. But then you may try with Java 1.4... and all is - well until you see a compile error: UnsupportedClassVersionError. - What does this mean though? - </p> - <p> - Well, each major release of Java has it's own version of bytecode. - Bytecode is forward compatible, ie run 1.4 bytecode in 1.5, but not - backwards compatible. If you try to use 1.5 bytecode in 1.4, you will - see the infernal UnsupportedClassVersionError. This happens because, - since you were using Java 1.5, the dependencies of the package you - were just trying to compile with 1.4 were built with 1.5, and the - default behavior is to build the highest possible bytecode. - </p> - <p> - So, these are the reasons Java 1.5 was package.mask'd, and why we - need to use Java 1.4 for building unmigrated packages. - </p> - </body> - </section> - </chapter> - - - <chapter> - <title>How the new system helps</title> - <section> - <body> - <p> - Here is a few reasons how the new java system helps correct the - situation. - </p> - <dl> - <dd> - <ul> - <li> - We get around the problem of enum by specifically telling the - compiler to use source="1.4", where enum is a valid variable - name. - </li> - <li> - We get around the changes in API by switching to a version - where it can be compiled, until such time as the package can be - properly patched. - </li> - <li> - Additionally, we make javac compile the lowest possible - bytecode. So it can be used by as many other packages as - possible. - </li> - </ul> - </dd> - </dl> - </body> - </section> - </chapter> - - <chapter> - <title>I still don't want 1.4</title> - <section> - <body> - <p> - For now you pretty much have to have a 1.4 jdk installed. Work is - being done to get all packages migrated to the new java system. - Along with testing them under 1.5, both compile and running. - Which is a pretty large task, considering we still have to maintain - other packages in the mean time. - </p> - <p> - There is no time frame for when Java 1.4 will no longer be required. - We do welcome any help with migrating the remaining packages causing - the 1.4 dependency. Then testing the packages under a 1.5 jdk and jre. - </p> - </body> - </section> - </chapter> -</guide> |