I would really stay away from Java 9 at this point. There is too much incompatible tooling out there at this point. I can't even run most apps out of the box I have laying around on Java 9 without breakage.
Gary On Sat, Oct 14, 2017 at 12:09 PM, Matt Sicker <boa...@gmail.com> wrote: > I forgot to mention my current difficulty in the release process are broken > tests. I just noticed that my default Java version on this computer is > actually 9, not 8, so that could be related. Any guidance from anyone who's > successfully built this before would be great. > > On 14 October 2017 at 13:01, Matt Sicker <boa...@gmail.com> wrote: > > > First off, for some reason, there are two repositories: > > > > https://github.com/apache/chainsaw > > https://github.com/apache/logging-chainsaw > > > > The second one appears to be up to date. Not sure what to do about the > > first one as it seems to be a relic of when Chainsaw was in SVN. > > > > Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It was > > tracked as a component of Log4j 1. See this: <https://bz.apache.org/ > > bugzilla/buglist.cgi?bug_status=__open__&component= > > chainsaw&product=Log4j%20-%20Now%20in%20Jira>. I believe it would be > > useful to switch over to JIRA like we're using for the rest of the > logging > > projects. Perhaps we can ask infra for some sort of issue transfer if > > possible. > > > > Another issue: the Java source version is set to 1.4. That means it > > doesn't even compile using Java 8 due to 1.6 being the oldest source > > version usable. That also means that this project hasn't been updated to > > use generics let alone anything else from the past 13 years (Java 5 was > > released in 2004 back when I was learning how to program in the first > > place!). As such, incrementing the base Java version to 1.6 would be a > > minimum change, and I think if we increased to Java 8 or 9 after a > release, > > that would give us a nice opportunity to do some mechanical refactorings > > and such which can sometimes be fun. > > > > Really, though, the choice of Java version or JVM language in general for > > a modernized version should be determined by whoever is interested in > > helping clean everything up and move forward. In that case, since I feel > a > > bit interested here, I'd propose going with either Java 9 or Scala 2.12 > > (Scala provides a neat Swing API wrapper as well). Kotlin could also be a > > contender here, though I haven't used it much at all yet, so I can't > really > > make a real recommendation there. There's also the option of migrating > from > > Swing to JavaFX if there is interest, though I've never really used > JavaFX > > before (but have used Swing). > > > > Then there is the notion of distribution. Since this is a GUI app, it's > > not generally as simple as just publishing to Maven Central. Naturally, > the > > standard Apache release process of publishing sources and binaries to SVN > > works fine, but there are additional options we can consider: > > * Publish a Java webstart thing (would require working with infra to get > > the releases signed; current build instructions tell the user how to > create > > their own release using a signing key and such) > > * Publish a macOS .app bundle. This can be published through our normal > > release channel, but there may also be a way to publish to the Mac App > > Store. Also, a Homebrew formula (or cask) for this would be nice, though > > they're normally maintained by external package maintainers just like in > > GNU/Linux distros. > > * Publish a native-ish Windows bundle. I don't see anything in the build > > already, but there are some tools out there to distribute a Java GUI app > > for Windows that could be useful here. > > > > I have other ideas I'd like to see such as adding support for the JSON > > layout and future binary layouts (e.g., Avro/Thrift/Protobuf/custom > binary > > logging format) so there is no reliance on serialized log events or > dealing > > with ambiguous log files. I'm pretty sure I could come up with a nice > > backlog here, and we could try to recruit some interested developers > > through helpwanted.a.o and potentially next time we have Google Summer of > > Code or other similar hackathon-like things. In general, I always find > the > > viewing and searching of logs to be a pain regardless of fancy tools like > > ELK or Graylog or Splunk, and having a nice local GUI to sort through it > > all could be super useful, and I'd be interested to see this succeed in > > that. > > > > With all that in mind, who would be interested in helping out on this? > I'm > > having difficulty with the current version getting compiled let alone > > getting a release cut, so I'm not even sure how feasible it would be to > cut > > a release before going ahead with the next generation. If we start > working > > on a major version of Chainsaw without a release for the existing code, > > would that need to take place in the incubator, or can we go forward > here? > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > > > -- > Matt Sicker <boa...@gmail.com> >
