RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

[Bradford Wetmore]

On 10/22/2013 7:52 AM, Erik Joelsson wrote:
> Trying this again. Here is a new webrev against jdk8/build. Again, this
> solves the issue detailed by Alan in this bug.
>
> http://cr.openjdk.java.net/~erikj/8009280/webrev.04/
>
> There will probably be more issues in "JDK-8006350 [build] JCE unusable
> using new build environment", but at least this part has had a fix ready
> for months. It would be nice to finally get it resolved. If the JCE team
> is unable to verify this

Not for lack of trying.  A couple new ZBB issues to resolve this week. 
But this still is very high on my list.

The good news is that JCE release builds are off the old build system.

Brad



 > , perhaps a review from someone else will be
> sufficient?
> /Erik
>
> On 2013-09-30 15:01, Erik Joelsson wrote:
>> Reposting an updated webrev for this:
>>
>> http://cr.openjdk.java.net/~erikj/8009280/webrev.03/
>>
>> From what I can tell, this changes the jdk (default) target to create
>> a valid jce layout. The jdk_security* tests are not failing for me.
>> There will likely be more issues to resolve for the JCE team, but this
>> should cover what's reported in this particular bug.
>>
>> /Erik
>>
>> On 2013-08-16 11:35, Erik Joelsson wrote:
>>> Woops, as some of you pointed out, I missed adding the link to the
>>> webrev:
>>>
>>> http://cr.openjdk.java.net/~erikj/8009280/webrev.02/
>>>
>>> /Erik
>>>
>>> On 2013-08-16 10:46, Erik Joelsson wrote:
>>>> Finally able to revisit this patch:
>>>>
>>>> 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/... directories.
>>>>
>>>> Also did:
>>>> * Removed now redundant entries in rt.jar exclude list
>>>> * Changed source location for signing unsigned jars
>>>> * Made the SetupJavaCompilation macro more friendly with multiple
>>>> setups sharing output directories.
>>>>
>>>> The reason it had to wait was that this design did not work with
>>>> sjavac. Sjavac has now been fixed in jdk8-tl.
>>>>
>>>> /Erik
>>
>