Actually, I had a better idea.
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.
Opinions? Does this need a vote?
Cheers,
Greg Trasuk.
On Nov 19, 2014, at 3:19 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> Hi all:
>
> I’m working on getting the build system, particularly ‘classdepandjar’ to
> work under JDK8. While I’m in there, I’m wondering if I should rename the
> affected package, ‘com.sun.jini.tool’, to ‘org.apache.river.tool’ or some
> such thing.
>
> Any opinions? I would have to change the reference to classdepandjar in the
> build scripts, but obviously it would also affect any external build scripts
> that use it. I suppose I could leave a wrapper class in ‘com.sun.jini.tool’
> so as not to affect build scripts.
>
> Opinions?
>
> Cheers,
>
> Greg Trasuk
>
