[
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
(v6.3.4#6332)
