logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikael Ståldal <mi...@apache.org>
Subject Re: Planning out what we can do to get Chainsaw back in the game
Date Sun, 15 Oct 2017 20:31:37 GMT
I also think it is a bit to early to depend on Java 9. However, we 
should depend on (and make use of) Java 8. Not sure if Java 9 give any 
substanstial benefits in this project (Java 8 definitely does).

If we want to rewrite it completely, I would go for Scala 2.12 (on JVM 
8). I don't think Kotlin is much used outside of Android, so Scala is 
probably a safer bet. (I would choose Kotlin for an Android app though.)


On 2017-10-14 20:12, Gary Gregory 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 <boards@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 <boards@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 <boards@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com>
>>
> 


Mime
View raw message