river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Trasuk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RIVER-444) Extract classdep and other tools to a separate project and upgrade to JDK1.8
Date Sun, 14 Dec 2014 18:39:13 GMT

    [ https://issues.apache.org/jira/browse/RIVER-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246047#comment-14246047

Greg Trasuk commented on RIVER-444:

ProfilingSecurityManager was removed from the production branch as part of a cleanup of license
headers (it wasn't developed as part of River):

<--Begin commit message -->
URL: http://svn.apache.org/r1540532 Log: Added Apache license header to
com.sun.jini.jeri.internal.runtime.SequenceEntry.java (It was part of the
original code donation).

Remove com.sun.jini.tool.ProfilingSecurityManager. Although its license was
compatible with AL2.0, it wasn't original to Jini, and it is readily available
on the web. 
<-- End commit message --> 

Could you expand on your concerns about putting DebugDynamicPolicyProvider into net.jini.security.policy?
 To me, it seems like a natural place for it.

As it stands now, DebugDynamicPolicyProvider is present in the project at https://svn.apache.org/repos/asf/river/river-rt-tools/trunk,
but it would seem natural to put it with the other security policy.

> Extract classdep and other tools to a separate project and upgrade to JDK1.8
> ----------------------------------------------------------------------------
>                 Key: RIVER-444
>                 URL: https://issues.apache.org/jira/browse/RIVER-444
>             Project: River
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: River_2.2.2
>            Reporter: Greg Trasuk
> Currently the build system in the 2.2 branch includes the classdep tool, which is built
in an early phase of the build.  It uses ASM3.2, which fails under JDK8.
> I proposed on the mailing list to remove the tools package to a separate project as follows:
> How about if I pull out the ‘tools’ package to a separate Maven project and integrate
the changes that Peter did on qa_refactor?  Then both the 2.2 branch and qa_refactor can use
the same tools.
> Process would be as follows:
> - Create a project in Apache git repo for ‘river-tools’
> - Create a Maven project (I’ll have a look at the modularization that Dennis did, I
suspect this is already done) in that repository
> - Integrate Peter’s updates from qa-refactor (which update to use asm-5 in classdep)
> - Do a release on river-tools, so that tools.jar can go into Maven Central 
> - Remove tools packages from 2.2. branch.  Modify build to get tools.jar from Central
rather than building it.
> 	- I can update qa_refactor at the same time.
> - Roll a release of the 2.2. branch.
> Which will leave a 2.2. release that builds under JDK1.8, qa_refactor that uses the same
tool, and one less piece of build system confusion to put off new committers.

This message was sent by Atlassian JIRA

View raw message