We Keep Coding

What to use instead of XMLBeans now that it has been retired?

I am starting a new project where I have third party XSD. My Java application needs to generate, and readm XML messages that conform to this XSD. In the past I have used Apache XMLBeans for this. It looks like XMLBeans has been retired.
What is a good replacement for XMLBeans now that it has been retired? I have used XStream on other projects but I don't recall that XStream has the ability to generate Java classes from an XSD so I am thinking that it is not a good choice over XMLBeans for this use case. I have hundreds of types defined in the XSD and would really prefer not to have to create the hundreds of Java classes to represent them in Java by hand.
In other words, using the XStream example, I have a Person type (and 99 others) defined in the XSD. Using XMLBeans I can generate the Java classes to represent these objects, but using XStream I would need to create the Java classes (e.g. Person) by hand or using some other tool. What tool should I use in this case?

Have you looked at JAXB? I haven't done anything with either of these, but googling for "alternative to XMLBeans" brings up lots of references to this package. Here's an article that compares them...
http://blog.bdoughan.com/2012/01/how-does-jaxb-compare-to-xmlbeans.html

XMLBeans has been unretired:
The Apache POI project has unretired the XMLBeans codebase and is maintaining it as a sub-project. Until now the XMLBeans codebase was held in the Apache Attic where former Apache projects are kept for the public good.
The latest release as of August 2020 is:
3.1.0 (March 26, 2019)
Having said that, I am not sure I would recommend using it, based on its history of retirement. Other solutions, such as JAXB, might be prefered since it will probably be better maintained in the future.

Does (or will) the JRE include a CLI parser

I normally use known CLI parsers (external libraries):
Apache Commons CLI http://commons.apache.org/cli/ (version 1.2)
Java Gems http://code.google.com/p/javagems/
JArgs http://jargs.sourceforge.net/
...
I haven't found one in the standard Java library, and I wonder if new versions of Java are providing an implementation so I can save a dependency. Does anyone know if there is something like that or a plan to include it in the future?

If when you say "native" you mean "java implementation included into JDK", the answer is "no". Obviously you can always create your own (more or less simple) parser based on arrays and string operations provided by java and JDK.
Concerning to choice among java CLI parsers I'd suggest you to use arg4j and can refer you to the following discussion: Java library for parsing command-line parameters?
One of the answers contains a very long list of libraries.
And the last note. I do not know why do you want to "save the dependencies". Use one of build tools that manage your dependencies (e.g. ivy, maven, gradle) and forget about such problems. if you want to distribute your program as a single jar, you can pack all your dependencies together with your application. Both maven and gradle can do this. If you want to achieve minimal jar size ... make your choice: what is more important for you - size or modularity. In most cases size is not an issue these days.

I don't think there is anything included in the JDK. Actually OpenJDK itself uses JOpt Simple (see comment at the bottom of the page).

Cannot find jena.db package with maven

I have a little problem with jena. I want to use https://github.com/ldodds/slug in one of my project. This application comes without dependencies so I use Maven to gather what this app needs. Maven resolved everything except one package
import com.hp.hpl.jena.db.*;
I cannot resolve it with any of jena maven respositories. Do you know where I can find it? Maybe jena.db was available in older package but I cannot find any migration guide about this package.
If you are familiar with problem or know Jena structure well, please help.
Thanks in advance.

The RDB storage layer (the package com.hp.hpl.jena.db) was removed from Jena a long time. Presumably slug works with the version of in it's lib directory.
It would be better to use TDB or generalise and use SPARQL (query and update) so it will work with an external, standard triple store (like Jena Fuseki -- there are many to choose from). It will need changes to slug.

Downloading part of guava-libraries

Current version (14.0.1) of guava-libraries is 2 MB. It is not huge, it is not small neither. Especially when I want to use it in an exemplary project for my students and only need "Strings" part of it for parsing some input.
Are there any smaller parts of Guava available as JAR-s with compiled code, or I have to use all of it, or compile and prepare my own bundle (e.g. using ProGuard)?

According to Maven Repository there does not seem to be any smaller jar files that the Guava library is depending on.
So I would say no, there are no smaller portions of the Guava library that you can use. You will have to build your own jar files with only the classes you need.
So ProGuard seems to be the right solution for you.

Problems with Xalan and Java JDK 1.5

From what I believe and have read online. Sun has decided to include Xalan in JDK 1.5. I am trying to take advantage of this and try to perform an XSLT to spit out multiple files. The problem I encounter:
'Unrecognized XSLTC extension 'org.apache.xalan.xslt.extensions.Redirect:write''"
From what I have read on google that i needed to change:
xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect"
to
xmlns:redirect="http://xml.apache.org/xalan/redirect"
in XSL transforms
When I apply this change to my .XSL File, I appear to be getting the same error. Need to get this working ASAP and can't seem to find an answer online. Any help will be greatly appreciated.

Just ignored the JDK's default Xalan. I just added the files from Xalan. Better, that way I can just use that rather than depending on a single JDK.