I didn't know it was a signed jar. Since it is an external (external to
glassfish svn) artifact, are we not supposed to do a source build of
this as well? May be that's another discussion altogether.
Given it is actually an extension module implementing a spec, I am
actually tempted to close the discussion here and not to anything about
it in this release.
Sahoo
On Friday 12 November 2010 01:53 AM, Snjezana Sevo-Zenzerovic wrote:
> AFAIK, the only other thing that uses it is standalone upgrade tool so we shouldn't need it in server classloader. Now, the problem with repackaging and adding the exclude flag is that javahelp.jar is signed jar so we need to keep it as-is (there are also some JavaHelp licensing implications of doing any modification at all to the binary, but that's yet another story).
>
> Sahoo, would it help if we simply move the jar into dedicated subdirectory of glassfish/lib, say glassfish/lib/javahelp and adjust verifier and upgrade tool classpaths accordingly?
>
> Thanks,
>
> Snjezana
>
> ----- Original Message -----
> From: sanjeeb.sahoo_at_oracle.com
> To: snjezana.sevozenzerovic_at_oracle.com, dev_at_glassfish.dev.java.net
> Sent: Wednesday, November 10, 2010 7:17:49 PM GMT -08:00 US/Canada Pacific
> Subject: javahelp.jar in glassfish/lib
>
> I know verifier uses javax.help in standalone mode, but that does not
> require it to be added common class loader's classpath. Is there any
> other program that requires it? If so, please state the usage. If there
> is no response, then packaging team should add GlassFishServerExcluded
> manifest entry in it so that it does not come into picture in server
> runtime.
>
> Thanks,
> Sahoo
>