I also opened a ticket about the bugzilla to jira part: https://issues.apache.org/jira/browse/INFRA-15282
On 14 October 2017 at 13:15, Matt Sicker <boa...@gmail.com> wrote: > 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> > -- Matt Sicker <boa...@gmail.com>
