the ReportScriptingMojo

Hi Kartik,

There are a couple more methods it might be useful for getScriptEngine
to load into a script engine by default.

If you look in the javadoc script for pljava-examples, there's a test
for whether the saxon-examples profile is active.

It's an easy test, but I can foresee it showing up in compiling scripts
as well, so a simple boolean isProfileActive(String id) method is probably
worth supplying.

If supplying one from PGXSUtils, I would probably also have the method
check that the argument profile name is even a known profile in the POM,
and warn if it isn't. That would catch cases where somebody edits a POM
and deletes a profile, not realizing a script was checking for it.
I think all the known profiles are in project.getModel().getProfiles().

You'll also see the -examples script generates the -classpath argument
by stringing together project.compileClasspathElements. That works for
-examples because the -examples code isn't modular.

I did not change the scripts in pljava/ and pljava-api/ because those
are modular code, and need to generate a --module-path instead. In
general, Maven's compileClasspathElements might include both: elements
that belong on the module path, elements that belong on the class path
because they aren't modules.

So that suggests a useful method like

Map<String,String> buildPaths(List<String> elements)

where you could pass it a list of elements (from compileClasspathElements
or runtimeClasspathElements, etc.) and get back a map m such that
m['classpath'] has all the elements that aren't modules, and
m['modulepath'] has the elements that are (both with pathSeparator between
elements).

An element is a module if it is a directory and has a module-info.class,
or it is a jar and either contains a module-info.class or has an
Automatic-Module-Name entry in its manifest.

Such a method would also be a good place for checking that no element
contains pathSeparator as part of its name, as that would lead to a
malformed path,

Regards,
-Chap