Hi Matt, It seems to me that to get out of the mess we are currently in, we need to publish something official ASAP, even it is just an alpha or beta.
Toward this goal, we should make the least amount of changes as possible. Changing the source to 1.6 seems like a requirement to use modern tooling. Then we can take it one step at a time. I like the idea of having a longer term road map, which, based on your messages, would be a long one full of milestones! :-) I'm not sure how much I'll be able to help but you can count on me here and there ;-) Gary On Sat, Oct 14, 2017 at 12:01 PM, 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> >
