I've committed the artifacts to svn <
https://dist.apache.org/repos/dist/release/logging/log4j/scala/11.0/> and
released the staging repo to Maven Central (minus the samples and dist
artifacts). I also updated reporter.apache.org. What remains now is to wait
a bit for mirrors to catch up, then we c
+1 from me.
This vote passes with 3 +1 votes from myself, Gary, and Mikael. I'll
continue with the release.
On 23 July 2017 at 21:10, Matt Sicker wrote:
> Away from computer at the moment, but yes, I'll be taking care of this as
> soon as possible.
>
> On 23 July 2017 at 18:54, Gary Gregory wr
Away from computer at the moment, but yes, I'll be taking care of this as
soon as possible.
On 23 July 2017 at 18:54, Gary Gregory wrote:
> I did not see a VOTE RESULT message. I'm sure Matt will get to it.
>
> Gary
>
> On Sat, Jul 22, 2017 at 2:14 PM, Ralph Goers
> wrote:
>
> > Is this a vote
I did not see a VOTE RESULT message. I'm sure Matt will get to it.
Gary
On Sat, Jul 22, 2017 at 2:14 PM, Ralph Goers
wrote:
> Is this a vote thread or a discussion thread? Was there a vote result?
>
> Ralph
>
> > On Jul 22, 2017, at 12:56 PM, Matt Sicker wrote:
> >
> > Yup, that's the plan. I
Is this a vote thread or a discussion thread? Was there a vote result?
Ralph
> On Jul 22, 2017, at 12:56 PM, Matt Sicker wrote:
>
> Yup, that's the plan. It doesn't save much in compile/test time on the main
> repo, but it's a nice start, and it also allows us to maintain the Scala
> API on it
Yup, that's the plan. It doesn't save much in compile/test time on the main
repo, but it's a nice start, and it also allows us to maintain the Scala
API on its own which may be useful (e.g., using a Scala-specific build
tool).
On 21 July 2017 at 16:19, Gary Gregory wrote:
> And then, you'll remo
And then, you'll remove the Scala modules from the main repo's master?
Gary
On Fri, Jul 21, 2017 at 11:30 AM, Matt Sicker wrote:
> Agreed. I'll finish this up either today or over the weekend.
>
> On 21 July 2017 at 07:17, Mikael Ståldal wrote:
>
> > Then I don't think this should block our re
Agreed. I'll finish this up either today or over the weekend.
On 21 July 2017 at 07:17, Mikael Ståldal wrote:
> Then I don't think this should block our release.
>
>
> On 2017-07-21 05:30, Matt Sicker wrote:
>
>> Logged internally: https://issues.apache.org/jira/browse/LOG4J2-1983
>>
>> On 20 Ju
Then I don't think this should block our release.
On 2017-07-21 05:30, Matt Sicker wrote:
Logged internally: https://issues.apache.org/jira/browse/LOG4J2-1983
On 20 July 2017 at 22:22, Matt Sicker wrote:
I did find this Scala issue: https://github.com/scala/bug/issues/10417
On 20 July 2017
Logged internally: https://issues.apache.org/jira/browse/LOG4J2-1983
On 20 July 2017 at 22:22, Matt Sicker wrote:
> I did find this Scala issue: https://github.com/scala/bug/issues/10417
>
> On 20 July 2017 at 22:07, Gary Gregory wrote:
>
>> On Thu, Jul 20, 2017 at 7:22 PM, Matt Sicker wrote:
I did find this Scala issue: https://github.com/scala/bug/issues/10417
On 20 July 2017 at 22:07, Gary Gregory wrote:
> On Thu, Jul 20, 2017 at 7:22 PM, Matt Sicker wrote:
>
> > As for the 2.12 IBM JDK bug, could be worth filing a jira ticket over it.
> >
>
> Creating a JIRA/issue where though?
That would probably help, though I meant tracking it in our jira. Unless
you think we should try to fix this or find a root cause before releasing
11.0. I'm not sure if IBM JDK is compatible with Scala 2.12 in the first
place, so it might be a bug on their end.
On 20 July 2017 at 22:07, Gary Grego
On Thu, Jul 20, 2017 at 7:22 PM, Matt Sicker wrote:
> As for the 2.12 IBM JDK bug, could be worth filing a jira ticket over it.
>
Creating a JIRA/issue where though? In IBM's system?
Gary
> Since they don't seem to publish the IBM JDK for macOS, that may make it
> harder to test a fix, but we
On Thu, Jul 20, 2017 at 7:35 PM, Matt Sicker wrote:
> I looked into this a bit more. If we made a 2.13 release now, we'd have to
> name the module more specifically. In this case, it'd be
> "log4j-api-scala_2.13.0-M1". The version number in the module name can be
> as specific as the exact compil
I looked into this a bit more. If we made a 2.13 release now, we'd have to
name the module more specifically. In this case, it'd be
"log4j-api-scala_2.13.0-M1". The version number in the module name can be
as specific as the exact compiler version (which is more important for
compiler plugins than
As for the 2.12 IBM JDK bug, could be worth filing a jira ticket over it.
Since they don't seem to publish the IBM JDK for macOS, that may make it
harder to test a fix, but we can possibly make a Dockerfile for it.
On 20 July 2017 at 21:18, Matt Sicker wrote:
> To test for 2.13.0, we'd need to m
To test for 2.13.0, we'd need to make a 2.13.0 jar for log4j-api-scala. You
can try it out by either copying or modifying the 2.12 one and changing the
compiler version. Using sbt, it's a bit easier to cross compile various
versions (future goal in this repo). I'm not sure if it's such a great idea
HI Matt,
- 2.10.6 Hello, world!
- 2.11.8 Hello, world!
- 2.11.11 Hello, world!
- 2.12.1 crashes
- 2.12.0 crashes
How do I update the sbt file to test 2.13.0-M1?
Gary
On Thu, Jul 20, 2017 at 6:27 PM, Matt Sicker wrote:
> Can you try changing the Scala version in build.sbt to
Can you try changing the Scala version in build.sbt to 2.11.8 or 2.10.6?
Those only require Java 6 btw.
On 20 July 2017 at 16:58, Gary Gregory wrote:
> Here is the JVM dump, not that we can do anything about it! :-P
>
> https://gist.githubusercontent.com/garydgregory/
> 1e8d78d6305fe5379efccf76f
Here is the JVM dump, not that we can do anything about it! :-P
https://gist.githubusercontent.com/garydgregory/1e8d78d6305fe5379efccf76fadf0b25/raw/1411977cea9a14328f17ff99f35bfc951c1eb1c0/javacore.20170720.133045.13856.0004.txt
Gary
On Thu, Jul 20, 2017 at 2:53 PM, Gary Gregory
wrote:
> In i
In installed SBT and ran: 'sbt clean run' and it hangs hard with IBM Java,
CTRL-C does nothing: https://pastebin.com/HWYniJXB
Gary
On Thu, Jul 20, 2017 at 1:25 PM, Matt Sicker wrote:
> The sbt script is just added for convenience in case you don't have sbt
> installed already. Regardless, sbt h
The sbt script is just added for convenience in case you don't have sbt
installed already. Regardless, sbt has to download itself as it is similar
to gradle's wrapper.
On 20 July 2017 at 14:38, Mikael Ståldal wrote:
> You could install SBT on your Windows machine, and build/run the project
> wit
You could install SBT on your Windows machine, and build/run the project
without using the "sbt" script in Matt's repo.
http://www.scala-sbt.org/0.13/docs/Installing-sbt-on-Windows.html
On 2017-07-20 21:21, Gary Gregory wrote:
Hi Matt,
I'm on Windows, so that sbt script is not going to work
You can just download SBT from their site and it'll work:
http://www.scala-sbt.org/download.html
On 20 July 2017 at 14:21, Gary Gregory wrote:
> Hi Matt,
>
> I'm on Windows, so that sbt script is not going to work for me.
>
> I did try it on Cygwin but no dice (unsurprisingly):
>
> $ ./sbt run
>
Hi Matt,
I'm on Windows, so that sbt script is not going to work for me.
I did try it on Cygwin but no dice (unsurprisingly):
$ ./sbt run
./sbt: line 5: $'\r': command not found
: invalid option nameipefail
./sbt: line 7: $'\r': command not found
./sbt: line 10: $'\r': command not found
./sbt: l
I just tried a Maven build again with the IBM JDK and it still crashes but
the build ends this time: https://pastebin.com/Lgq98MjF
Gary
On Thu, Jul 20, 2017 at 12:14 PM, Matt Sicker wrote:
> https://github.com/jvz/test-log4j-scala
>
> Clone this and run "sbt run" or "./sbt run". It should print
https://github.com/jvz/test-log4j-scala
Clone this and run "sbt run" or "./sbt run". It should print out a single
info-level "Hello, world!" log message.
On 20 July 2017 at 14:03, Matt Sicker wrote:
> I can write a test project that you can try out with the IBM JDK. I'll
> push something to Git
I can write a test project that you can try out with the IBM JDK. I'll push
something to GitHub this afternoon.
On 20 July 2017 at 13:59, Gary Gregory wrote:
> On Thu, Jul 20, 2017 at 11:54 AM, Mikael Ståldal wrote:
>
> > On 2017-07-20 03:16, Gary Gregory wrote:
> >
> >> I noticed WARNINGs like
On Thu, Jul 20, 2017 at 11:54 AM, Mikael Ståldal wrote:
> On 2017-07-20 03:16, Gary Gregory wrote:
>
>> I noticed WARNINGs like:
>>
>> [INFO] --- scala-maven-plugin:3.2.2:compile (default) @
>> log4j-api-scala_2.11 ---
>> [WARNING] Expected all dependencies to require Scala version: 2.11.8
>> [W
On 2017-07-20 03:16, Gary Gregory wrote:
I noticed WARNINGs like:
[INFO] --- scala-maven-plugin:3.2.2:compile (default) @
log4j-api-scala_2.11 ---
[WARNING] Expected all dependencies to require Scala version: 2.11.8
[WARNING] org.apache.logging.log4j:log4j-api-scala_2.11:11.0 requires
scala ve
+1
- ASC, MD5 and SHA1 are OK on src zip.
- Building it worked for me from the src zip with 'mvn clean install site'.
- RAT check OK.
- I did not try to use build products from Scala.
Using:
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T12:39:06-07:00)
Maven home: C:\J
So we're reaching the same state as the first release candidate: 1 cast
vote, 1 implicit vote (I'll wait), and still no 3rd vote. Can I get another
vote?
On 17 July 2017 at 10:13, Matt Sicker wrote:
> Agreed. I've been using 11.0-SNAPSHOT in my projects at work for a while
> now as it is.
>
> On
Agreed. I've been using 11.0-SNAPSHOT in my projects at work for a while
now as it is.
On 17 July 2017 at 07:39, Mikael Ståldal wrote:
> Changing the artifactId would be annoying for the users who are already
> using this (the Scala API has already been publicly released quite some
> time ago th
Changing the artifactId would be annoying for the users who are already
using this (the Scala API has already been publicly released quite some
time ago through the main repo). I don't like that.
On 2017-07-16 23:04, Ralph Goers wrote:
To address Gary’s issues I think it would be better to us
Can't we just go on with what we decieded months ago? I think it's a bit
late to change it now, and everyone has have the oppourtnity to discuss
this for a long time.
On 2017-07-16 23:04, Ralph Goers wrote:
To address Gary’s issues I think it would be better to use a different module
name an
If the version number is an issue and we'd prefer a different module name
with a version 1.0, then everything changes quite a bit. If we want to use
a smaller version number as the initial release, that's a lot simpler.
On 16 July 2017 at 18:34, Matt Sicker wrote:
> A bit like Java 9 when you th
A bit like Java 9 when you think of it. ;)
I'm not sure why they used an artefact naming scheme rather than use
classifiers or something more sensible, but then again, I'm not sure if Ivy
supports that as it is (it seems as though every JVM build tool other than
Maven still uses Ivy).
On 16 July
Ah right, since Scale is fond on breaking compatibility.
Gary
On Jul 16, 2017 14:49, "Ralph Goers" wrote:
> Apparently the module name has to have a Scala version number in it.
>
> Ralph
>
> > On Jul 16, 2017, at 2:41 PM, Gary Gregory
> wrote:
> >
> > Like log4j-api-scala-wrapper?
> >
> > Gary
Apparently the module name has to have a Scala version number in it.
Ralph
> On Jul 16, 2017, at 2:41 PM, Gary Gregory wrote:
>
> Like log4j-api-scala-wrapper?
>
> Gary
>
> On Jul 16, 2017 14:04, "Ralph Goers" wrote:
>
>> To address Gary’s issues I think it would be better to use a differen
Like log4j-api-scala-wrapper?
Gary
On Jul 16, 2017 14:04, "Ralph Goers" wrote:
> To address Gary’s issues I think it would be better to use a different
> module name and start from version 1.0.
>
> Ralph
>
> > On Jul 16, 2017, at 1:43 PM, Gary Gregory
> wrote:
> >
> > I know... :-(
> >
> > The
To address Gary’s issues I think it would be better to use a different module
name and start from version 1.0.
Ralph
> On Jul 16, 2017, at 1:43 PM, Gary Gregory wrote:
>
> I know... :-(
>
> The checksums are generated either by some Maven plugin or Nexus.
>
> Gary
>
> On Sun, Jul 16, 2017 a
I know... :-(
The checksums are generated either by some Maven plugin or Nexus.
Gary
On Sun, Jul 16, 2017 at 1:38 PM, Mikael Ståldal wrote:
> The md5sum and sha1sum tools are able to do the comparations themself if
> the checksum file contains the filename, which those checksum files
> doesn't
The md5sum and sha1sum tools are able to do the comparations themself if
the checksum file contains the filename, which those checksum files
doesn't. Why not?
We need to automate this, it's tedious and error-prone to do all this
checksum verification manually.
On 2017-07-16 22:29, Gary Greg
On Sun, Jul 16, 2017 at 1:27 PM, Mikael Ståldal wrote:
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /opt/apache-maven-3.3.9
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /opt/jvm/jdk1.8.0_131/jre
> Default locale:
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/apache-maven-3.3.9
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /opt/jvm/jdk1.8.0_131/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-8
As a PMC, we think we need to better document our "+1"s than "Everything
seems fine."
For example: Did you check the ASC, MD5 and SHA1 files?
_How_ exactly does it "seem" fine?
What JDK(s) did you use to build? What did you build? From what? The tag?
The zip?
And so on.
Gary
On Sun, Jul 16, 2
Why is the Maven module name so important?
On 2017-07-16 21:11, Gary Gregory wrote:
I like my rename suggestion the best which makes the actual version number
less confusing (for me) even if it could be somewhat misleading due to
version inflation.
And I'll leave it at that ;-)
Gary
On Sun,
I like my rename suggestion the best which makes the actual version number
less confusing (for me) even if it could be somewhat misleading due to
version inflation.
And I'll leave it at that ;-)
Gary
On Sun, Jul 16, 2017 at 12:02 PM, Matt Sicker wrote:
> I also considered starting with version
+1
Everything seems fine.
On 2017-07-16 18:41, Matt Sicker wrote:
Hello all, sorry for the delay between release candidates. This is a vote
to release RC2 of Log4j Scala API 11.0, the first release of the new
repository. The main features in this release are Scala 2.12 support and an
API for m
I also considered starting with version 1.0, but since we've already
released a few versions in the 2.x line of this exact groupId/artifactId
combo, it wouldn't make sense to start anywhere earlier than 2.8.2
currently.
On 16 July 2017 at 13:52, Matt Sicker wrote:
> This only requires log4j-api
This only requires log4j-api as a dependency, and as we've seen in
log4j-core et al, we can require a minimum log4j-api version and simply
release the Scala API after log4j-core releases. It'll be too confusing if
the version numbers were similar.
Perhaps it might make more sense to use version 3.
Would it be unreasonable to call this Log4jScala? Then you do not have to
deal with the whole "for Log4j API" postfix.
Alternatively "*Log4j API **wrapper **for Scala 2.10 11.0*"
Gary
On Sun, Jul 16, 2017 at 11:37 AM, Mikael Ståldal wrote:
> This is version 11.0 of the Scala 2.10 wrapper for
This is version 11.0 of the Scala 2.10 wrapper for Log2j API.
"version 11.0" applies to "Scala 2.10 wrapper for Log2j API", not to
"Log2j API". The Maven output make this a bit unclear, not sure what we
can do about it.
On 2017-07-16 20:32, Gary Gregory wrote:
On Sun, Jul 16, 2017 at 11:27
On Sun, Jul 16, 2017 at 11:27 AM, Gary Gregory
wrote:
> On Sun, Jul 16, 2017 at 11:17 AM, Gary Gregory
> wrote:
>
>> This is confusing. What are we doing an RC for here? One wrapper? Or all
>> of them? Why is this version 11? There is no version 11 of anything. There
>> is Scala 2.11 that I see.
On Sun, Jul 16, 2017 at 11:28 AM, Matt Sicker wrote:
> On 16 July 2017 at 13:27, Gary Gregory wrote:
> >
> > "Building Scala 2.10 wrapper for Log4j API 11.0"
> >
> > Where do you see this?
>
Maven build output.
Gary
>
>
> > Uh?
> >
> > Gary
> >
> >
> > >
> > > Gary
> > >
> > > On Sun, Jul 16,
On Sun, Jul 16, 2017 at 11:25 AM, Mikael Ståldal wrote:
> We decided to decouple the versioning of this Scala API from the rest of
> Logj4, therefore we bumped the version up to 11.0 to make that clear. The
> 11 is not related to Scala 2.11.
>
Still arbitrary silliness AND confusing why not vers
On 16 July 2017 at 13:27, Gary Gregory wrote:
>
> "Building Scala 2.10 wrapper for Log4j API 11.0"
>
> Where do you see this?
> Uh?
>
> Gary
>
>
> >
> > Gary
> >
> > On Sun, Jul 16, 2017 at 9:41 AM, Matt Sicker wrote:
> >
> >> Hello all, sorry for the delay between release candidates. This is a
On Sun, Jul 16, 2017 at 11:17 AM, Gary Gregory
wrote:
> This is confusing. What are we doing an RC for here? One wrapper? Or all
> of them? Why is this version 11? There is no version 11 of anything. There
> is Scala 2.11 that I see. Is this a typo?
>
> When I dig a round the repo site from the l
I'm not sure what plugins are available for Scala builds yet as I'm still
rather new to the Scala ecosystem. I was thinking it might be simpler to
find this stuff by switching to SBT for this subproject, though I'll still
have to explore a bit to find out.
On 16 July 2017 at 13:26, Gary Gregory w
Never mind about CLIRR blowing up, I was using Java 7, instead of 8.
Gary
On Sun, Jul 16, 2017 at 11:26 AM, Gary Gregory
wrote:
> Is there a CLIRR plugin for Scala? 'cause 'mvn clean clirr:check' blows up.
>
>
> Gary
>
> On Sun, Jul 16, 2017 at 9:41 AM, Matt Sicker wrote:
>
>> Hello all, sorry
This is purely the Log4j Scala API. We're releasing it separately now
because it requires Java 8 to build to support Scala 2.12.
The version is 11 because it's on its own release train, so we jumped ahead.
On 16 July 2017 at 13:17, Gary Gregory wrote:
> This is confusing. What are we doing an R
We decided to decouple the versioning of this Scala API from the rest of
Logj4, therefore we bumped the version up to 11.0 to make that clear.
The 11 is not related to Scala 2.11.
The important thing here is supporting Scala 2.12 (which requires Java 8).
On 2017-07-16 20:17, Gary Gregory wrot
Is there a CLIRR plugin for Scala? 'cause 'mvn clean clirr:check' blows up.
Gary
On Sun, Jul 16, 2017 at 9:41 AM, Matt Sicker wrote:
> Hello all, sorry for the delay between release candidates. This is a vote
> to release RC2 of Log4j Scala API 11.0, the first release of the new
> repository.
This is confusing. What are we doing an RC for here? One wrapper? Or all of
them? Why is this version 11? There is no version 11 of anything. There is
Scala 2.11 that I see. Is this a typo?
When I dig a round the repo site from the link, I found a distro zip, which
includes ALL the wrappers. OK, g
Hello all, sorry for the delay between release candidates. This is a vote
to release RC2 of Log4j Scala API 11.0, the first release of the new
repository. The main features in this release are Scala 2.12 support and an
API for manipulating the ThreadContext.
Artifacts are available in this staging
65 matches
Mail list logo
