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 Tue, 09 Dec 2014 06:23:12 GMT

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

Greg Trasuk commented on RIVER-444:

Small complication - In the com.sun.jini.tools directory, there are two classes, 'ClassServer'
and 'DebugDynamicPolicyProvider', that have dependencies on classes that are elsewhere in
the source.  ClassServer depends on 'com.sun.jini.start.LifeCycle', and 'DebugDynamicPolicyProvider'
depends on several class in 'net.jini.security.policy'.

Also, there is another package, 'com.sun.jini.tools.envcheck' which has several dependencies
on the core API.

Fundamentally, the problem is that as it sits, the 'tools' package is a bit muddled:  part
of it is tools for building the system (classdep, jarwrapper, etc), and part of it is tools
for runtime (classserver, envcheck).  The runtime tools have a further dependency on the start
package.  Obviously the build tool portion should be built prior to the main packages, and
the runtime tool portion could be built after the main packages.

It would make sense to move the 'DebugDynamicPolicyProvider' into 'net.jini.security'.

ClassServer and envcheck present a bigger problem, however.  As runtime tools, they should
be in a separate deliverable (e.g. Maven module) from the build tools ( and it really doesn't
make any sense to include them in the same parent project as the build tools).  But pulling
them out into a separate deliverable would also imply pulling out the start package, the examples
and service-browser packages (which depend on start), and also the qa packages (which depend
on both start and the ClassServer).

All of which is not a bad thing, I think.  The build system ends up simplified, the project
gets more modular, we get closer to a "modular build" and new users can simply start out with
the examples project rather than the whole ball of string.  Also, merging back qa_refactor
would seem like less of an issues, because those modules could similarly be removed from that
branch.  But it does seem like quite a large change.

Any opinions?

> 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