I’ve worked with JavaFX. It is pretty easy. I have zero interest in working with Swing.
I’d prefer to get away from WebStart. I think that may have been what hung up Scott in the first place as he needed a cert. Some of the other technologies for binary deployment make sense to me. To be honest, I’ve never run Chainsaw or Lillith. I am not sure how they differ. I am not a big fan of having two projects that do exactly the same thing so I’d like some understanding of what they do and how they differ. Ralph > On Oct 14, 2017, at 11:01 AM, 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>
