I'm looking at the infra stuff right now. Found this: < https://issues.apache.org/jira/browse/INFRA-8439>. So it appears we may already have the webstart code signing thing handled. More info here: < https://blogs.apache.org/infra/entry/code_signing_service_now_available>.
On 14 October 2017 at 13:12, Gary Gregory <garydgreg...@gmail.com> wrote: > 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> > > > -- Matt Sicker <boa...@gmail.com>
