Subject: Re: PL/Java new build plugin
To: Kartik Ohri <kartikohri13@gmail.com>
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
 <5F077926.2050806@anastigmatix.net>
 <CAASLQ4OuFQCiSMeypQtfRaAvj-4H-EAgszLwdAo6Tc1zS9B66g@mail.gmail.com>
 <5F07C2D5.5050904@anastigmatix.net>
 <CAASLQ4PSizkzBKyyfkp9ccJ1qDPLRLu6g2bo9cN-XuTzGQFGfQ@mail.gmail.com>
 <CAASLQ4P9zGxHda=HAGJ2eAa-oMmJtnPm=4a14mj4P-QpfFsYxg@mail.gmail.com>
 <5F0D35BA.30904@anastigmatix.net>
 <CAASLQ4NmornyOW8n-qyneLpDVPgV0Js=+=Eys6bw3Y-ZiVbVjA@mail.gmail.com>
 <CAASLQ4OYvTQL7ssG4=QyEqhaB71=AM-svBUYj3uRdWXWoQgBPw@mail.gmail.com>
 <5F0E3972.5070609@anastigmatix.net> <5F0F2DA2.5090603@anastigmatix.net>
 <CAASLQ4N40xn-0S4Nsy0Ld75=Ny719MPUE7_aRP_5nAcAqkAqoQ@mail.gmail.com>
 <CAASLQ4OiWCQQwYFnxAQBe2dC6Ms803RjCMX-9AC2=1m0ZzeDhA@mail.gmail.com>
 <5F12FF49.6090906@anastigmatix.net> <5F12FF80.5020208@anastigmatix.net>
 <CAASLQ4MqSVnhK_GMgq03HcmOKk7a-v7b4L0yfPbtRO=mpqoQtA@mail.gmail.com>
 <5F1338F8.6030506@anastigmatix.net>
 <CAASLQ4OR8ZD4GRNHVGuTzJp_UP-PAcADxcz=uymiSFPpg8EEHQ@mail.gmail.com>
Cc: pljava-dev@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5F135B84.8070302@anastigmatix.net>
Date: Sat, 18 Jul 2020 16:28:52 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
 <CAASLQ4OR8ZD4GRNHVGuTzJp_UP-PAcADxcz=uymiSFPpg8EEHQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 07/18/20 15:49, Kartik Ohri wrote:
> inside out. maven.plugin.classpath is not something that maven declares. It
> is declared by the maven antrun plugin for use by ant tasks [2]
> <https://github.com/apache/maven-antrun-plugin/blob/8e5b3c613e96c20881347ec16813864a2d8ef0bb/src/main/java/org/apache/maven/plugins/antrun/AntRunMojo.java#L383>.

Aha! And it generates that using getPathFromArtifacts(), which just goes
through its own dependency list and collects the jar names (which are
maybe the exact same jar names its current ClassRealm loader is using).

I wonder what would happen just making a dead-simple ClassLoader with
two "parents" and otherwise no functionality of its own. Of course it
could only have one real parent and an instance field for the 'extra' one.

Create it so one 'parent' is the ClassRealm loader that loaded us, and the
other is from getSystemClassLoader() (they changed the official name to
"application class loader" but didn't rename the method). Have its findClass
method just say "either parent A has it or parent B has it or I haven't
heard of it, sorry."

(In fact, findClass doesn't get called until the 'real' parent has already
been checked, so it doesn't need to do anything besides check the 'extra'
parent and return what it finds, if anything.)

That would leave the question of which parent should be the real one and
which should be the extra one, since the real one is the one that gets
searched first. In Java tradition, the app loader would be the real one.
For Maven it might be better to make the ClassRealm the real one, so
everything Maven constructed gets used, except when it fails to find
something.

I think you can pass a chosen ClassLoader directly to the
ScriptEngineManager constructor, so this special loader wouldn't need
to be used anywhere but there.

What Could Possibly Go Wrong?™

Regards,
-Chap