This patch didn't work with sjavac enabled. Back to the drawing board.
/Erik
On 2013-04-30 16:45, Erik Joelsson wrote:
With this patch the security tests will again be runnable on the
exploded jdk image. The main changes are:
* The security classes are compiled separately to a different outpu
On 7/05/2013 7:22 PM, Erik Joelsson wrote:
It seems to work for me.
The reason I removed things from RT_JAR_EXCLUDES that are no longer
present in jdk/classes outputdir.
Ah okay that should be fine then. If they aren't there in the first
place then no need to exclude :)
Thanks,
David
/Eri
It seems to work for me.
The reason I removed things from RT_JAR_EXCLUDES that are no longer
present in jdk/classes outputdir.
/Erik
On 2013-05-07 07:33, David Holmes wrote:
Erik,
Was this tested with a Profiles build? The changes to the
RT_JAR_INCLUDES variable has me concerned.
Thanks,
Erik,
Was this tested with a Profiles build? The changes to the
RT_JAR_INCLUDES variable has me concerned.
Thanks,
David
On 1/05/2013 12:45 AM, Erik Joelsson wrote:
With this patch the security tests will again be runnable on the
exploded jdk image. The main changes are:
* The security clas
I agree the dependencies in BuildJdk.gmk are messed up but I didn't
think this bug was the correct place to clean it up so I just followed
the existing pattern, which is a strict linear dependency chain.
/Erik
On 2013-04-30 17:58, Mike Duigou wrote:
It's very nice to see this resolved. Hopefu
It's very nice to see this resolved. Hopefully one more nail in the old build's
coffin.
The jdk target should depend upon genclasses. It seems really strange to have
this as a dependency for securityjars and not jdk.
Mike
On Apr 30 2013, at 07:45 , Erik Joelsson wrote:
> With this patch the s
With this patch the security tests will again be runnable on the
exploded jdk image. The main changes are:
* The security classes are compiled separately to a different output
directory.
* The security jars are created in the jdk target (instead of images)
and put in the jdk/lib/... directorie
