You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Mikael Ståldal <mi...@apache.org> on 2017/07/06 20:15:23 UTC
Re: [Log4j] release 2.9 - Scala API
Yes, I think that the 11.0 release of the Scala API should only be what
we currently have in 2.8.2 plus Scala 2.12 support plus the already
implemented ThreadContext wrapper in LOG4J2-1690.
Basically just release what we currently have in the logging-log4j-scala
Git repo.
On 2017-07-05 23:28, Matt Sicker wrote:
> So 11.0 would have the old name, and 12.0 would have the new name?
> That would be fine with me. That also gives us an opportunity to look into
> Scalameta for simpler macro portability going forward considering I keep
> seeing deprecation warnings all over the place in the existing macro API.
Re: [Log4j] release 2.9 - Scala API
Posted by Matt Sicker <bo...@gmail.com>.
I won't be able to help out with that until next week at the earliest. I'm
preparing a presentation this weekend (coincidentally one about Scala
actually), but things are starting to simmer down finally.
On 7 July 2017 at 13:39, Mikael Ståldal <mi...@apache.org> wrote:
> It would be good if you could finalize the release of logging-log4j-scala.
> I am ready to help.
>
>
> On 2017-07-07 01:04, Matt Sicker wrote:
>
>> The code as is should be ready for source and binary artifacts I believe.
>> I
>> don't recall if there was a distribution zip task already set up, though,
>> and I believe that's the minimal required artifacts for an Apache release.
>>
>> On 6 July 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Thu, Jul 6, 2017 at 2:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I attempted a release, and we fixed something, but I was still unsure as
>>>>
>>> to
>>>
>>>> how to build the website as the site:stage goal fails with missing file
>>>> errors if I recall correctly. Since then, I've been busy with a short
>>>>
>>> term
>>>
>>>> work project eating up all my energy, so I haven't had a chance to make
>>>> another rc, though without the site, it's not really a release now is
>>>> it?
>>>> :/
>>>>
>>>>
>>> Well, strictly speaking, Apache delivers sources (see Subversion),
>>> binaries
>>> and site? Pft! A mere convenience! Just JOKING of course. Putting our
>>> jars
>>> in Maven Central is a must these days.
>>>
>>> Gary
>>>
>>>
>>>> On 6 July 2017 at 15:35, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> Don’t we still need to get Scala integrated into the web site? Can we
>>>>>
>>>> do
>>>
>>>> that before the 2.9 release? Or has a Scala release not been done yet?
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Jul 6, 2017, at 1:15 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>>>>>
>>>>>> Yes, I think that the 11.0 release of the Scala API should only be
>>>>>>
>>>>> what
>>>
>>>> we currently have in 2.8.2 plus Scala 2.12 support plus the already
>>>>> implemented ThreadContext wrapper in LOG4J2-1690.
>>>>>
>>>>>>
>>>>>> Basically just release what we currently have in the
>>>>>>
>>>>> logging-log4j-scala
>>>>
>>>>> Git repo.
>>>>>
>>>>>>
>>>>>>
>>>>>> On 2017-07-05 23:28, Matt Sicker wrote:
>>>>>>
>>>>>>> So 11.0 would have the old name, and 12.0 would have the new name?
>>>>>>>
>>>>>> That
>>>>
>>>>> would be fine with me. That also gives us an opportunity to look into
>>>>>
>>>>>> Scalameta for simpler macro portability going forward considering I
>>>>>>>
>>>>>> keep
>>>>
>>>>> seeing deprecation warnings all over the place in the existing macro
>>>>>>>
>>>>>> API.
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>
>>
>>
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] release 2.9 - Scala API
Posted by Mikael Ståldal <mi...@apache.org>.
It would be good if you could finalize the release of
logging-log4j-scala. I am ready to help.
On 2017-07-07 01:04, Matt Sicker wrote:
> The code as is should be ready for source and binary artifacts I believe. I
> don't recall if there was a distribution zip task already set up, though,
> and I believe that's the minimal required artifacts for an Apache release.
>
> On 6 July 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Thu, Jul 6, 2017 at 2:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I attempted a release, and we fixed something, but I was still unsure as
>> to
>>> how to build the website as the site:stage goal fails with missing file
>>> errors if I recall correctly. Since then, I've been busy with a short
>> term
>>> work project eating up all my energy, so I haven't had a chance to make
>>> another rc, though without the site, it's not really a release now is it?
>>> :/
>>>
>>
>> Well, strictly speaking, Apache delivers sources (see Subversion), binaries
>> and site? Pft! A mere convenience! Just JOKING of course. Putting our jars
>> in Maven Central is a must these days.
>>
>> Gary
>>
>>>
>>> On 6 July 2017 at 15:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>>> Don’t we still need to get Scala integrated into the web site? Can we
>> do
>>>> that before the 2.9 release? Or has a Scala release not been done yet?
>>>>
>>>> Ralph
>>>>
>>>>> On Jul 6, 2017, at 1:15 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>>>>
>>>>> Yes, I think that the 11.0 release of the Scala API should only be
>> what
>>>> we currently have in 2.8.2 plus Scala 2.12 support plus the already
>>>> implemented ThreadContext wrapper in LOG4J2-1690.
>>>>>
>>>>> Basically just release what we currently have in the
>>> logging-log4j-scala
>>>> Git repo.
>>>>>
>>>>>
>>>>> On 2017-07-05 23:28, Matt Sicker wrote:
>>>>>> So 11.0 would have the old name, and 12.0 would have the new name?
>>> That
>>>> would be fine with me. That also gives us an opportunity to look into
>>>>>> Scalameta for simpler macro portability going forward considering I
>>> keep
>>>>>> seeing deprecation warnings all over the place in the existing macro
>>>> API.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>
>
>
Re: [Log4j] release 2.9 - Scala API
Posted by Matt Sicker <bo...@gmail.com>.
The code as is should be ready for source and binary artifacts I believe. I
don't recall if there was a distribution zip task already set up, though,
and I believe that's the minimal required artifacts for an Apache release.
On 6 July 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Jul 6, 2017 at 2:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> > I attempted a release, and we fixed something, but I was still unsure as
> to
> > how to build the website as the site:stage goal fails with missing file
> > errors if I recall correctly. Since then, I've been busy with a short
> term
> > work project eating up all my energy, so I haven't had a chance to make
> > another rc, though without the site, it's not really a release now is it?
> > :/
> >
>
> Well, strictly speaking, Apache delivers sources (see Subversion), binaries
> and site? Pft! A mere convenience! Just JOKING of course. Putting our jars
> in Maven Central is a must these days.
>
> Gary
>
> >
> > On 6 July 2017 at 15:35, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> > > Don’t we still need to get Scala integrated into the web site? Can we
> do
> > > that before the 2.9 release? Or has a Scala release not been done yet?
> > >
> > > Ralph
> > >
> > > > On Jul 6, 2017, at 1:15 PM, Mikael Ståldal <mi...@apache.org> wrote:
> > > >
> > > > Yes, I think that the 11.0 release of the Scala API should only be
> what
> > > we currently have in 2.8.2 plus Scala 2.12 support plus the already
> > > implemented ThreadContext wrapper in LOG4J2-1690.
> > > >
> > > > Basically just release what we currently have in the
> > logging-log4j-scala
> > > Git repo.
> > > >
> > > >
> > > > On 2017-07-05 23:28, Matt Sicker wrote:
> > > >> So 11.0 would have the old name, and 12.0 would have the new name?
> > That
> > > would be fine with me. That also gives us an opportunity to look into
> > > >> Scalameta for simpler macro portability going forward considering I
> > keep
> > > >> seeing deprecation warnings all over the place in the existing macro
> > > API.
> > > >
> > >
> > >
> > >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] release 2.9 - Scala API
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jul 6, 2017 at 2:31 PM, Matt Sicker <bo...@gmail.com> wrote:
> I attempted a release, and we fixed something, but I was still unsure as to
> how to build the website as the site:stage goal fails with missing file
> errors if I recall correctly. Since then, I've been busy with a short term
> work project eating up all my energy, so I haven't had a chance to make
> another rc, though without the site, it's not really a release now is it?
> :/
>
Well, strictly speaking, Apache delivers sources (see Subversion), binaries
and site? Pft! A mere convenience! Just JOKING of course. Putting our jars
in Maven Central is a must these days.
Gary
>
> On 6 July 2017 at 15:35, Ralph Goers <ra...@dslextreme.com> wrote:
>
> > Don’t we still need to get Scala integrated into the web site? Can we do
> > that before the 2.9 release? Or has a Scala release not been done yet?
> >
> > Ralph
> >
> > > On Jul 6, 2017, at 1:15 PM, Mikael Ståldal <mi...@apache.org> wrote:
> > >
> > > Yes, I think that the 11.0 release of the Scala API should only be what
> > we currently have in 2.8.2 plus Scala 2.12 support plus the already
> > implemented ThreadContext wrapper in LOG4J2-1690.
> > >
> > > Basically just release what we currently have in the
> logging-log4j-scala
> > Git repo.
> > >
> > >
> > > On 2017-07-05 23:28, Matt Sicker wrote:
> > >> So 11.0 would have the old name, and 12.0 would have the new name?
> That
> > would be fine with me. That also gives us an opportunity to look into
> > >> Scalameta for simpler macro portability going forward considering I
> keep
> > >> seeing deprecation warnings all over the place in the existing macro
> > API.
> > >
> >
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [Log4j] release 2.9 - Scala API
Posted by Matt Sicker <bo...@gmail.com>.
I attempted a release, and we fixed something, but I was still unsure as to
how to build the website as the site:stage goal fails with missing file
errors if I recall correctly. Since then, I've been busy with a short term
work project eating up all my energy, so I haven't had a chance to make
another rc, though without the site, it's not really a release now is it? :/
On 6 July 2017 at 15:35, Ralph Goers <ra...@dslextreme.com> wrote:
> Don’t we still need to get Scala integrated into the web site? Can we do
> that before the 2.9 release? Or has a Scala release not been done yet?
>
> Ralph
>
> > On Jul 6, 2017, at 1:15 PM, Mikael Ståldal <mi...@apache.org> wrote:
> >
> > Yes, I think that the 11.0 release of the Scala API should only be what
> we currently have in 2.8.2 plus Scala 2.12 support plus the already
> implemented ThreadContext wrapper in LOG4J2-1690.
> >
> > Basically just release what we currently have in the logging-log4j-scala
> Git repo.
> >
> >
> > On 2017-07-05 23:28, Matt Sicker wrote:
> >> So 11.0 would have the old name, and 12.0 would have the new name? That
> would be fine with me. That also gives us an opportunity to look into
> >> Scalameta for simpler macro portability going forward considering I keep
> >> seeing deprecation warnings all over the place in the existing macro
> API.
> >
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] release 2.9 - Scala API
Posted by Ralph Goers <ra...@dslextreme.com>.
Don’t we still need to get Scala integrated into the web site? Can we do that before the 2.9 release? Or has a Scala release not been done yet?
Ralph
> On Jul 6, 2017, at 1:15 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
> Yes, I think that the 11.0 release of the Scala API should only be what we currently have in 2.8.2 plus Scala 2.12 support plus the already implemented ThreadContext wrapper in LOG4J2-1690.
>
> Basically just release what we currently have in the logging-log4j-scala Git repo.
>
>
> On 2017-07-05 23:28, Matt Sicker wrote:
>> So 11.0 would have the old name, and 12.0 would have the new name? That would be fine with me. That also gives us an opportunity to look into
>> Scalameta for simpler macro portability going forward considering I keep
>> seeing deprecation warnings all over the place in the existing macro API.
>