public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chapman Flack <[email protected]>
To: Kartik Ohri <[email protected]>
Cc: [email protected]
Subject: Re: PL/Java new build plugin
Date: Mon, 20 Jul 2020 23:45:09 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAASLQ4PjzGVCj559r60Kw7i3uRUTzJraxBSDDsNtAt8v8_-oWQ@mail.gmail.com>
References: <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
<CAASLQ4OYvTQL7ssG4=QyEqhaB71=AM-svBUYj3uRdWXWoQgBPw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAASLQ4N40xn-0S4Nsy0Ld75=Ny719MPUE7_aRP_5nAcAqkAqoQ@mail.gmail.com>
<CAASLQ4OiWCQQwYFnxAQBe2dC6Ms803RjCMX-9AC2=1m0ZzeDhA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAASLQ4MqSVnhK_GMgq03HcmOKk7a-v7b4L0yfPbtRO=mpqoQtA@mail.gmail.com>
<[email protected]>
<CAASLQ4OR8ZD4GRNHVGuTzJp_UP-PAcADxcz=uymiSFPpg8EEHQ@mail.gmail.com>
<[email protected]>
<CAASLQ4O=tYGASWB6F+PTiB2L3RbmHcVX8XAbKHyhwBDOodH1zg@mail.gmail.com>
<CAASLQ4P=c42e342-1YTTCBxA=CKBH2m=DLJN+ZQb5EJW6MyofQ@mail.gmail.com>
<CAASLQ4NU3BgfCnVxvAbu9vK9+gtPT87xX1uBj57b0y2J6nxi+Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAASLQ4PjzGVCj559r60Kw7i3uRUTzJraxBSDDsNtAt8v8_-oWQ@mail.gmail.com>
On 07/20/20 22:51, Kartik Ohri wrote:
>> <script engine="nashorn">...</script>
>>
> It is possible to have this syntax. We need to specify an executionID in
> the executionBlock for that. In the plugin, we can get the entire
> configuration XML as a Plexus Xpp3Dom object from which we can retrieve the
> attribute from any element. I'll add this. What attribute should be used
> though mimetype or engine or allow both and give engine precedence over
> mimetype ?
I like allowing both; giving engine preference, or just complaining if
both are specified. (Or, if both are specified, look up by engine, then
complain if its mimetypes don't include mimetype.)
By the way, when allowing an attribute to specify the script language,
it then becomes trickier to make functions available to the script
by eval'ing function definitions for them, as the mojo now does; if
those are in JavaScript and somebody wants to write a script block
in Tcl, that'll be trouble. (Not that I have any actual plans to add
Tcl scripts to this build, but....)
The ScriptEngineFactory has useful methods getMethodCallSyntax and
getOutputStatement, but it doesn't really have a
"getWholeFunctionDeclaration" method to help out there.
What I have found does work with Nashorn (haven't tried it with Graal yet)
is just engine.put (or getContext().setAttribute()), passing a functional
interface instance, e.g.:
engine.put("quoteStringForC",
(Function<String,String>)PGXSUtils::quoteStringForC);
I'm not sure that works with every script engine out there (but then
again, neither would defining the functions as JavaScript). If it does
work with both Nashorn and Graal, it seems the cleanest way.
Regards,
-Chap
view thread (132+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: PL/Java new build plugin
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox