You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2017/02/24 04:07:22 UTC
Roadmap for 2.8.1
I'm hoping we can get this released soon as we have some bugfixes and such
ready to go. I also want to move forward with 2.9 changes but don't really
want to deal with creating a 2.9 branch or forking master into a 2.8
branch. Let's go over anything left to do for 2.8.1:
* Integrated log4j-api-scala website into main site
* Remove scala modules from logging-log4j2 repo
* Release scala modules from logging-log4j-scala repo (presumably shortly
after releasing 2.8.1 of core?)
I also have ideas on what we can shoot for in 2.9 and beyond, but that's
for another day. I think getting everything working properly in Java 9
would be a good thing to start doing soon so we can figure out if our APIs
will still work properly in the future or if we need to break backwards
compatibility. Although, multi-jar support could help in migrating the API
if needed for 9+, though that would be a rather unorthodox abuse of the
feature.
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
I've done a couple releases in this project so far (a Log4j and Logging
Parent release), so it shouldn't be too hard. I'm thinking we need to copy
over the log4j-distribution stuff so we can create source and binary
assemblies for uploading to apache.org as well.
On 8 March 2017 at 11:55, Mikael Ståldal <mi...@magine.com> wrote:
> I have never made any Apache release before, so it's probably good if
> someone more experienced does it the first time. So I would be grateful if
> Matt could do it.
>
> I can maybe do it the next time.
>
> On Mar 8, 2017 5:43 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>
>> If you don't have time to do it, Mikael, I could probably take care of
>> it. I'm planning on doing some Commons releases starting this week anyways,
>> and the process is fairly similar.
>>
>> On 8 March 2017 at 06:41, Apache <ra...@dslextreme.com> wrote:
>>
>>> Yes, go for it. You can look at the Log4J release guide although some
>>> steps won't apply.
>>>
>>> Ralph
>>>
>>> On Mar 8, 2017, at 5:32 AM, Remko Popma <re...@gmail.com> wrote:
>>>
>>> I won't be able to do it. :-) Why don't you give it a shot? I suspect
>>> you will be driving future changes often so it would be good if you can
>>> release such changes without having to wait for others to make time.
>>>
>>> Remko
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 8, 2017, at 18:45, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>> OK, I have updated the log4j-scala repo to bump version to 11.0, and
>>> note in README about independent versioning. It should now be ready for
>>> release. Who will do the release?
>>>
>>> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> Yes. Scala should be released asap and the site manually modified to
>>>> point to it. We would then modify the log4j source to permanently point
>>>> there.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> Ralph pointed out that we can't make a release of the main repo without
>>>> the scala modules until there is a release of the scala modules on their
>>>> own. Otherwise, there'd be a regression in the main repo by removing
>>>> modules that were there before.
>>>>
>>>> On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
>>>>
>>>>> No objection from me to release log4j-scala.
>>>>>
>>>>> Do you have a versioning scheme that lets log4j-scala and log4j
>>>>> upgrade independently?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com>
>>>>> wrote:
>>>>>
>>>>> Can we release log4j-scala now? Or to we have to wait for the next
>>>>> release of main repo with Scala modules removed? Should we remove the Scala
>>>>> modules from main repo now?
>>>>>
>>>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>>> The Scala language versions is already done the same standard way
>>>>>> everyone implements Scala libraries (hence the strange naming scheme we
>>>>>> already have). I'd imagine that the versions can be completely decoupled by
>>>>>> specifying a minimum Log4j API version it requires (though should generally
>>>>>> be whatever the latest was at release) and bumping its own version as new
>>>>>> features or bugfixes are added. I'd like to see that follow semantic
>>>>>> versioning properly, too.
>>>>>>
>>>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should
>>>>>>> be independent in both ways, right?
>>>>>>>
>>>>>>> I think I have coordination between log4j-scala and Scala language
>>>>>>> covered already.
>>>>>>>
>>>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Mikael, you probably need to plan your versioning scheme to handle
>>>>>>>> any combination of the following:
>>>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>>>>>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>>>>>>>> once they are decoupled, the log4j-scala modules won't be released
>>>>>>>> automatically with log4j anymore, someone needs to do the work for
>>>>>>>> a log4j-scala release separately.
>>>>>>>> * Scala releases: how do you want to sync up with Scala language
>>>>>>>> versions? (I guess include major&minor Scala version in the log4j-scala
>>>>>>>> module version)
>>>>>>>> * log4j-scala module versions: enhancements to these modules,
>>>>>>>> independent of the above
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I would like to keep package and artifact names, and bump version
>>>>>>>> to 11.0.
>>>>>>>>
>>>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> If you change artifact ids, it's generally a good idea to change
>>>>>>>>> packages, too. I've had issues in the past with Feign for instance because
>>>>>>>>> they changed groupId/artifactId at one point but kept the same API, so I
>>>>>>>>> had two copies on the classpath until I found out there was a duplicate and
>>>>>>>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>>>>
>>>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> You can do that, but that will probably confuse users too. I
>>>>>>>>>> would suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <
>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <
>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I guarantee if you try to keep the same versioning you will
>>>>>>>>>>> regret it.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <
>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I was under the impression that we were not ready to integrate
>>>>>>>>>>> the site from log4j-scala. That's why I considered the release of
>>>>>>>>>>> log4j-scala as delayed, since there is no point of releasing it if we
>>>>>>>>>>> cannot get the site integrated.
>>>>>>>>>>>
>>>>>>>>>>> But now when Ralph says he's ready to integrate the site, I
>>>>>>>>>>> guess we can go ahead and release log4j-scala.
>>>>>>>>>>>
>>>>>>>>>>> I don't like the idea of having separate versioning for
>>>>>>>>>>> log4j-scala, that will be confusing since we have already started with the
>>>>>>>>>>> same versioning as Log4j. Log4j-scala also have a dependency on log4j-api,
>>>>>>>>>>> and I think we want to keep that in sync.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> One issue we came across in practice is that Scala 2.12
>>>>>>>>>>>> requires Java 8, but we don't want to require that for the entire build, so
>>>>>>>>>>>> we separated the repo. This also helps avoid making the main log4j repo
>>>>>>>>>>>> from taking forever to build and release which can help the RERO idea.
>>>>>>>>>>>> Plus, these non-core modules don't change nearly as often as log4j-core or
>>>>>>>>>>>> log4j-api, so they don't really need new releases all that often.
>>>>>>>>>>>>
>>>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <
>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>>>>
>>>>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>>>>> * what different websites we are planning to create to give
>>>>>>>>>>>>> users access to these different modules
>>>>>>>>>>>>> * what websites are going to be driven from which modules or
>>>>>>>>>>>>> projects
>>>>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>>>>
>>>>>>>>>>>>> My lack of understanding is not just limited to the Scala
>>>>>>>>>>>>> modules but is about the whole splitting up the release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I
>>>>>>>>>>>>> think there's already a JIRA or an epic for the above. Adding some diagrams
>>>>>>>>>>>>> there would be very useful.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd be in favour of starting a new release train for the
>>>>>>>>>>>>>> Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you use that excuse they will never get released as it
>>>>>>>>>>>>>> creates a catch-22. If I release without them then we have a regression
>>>>>>>>>>>>>> until they are released.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the
>>>>>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or
>>>>>>>>>>>>>> whatever.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Once you create the release and deploy it to the web site I
>>>>>>>>>>>>>> can modify the web site to point to it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of
>>>>>>>>>>>>>> makes it harder to release from the log4j-scala repo when two of the three
>>>>>>>>>>>>>> artifacts will already exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the
>>>>>>>>>>>>>> next release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo
>>>>>>>>>>>>>> since I thought that it would be released as part of 2.8, otherwise I would
>>>>>>>>>>>>>> have put it to the main repo as well. But now releasing of the log4j-scala
>>>>>>>>>>>>>> repo has been delayed and I start to get disappointed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <
>>>>>>>>>>>>>> boards@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Relative symlinks would work for that regardless of version.
>>>>>>>>>>>>>> Option 1 it is, then?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink
>>>>>>>>>>>>>> so that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the
>>>>>>>>>>>>>> release manager for log4j-scala. In order for me to implement option 2 I
>>>>>>>>>>>>>> would have to include the log4j-scala site into the log4j release process -
>>>>>>>>>>>>>> as well as log4j-examples, etc if they move out. That is just not doable.
>>>>>>>>>>>>>> Deploying the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>>>>>>>> independently of log4j.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant;
>>>>>>>>>>>>>> that's a pretty ugly URL honestly)
>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but
>>>>>>>>>>>>>> you'd have to manage it alongside log4j core releases. Option 1 still
>>>>>>>>>>>>>> requires maintenance, too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is a specific location in svn where the site pages have
>>>>>>>>>>>>>> to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to
>>>>>>>>>>>>>> what I started doing with Log4j Boot. Add redirect pages or rewrite rules
>>>>>>>>>>>>>> via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the
>>>>>>>>>>>>>> main site. Depending on how you update the files in svn for a site update,
>>>>>>>>>>>>>> could this be more annoying to maintain?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would
>>>>>>>>>>>>>> really need a Scala site before we can modify the Log4j site, otherwise it
>>>>>>>>>>>>>> will be a dead link.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that
>>>>>>>>>>>>>> need fixes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>>>>>>>> mostly cosmetic.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <
>>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving
>>>>>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I really
>>>>>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue I see that
>>>>>>>>>>>>>> fixing now is the null classloader issue for which we have a patch but it
>>>>>>>>>>>>>> does not work for me (see JIRA).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <
>>>>>>>>>>>>>> boards@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some
>>>>>>>>>>>>>> bugfixes and such ready to go. I also want to move forward with 2.9 changes
>>>>>>>>>>>>>> but don't really want to deal with creating a 2.9 branch or forking master
>>>>>>>>>>>>>> into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo
>>>>>>>>>>>>>> (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond,
>>>>>>>>>>>>>> but that's for another day. I think getting everything working properly in
>>>>>>>>>>>>>> Java 9 would be a good thing to start doing soon so we can figure out if
>>>>>>>>>>>>>> our APIs will still work properly in the future or if we need to break
>>>>>>>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
I have never made any Apache release before, so it's probably good if
someone more experienced does it the first time. So I would be grateful if
Matt could do it.
I can maybe do it the next time.
On Mar 8, 2017 5:43 PM, "Matt Sicker" <bo...@gmail.com> wrote:
> If you don't have time to do it, Mikael, I could probably take care of it.
> I'm planning on doing some Commons releases starting this week anyways, and
> the process is fairly similar.
>
> On 8 March 2017 at 06:41, Apache <ra...@dslextreme.com> wrote:
>
>> Yes, go for it. You can look at the Log4J release guide although some
>> steps won't apply.
>>
>> Ralph
>>
>> On Mar 8, 2017, at 5:32 AM, Remko Popma <re...@gmail.com> wrote:
>>
>> I won't be able to do it. :-) Why don't you give it a shot? I suspect you
>> will be driving future changes often so it would be good if you can release
>> such changes without having to wait for others to make time.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>> On Mar 8, 2017, at 18:45, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> OK, I have updated the log4j-scala repo to bump version to 11.0, and note
>> in README about independent versioning. It should now be ready for release.
>> Who will do the release?
>>
>> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> Yes. Scala should be released asap and the site manually modified to
>>> point to it. We would then modify the log4j source to permanently point
>>> there.
>>>
>>> Ralph
>>>
>>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Ralph pointed out that we can't make a release of the main repo without
>>> the scala modules until there is a release of the scala modules on their
>>> own. Otherwise, there'd be a regression in the main repo by removing
>>> modules that were there before.
>>>
>>> On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
>>>
>>>> No objection from me to release log4j-scala.
>>>>
>>>> Do you have a versioning scheme that lets log4j-scala and log4j
>>>> upgrade independently?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com>
>>>> wrote:
>>>>
>>>> Can we release log4j-scala now? Or to we have to wait for the next
>>>> release of main repo with Scala modules removed? Should we remove the Scala
>>>> modules from main repo now?
>>>>
>>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> The Scala language versions is already done the same standard way
>>>>> everyone implements Scala libraries (hence the strange naming scheme we
>>>>> already have). I'd imagine that the versions can be completely decoupled by
>>>>> specifying a minimum Log4j API version it requires (though should generally
>>>>> be whatever the latest was at release) and bumping its own version as new
>>>>> features or bugfixes are added. I'd like to see that follow semantic
>>>>> versioning properly, too.
>>>>>
>>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com>
>>>>> wrote:
>>>>>
>>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should
>>>>>> be independent in both ways, right?
>>>>>>
>>>>>> I think I have coordination between log4j-scala and Scala language
>>>>>> covered already.
>>>>>>
>>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Mikael, you probably need to plan your versioning scheme to handle
>>>>>>> any combination of the following:
>>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>>>>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>>>>>>> once they are decoupled, the log4j-scala modules won't be released
>>>>>>> automatically with log4j anymore, someone needs to do the work for
>>>>>>> a log4j-scala release separately.
>>>>>>> * Scala releases: how do you want to sync up with Scala language
>>>>>>> versions? (I guess include major&minor Scala version in the log4j-scala
>>>>>>> module version)
>>>>>>> * log4j-scala module versions: enhancements to these modules,
>>>>>>> independent of the above
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I would like to keep package and artifact names, and bump version to
>>>>>>> 11.0.
>>>>>>>
>>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>>> If you change artifact ids, it's generally a good idea to change
>>>>>>>> packages, too. I've had issues in the past with Feign for instance because
>>>>>>>> they changed groupId/artifactId at one point but kept the same API, so I
>>>>>>>> had two copies on the classpath until I found out there was a duplicate and
>>>>>>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>>>
>>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> You can do that, but that will probably confuse users too. I would
>>>>>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <
>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>
>>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>>>
>>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.goers@dslextreme.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I guarantee if you try to keep the same versioning you will
>>>>>>>>>> regret it.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <
>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I was under the impression that we were not ready to integrate
>>>>>>>>>> the site from log4j-scala. That's why I considered the release of
>>>>>>>>>> log4j-scala as delayed, since there is no point of releasing it if we
>>>>>>>>>> cannot get the site integrated.
>>>>>>>>>>
>>>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess
>>>>>>>>>> we can go ahead and release log4j-scala.
>>>>>>>>>>
>>>>>>>>>> I don't like the idea of having separate versioning for
>>>>>>>>>> log4j-scala, that will be confusing since we have already started with the
>>>>>>>>>> same versioning as Log4j. Log4j-scala also have a dependency on log4j-api,
>>>>>>>>>> and I think we want to keep that in sync.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires
>>>>>>>>>>> Java 8, but we don't want to require that for the entire build, so we
>>>>>>>>>>> separated the repo. This also helps avoid making the main log4j repo from
>>>>>>>>>>> taking forever to build and release which can help the RERO idea. Plus,
>>>>>>>>>>> these non-core modules don't change nearly as often as log4j-core or
>>>>>>>>>>> log4j-api, so they don't really need new releases all that often.
>>>>>>>>>>>
>>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <remko.popma@gmail.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>>>
>>>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>>>> * what different websites we are planning to create to give
>>>>>>>>>>>> users access to these different modules
>>>>>>>>>>>> * what websites are going to be driven from which modules or
>>>>>>>>>>>> projects
>>>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>>>
>>>>>>>>>>>> My lack of understanding is not just limited to the Scala
>>>>>>>>>>>> modules but is about the whole splitting up the release.
>>>>>>>>>>>>
>>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>>>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>>>>>>>> would be very useful.)
>>>>>>>>>>>>
>>>>>>>>>>>> Remko
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j
>>>>>>>>>>>>> Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you use that excuse they will never get released as it
>>>>>>>>>>>>> creates a catch-22. If I release without them then we have a regression
>>>>>>>>>>>>> until they are released.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the
>>>>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or
>>>>>>>>>>>>> whatever.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once you create the release and deploy it to the web site I
>>>>>>>>>>>>> can modify the web site to point to it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of
>>>>>>>>>>>>> makes it harder to release from the log4j-scala repo when two of the three
>>>>>>>>>>>>> artifacts will already exist.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the
>>>>>>>>>>>>> next release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo
>>>>>>>>>>>>> since I thought that it would be released as part of 2.8, otherwise I would
>>>>>>>>>>>>> have put it to the main repo as well. But now releasing of the log4j-scala
>>>>>>>>>>>>> repo has been delayed and I start to get disappointed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boards@gmail.com
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Relative symlinks would work for that regardless of version.
>>>>>>>>>>>>> Option 1 it is, then?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink
>>>>>>>>>>>>> so that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the
>>>>>>>>>>>>> release manager for log4j-scala. In order for me to implement option 2 I
>>>>>>>>>>>>> would have to include the log4j-scala site into the log4j release process -
>>>>>>>>>>>>> as well as log4j-examples, etc if they move out. That is just not doable.
>>>>>>>>>>>>> Deploying the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>>>>>>> independently of log4j.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant;
>>>>>>>>>>>>> that's a pretty ugly URL honestly)
>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>>
>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but
>>>>>>>>>>>>> you'd have to manage it alongside log4j core releases. Option 1 still
>>>>>>>>>>>>> requires maintenance, too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is a specific location in svn where the site pages have
>>>>>>>>>>>>> to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to
>>>>>>>>>>>>> what I started doing with Log4j Boot. Add redirect pages or rewrite rules
>>>>>>>>>>>>> via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the
>>>>>>>>>>>>> main site. Depending on how you update the files in svn for a site update,
>>>>>>>>>>>>> could this be more annoying to maintain?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would
>>>>>>>>>>>>> really need a Scala site before we can modify the Log4j site, otherwise it
>>>>>>>>>>>>> will be a dead link.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that
>>>>>>>>>>>>> need fixes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>>>>>>> mostly cosmetic.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <
>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving
>>>>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I really
>>>>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue I see that
>>>>>>>>>>>>> fixing now is the null classloader issue for which we have a patch but it
>>>>>>>>>>>>> does not work for me (see JIRA).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some
>>>>>>>>>>>>> bugfixes and such ready to go. I also want to move forward with 2.9 changes
>>>>>>>>>>>>> but don't really want to deal with creating a 2.9 branch or forking master
>>>>>>>>>>>>> into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo
>>>>>>>>>>>>> (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond,
>>>>>>>>>>>>> but that's for another day. I think getting everything working properly in
>>>>>>>>>>>>> Java 9 would be a good thing to start doing soon so we can figure out if
>>>>>>>>>>>>> our APIs will still work properly in the future or if we need to break
>>>>>>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
If you don't have time to do it, Mikael, I could probably take care of it.
I'm planning on doing some Commons releases starting this week anyways, and
the process is fairly similar.
On 8 March 2017 at 06:41, Apache <ra...@dslextreme.com> wrote:
> Yes, go for it. You can look at the Log4J release guide although some
> steps won't apply.
>
> Ralph
>
> On Mar 8, 2017, at 5:32 AM, Remko Popma <re...@gmail.com> wrote:
>
> I won't be able to do it. :-) Why don't you give it a shot? I suspect you
> will be driving future changes often so it would be good if you can release
> such changes without having to wait for others to make time.
>
> Remko
>
> Sent from my iPhone
>
> On Mar 8, 2017, at 18:45, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> OK, I have updated the log4j-scala repo to bump version to 11.0, and note
> in README about independent versioning. It should now be ready for release.
> Who will do the release?
>
> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Yes. Scala should be released asap and the site manually modified to
>> point to it. We would then modify the log4j source to permanently point
>> there.
>>
>> Ralph
>>
>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Ralph pointed out that we can't make a release of the main repo without
>> the scala modules until there is a release of the scala modules on their
>> own. Otherwise, there'd be a regression in the main repo by removing
>> modules that were there before.
>>
>> On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
>>
>>> No objection from me to release log4j-scala.
>>>
>>> Do you have a versioning scheme that lets log4j-scala and log4j upgrade
>>> independently?
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>> Can we release log4j-scala now? Or to we have to wait for the next
>>> release of main repo with Scala modules removed? Should we remove the Scala
>>> modules from main repo now?
>>>
>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> The Scala language versions is already done the same standard way
>>>> everyone implements Scala libraries (hence the strange naming scheme we
>>>> already have). I'd imagine that the versions can be completely decoupled by
>>>> specifying a minimum Log4j API version it requires (though should generally
>>>> be whatever the latest was at release) and bumping its own version as new
>>>> features or bugfixes are added. I'd like to see that follow semantic
>>>> versioning properly, too.
>>>>
>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com>
>>>> wrote:
>>>>
>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be
>>>>> independent in both ways, right?
>>>>>
>>>>> I think I have coordination between log4j-scala and Scala language
>>>>> covered already.
>>>>>
>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Mikael, you probably need to plan your versioning scheme to handle
>>>>>> any combination of the following:
>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>>>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>>>>>> once they are decoupled, the log4j-scala modules won't be released
>>>>>> automatically with log4j anymore, someone needs to do the work for
>>>>>> a log4j-scala release separately.
>>>>>> * Scala releases: how do you want to sync up with Scala language
>>>>>> versions? (I guess include major&minor Scala version in the log4j-scala
>>>>>> module version)
>>>>>> * log4j-scala module versions: enhancements to these modules,
>>>>>> independent of the above
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>>>>>> wrote:
>>>>>>
>>>>>> I would like to keep package and artifact names, and bump version to
>>>>>> 11.0.
>>>>>>
>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>>
>>>>>>> If you change artifact ids, it's generally a good idea to change
>>>>>>> packages, too. I've had issues in the past with Feign for instance because
>>>>>>> they changed groupId/artifactId at one point but kept the same API, so I
>>>>>>> had two copies on the classpath until I found out there was a duplicate and
>>>>>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>>
>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> You can do that, but that will probably confuse users too. I would
>>>>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <
>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>
>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>>
>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I guarantee if you try to keep the same versioning you will regret
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <
>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>
>>>>>>>>> I was under the impression that we were not ready to integrate the
>>>>>>>>> site from log4j-scala. That's why I considered the release of log4j-scala
>>>>>>>>> as delayed, since there is no point of releasing it if we cannot get the
>>>>>>>>> site integrated.
>>>>>>>>>
>>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess
>>>>>>>>> we can go ahead and release log4j-scala.
>>>>>>>>>
>>>>>>>>> I don't like the idea of having separate versioning for
>>>>>>>>> log4j-scala, that will be confusing since we have already started with the
>>>>>>>>> same versioning as Log4j. Log4j-scala also have a dependency on log4j-api,
>>>>>>>>> and I think we want to keep that in sync.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires
>>>>>>>>>> Java 8, but we don't want to require that for the entire build, so we
>>>>>>>>>> separated the repo. This also helps avoid making the main log4j repo from
>>>>>>>>>> taking forever to build and release which can help the RERO idea. Plus,
>>>>>>>>>> these non-core modules don't change nearly as often as log4j-core or
>>>>>>>>>> log4j-api, so they don't really need new releases all that often.
>>>>>>>>>>
>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>>
>>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>>> * what different websites we are planning to create to give
>>>>>>>>>>> users access to these different modules
>>>>>>>>>>> * what websites are going to be driven from which modules or
>>>>>>>>>>> projects
>>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>>
>>>>>>>>>>> My lack of understanding is not just limited to the Scala
>>>>>>>>>>> modules but is about the whole splitting up the release.
>>>>>>>>>>>
>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>>>>>>> would be very useful.)
>>>>>>>>>>>
>>>>>>>>>>> Remko
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j
>>>>>>>>>>>> Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>>
>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> If you use that excuse they will never get released as it
>>>>>>>>>>>> creates a catch-22. If I release without them then we have a regression
>>>>>>>>>>>> until they are released.
>>>>>>>>>>>>
>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the
>>>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or
>>>>>>>>>>>> whatever.
>>>>>>>>>>>>
>>>>>>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>>>>>>> modify the web site to point to it.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of
>>>>>>>>>>>> makes it harder to release from the log4j-scala repo when two of the three
>>>>>>>>>>>> artifacts will already exist.
>>>>>>>>>>>>
>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>>>>>>> release.
>>>>>>>>>>>>
>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo
>>>>>>>>>>>> since I thought that it would be released as part of 2.8, otherwise I would
>>>>>>>>>>>> have put it to the main repo as well. But now releasing of the log4j-scala
>>>>>>>>>>>> repo has been delayed and I start to get disappointed.
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Relative symlinks would work for that regardless of version.
>>>>>>>>>>>> Option 1 it is, then?
>>>>>>>>>>>>
>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink so
>>>>>>>>>>>> that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the
>>>>>>>>>>>> release manager for log4j-scala. In order for me to implement option 2 I
>>>>>>>>>>>> would have to include the log4j-scala site into the log4j release process -
>>>>>>>>>>>> as well as log4j-examples, etc if they move out. That is just not doable.
>>>>>>>>>>>> Deploying the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>>>>>> independently of log4j.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>
>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>> ...
>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>
>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's
>>>>>>>>>>>> a pretty ugly URL honestly)
>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>
>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd
>>>>>>>>>>>> have to manage it alongside log4j core releases. Option 1 still requires
>>>>>>>>>>>> maintenance, too.
>>>>>>>>>>>>
>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> There is a specific location in svn where the site pages have
>>>>>>>>>>>> to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to
>>>>>>>>>>>> what I started doing with Log4j Boot. Add redirect pages or rewrite rules
>>>>>>>>>>>> via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the
>>>>>>>>>>>> main site. Depending on how you update the files in svn for a site update,
>>>>>>>>>>>> could this be more annoying to maintain?
>>>>>>>>>>>>
>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would
>>>>>>>>>>>> really need a Scala site before we can modify the Log4j site, otherwise it
>>>>>>>>>>>> will be a dead link.
>>>>>>>>>>>>
>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>
>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that
>>>>>>>>>>>> need fixes.
>>>>>>>>>>>>
>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>>>>>> mostly cosmetic.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <
>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving
>>>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I really
>>>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue I see that
>>>>>>>>>>>> fixing now is the null classloader issue for which we have a patch but it
>>>>>>>>>>>> does not work for me (see JIRA).
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm hoping we can get this released soon as we have some
>>>>>>>>>>>> bugfixes and such ready to go. I also want to move forward with 2.9 changes
>>>>>>>>>>>> but don't really want to deal with creating a 2.9 branch or forking master
>>>>>>>>>>>> into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>
>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo
>>>>>>>>>>>> (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>
>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond,
>>>>>>>>>>>> but that's for another day. I think getting everything working properly in
>>>>>>>>>>>> Java 9 would be a good thing to start doing soon so we can figure out if
>>>>>>>>>>>> our APIs will still work properly in the future or if we need to break
>>>>>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>>>>>
>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>>>>>
>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>
>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>
>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>> www.magine.com
>>>>>>>>>>>>
>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in
>>>>>>>>>>>> this message. If you are not the addressee indicated in this message
>>>>>>>>>>>> (or responsible for delivery of the message to such a person),
>>>>>>>>>>>> you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>>>>>> reply email.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> [image: MagineTV]
>>>>>>>>>
>>>>>>>>> *Mikael Ståldal*
>>>>>>>>> Senior software developer
>>>>>>>>>
>>>>>>>>> *Magine TV*
>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>
>>>>>>>>> Privileged and/or Confidential Information may be contained in
>>>>>>>>> this message. If you are not the addressee indicated in this message
>>>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>>> reply email.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> [image: MagineTV]
>>>>>>>>
>>>>>>>> *Mikael Ståldal*
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> *Magine TV*
>>>>>>>> mikael.staldal@magine.com
>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>
>>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>> reply email.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@magine.com
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this
>>>>> message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may
>>>>> not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply
>>>>> email.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
Yes, go for it. You can look at the Log4J release guide although some steps won't apply.
Ralph
> On Mar 8, 2017, at 5:32 AM, Remko Popma <re...@gmail.com> wrote:
>
> I won't be able to do it. :-) Why don't you give it a shot? I suspect you will be driving future changes often so it would be good if you can release such changes without having to wait for others to make time.
>
> Remko
>
> Sent from my iPhone
>
>> On Mar 8, 2017, at 18:45, Mikael Ståldal <mi...@magine.com> wrote:
>>
>> OK, I have updated the log4j-scala repo to bump version to 11.0, and note in README about independent versioning. It should now be ready for release. Who will do the release?
>>
>>> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Yes. Scala should be released asap and the site manually modified to point to it. We would then modify the log4j source to permanently point there.
>>>
>>> Ralph
>>>
>>>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> Ralph pointed out that we can't make a release of the main repo without the scala modules until there is a release of the scala modules on their own. Otherwise, there'd be a regression in the main repo by removing modules that were there before.
>>>>
>>>> On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
>>>>> No objection from me to release log4j-scala.
>>>>>
>>>>> Do you have a versioning scheme that lets log4j-scala and log4j upgrade independently?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>
>>>>>> Can we release log4j-scala now? Or to we have to wait for the next release of main repo with Scala modules removed? Should we remove the Scala modules from main repo now?
>>>>>>
>>>>>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>> The Scala language versions is already done the same standard way everyone implements Scala libraries (hence the strange naming scheme we already have). I'd imagine that the versions can be completely decoupled by specifying a minimum Log4j API version it requires (though should generally be whatever the latest was at release) and bumping its own version as new features or bugfixes are added. I'd like to see that follow semantic versioning properly, too.
>>>>>>>
>>>>>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be independent in both ways, right?
>>>>>>>>
>>>>>>>> I think I have coordination between log4j-scala and Scala language covered already.
>>>>>>>>
>>>>>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>> Mikael, you probably need to plan your versioning scheme to handle any combination of the following:
>>>>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once they are decoupled, the log4j-scala modules won't be released automatically with log4j anymore, someone needs to do the work for a log4j-scala release separately.
>>>>>>>>> * Scala releases: how do you want to sync up with Scala language versions? (I guess include major&minor Scala version in the log4j-scala module version)
>>>>>>>>> * log4j-scala module versions: enhancements to these modules, independent of the above
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I would like to keep package and artifact names, and bump version to 11.0.
>>>>>>>>>>
>>>>>>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>>>>>>> If you change artifact ids, it's generally a good idea to change packages, too. I've had issues in the past with Feign for instance because they changed groupId/artifactId at one point but kept the same API, so I had two copies on the classpath until I found out there was a duplicate and excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>>>>>>
>>>>>>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>> You can do that, but that will probably confuse users too. I would suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>>>>>>>>> * what different websites we are planning to create to give users access to these different modules
>>>>>>>>>>>>>>>>> * what websites are going to be driven from which modules or projects
>>>>>>>>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>>>>>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>>>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>>>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>
>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Mikael Ståldal
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> Magine TV
>>>>>>>> mikael.staldal@magine.com
>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>
>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Mikael Ståldal
>>>>>> Senior software developer
>>>>>>
>>>>>> Magine TV
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>
>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
Re: Roadmap for 2.8.1
Posted by Remko Popma <re...@gmail.com>.
I won't be able to do it. :-) Why don't you give it a shot? I suspect you will be driving future changes often so it would be good if you can release such changes without having to wait for others to make time.
Remko
Sent from my iPhone
> On Mar 8, 2017, at 18:45, Mikael Ståldal <mi...@magine.com> wrote:
>
> OK, I have updated the log4j-scala repo to bump version to 11.0, and note in README about independent versioning. It should now be ready for release. Who will do the release?
>
>> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> Yes. Scala should be released asap and the site manually modified to point to it. We would then modify the log4j source to permanently point there.
>>
>> Ralph
>>
>>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Ralph pointed out that we can't make a release of the main repo without the scala modules until there is a release of the scala modules on their own. Otherwise, there'd be a regression in the main repo by removing modules that were there before.
>>>
>>> On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
>>>> No objection from me to release log4j-scala.
>>>>
>>>> Do you have a versioning scheme that lets log4j-scala and log4j upgrade independently?
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>
>>>>> Can we release log4j-scala now? Or to we have to wait for the next release of main repo with Scala modules removed? Should we remove the Scala modules from main repo now?
>>>>>
>>>>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>> The Scala language versions is already done the same standard way everyone implements Scala libraries (hence the strange naming scheme we already have). I'd imagine that the versions can be completely decoupled by specifying a minimum Log4j API version it requires (though should generally be whatever the latest was at release) and bumping its own version as new features or bugfixes are added. I'd like to see that follow semantic versioning properly, too.
>>>>>>
>>>>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be independent in both ways, right?
>>>>>>>
>>>>>>> I think I have coordination between log4j-scala and Scala language covered already.
>>>>>>>
>>>>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>> Mikael, you probably need to plan your versioning scheme to handle any combination of the following:
>>>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once they are decoupled, the log4j-scala modules won't be released automatically with log4j anymore, someone needs to do the work for a log4j-scala release separately.
>>>>>>>> * Scala releases: how do you want to sync up with Scala language versions? (I guess include major&minor Scala version in the log4j-scala module version)
>>>>>>>> * log4j-scala module versions: enhancements to these modules, independent of the above
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>
>>>>>>>>> I would like to keep package and artifact names, and bump version to 11.0.
>>>>>>>>>
>>>>>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>>>>>> If you change artifact ids, it's generally a good idea to change packages, too. I've had issues in the past with Feign for instance because they changed groupId/artifactId at one point but kept the same API, so I had two copies on the classpath until I found out there was a duplicate and excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>>>>>
>>>>>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>> You can do that, but that will probably confuse users too. I would suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>>>>>>>> * what different websites we are planning to create to give users access to these different modules
>>>>>>>>>>>>>>>> * what websites are going to be driven from which modules or projects
>>>>>>>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>>>>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>
>>>>>>>>>>>> Magine TV
>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>
>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Mikael Ståldal
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> Magine TV
>>>>>>> mikael.staldal@magine.com
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Mikael Ståldal
>>>>> Senior software developer
>>>>>
>>>>> Magine TV
>>>>> mikael.staldal@magine.com
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
OK, I have updated the log4j-scala repo to bump version to 11.0, and note
in README about independent versioning. It should now be ready for release.
Who will do the release?
On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> Yes. Scala should be released asap and the site manually modified to point
> to it. We would then modify the log4j source to permanently point there.
>
> Ralph
>
> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Ralph pointed out that we can't make a release of the main repo without
> the scala modules until there is a release of the scala modules on their
> own. Otherwise, there'd be a regression in the main repo by removing
> modules that were there before.
>
> On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
>
>> No objection from me to release log4j-scala.
>>
>> Do you have a versioning scheme that lets log4j-scala and log4j upgrade
>> independently?
>>
>> Sent from my iPhone
>>
>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> Can we release log4j-scala now? Or to we have to wait for the next
>> release of main repo with Scala modules removed? Should we remove the Scala
>> modules from main repo now?
>>
>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> The Scala language versions is already done the same standard way
>>> everyone implements Scala libraries (hence the strange naming scheme we
>>> already have). I'd imagine that the versions can be completely decoupled by
>>> specifying a minimum Log4j API version it requires (though should generally
>>> be whatever the latest was at release) and bumping its own version as new
>>> features or bugfixes are added. I'd like to see that follow semantic
>>> versioning properly, too.
>>>
>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be
>>>> independent in both ways, right?
>>>>
>>>> I think I have coordination between log4j-scala and Scala language
>>>> covered already.
>>>>
>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> Mikael, you probably need to plan your versioning scheme to handle any
>>>>> combination of the following:
>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>>>>> once they are decoupled, the log4j-scala modules won't be released
>>>>> automatically with log4j anymore, someone needs to do the work for
>>>>> a log4j-scala release separately.
>>>>> * Scala releases: how do you want to sync up with Scala language
>>>>> versions? (I guess include major&minor Scala version in the log4j-scala
>>>>> module version)
>>>>> * log4j-scala module versions: enhancements to these modules,
>>>>> independent of the above
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>>>>> wrote:
>>>>>
>>>>> I would like to keep package and artifact names, and bump version to
>>>>> 11.0.
>>>>>
>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>
>>>>>> If you change artifact ids, it's generally a good idea to change
>>>>>> packages, too. I've had issues in the past with Feign for instance because
>>>>>> they changed groupId/artifactId at one point but kept the same API, so I
>>>>>> had two copies on the classpath until I found out there was a duplicate and
>>>>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>
>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>>> You can do that, but that will probably confuse users too. I would
>>>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <
>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>
>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>
>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I guarantee if you try to keep the same versioning you will regret
>>>>>>>> it.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <
>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>
>>>>>>>> I was under the impression that we were not ready to integrate the
>>>>>>>> site from log4j-scala. That's why I considered the release of log4j-scala
>>>>>>>> as delayed, since there is no point of releasing it if we cannot get the
>>>>>>>> site integrated.
>>>>>>>>
>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess
>>>>>>>> we can go ahead and release log4j-scala.
>>>>>>>>
>>>>>>>> I don't like the idea of having separate versioning for
>>>>>>>> log4j-scala, that will be confusing since we have already started with the
>>>>>>>> same versioning as Log4j. Log4j-scala also have a dependency on log4j-api,
>>>>>>>> and I think we want to keep that in sync.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires
>>>>>>>>> Java 8, but we don't want to require that for the entire build, so we
>>>>>>>>> separated the repo. This also helps avoid making the main log4j repo from
>>>>>>>>> taking forever to build and release which can help the RERO idea. Plus,
>>>>>>>>> these non-core modules don't change nearly as often as log4j-core or
>>>>>>>>> log4j-api, so they don't really need new releases all that often.
>>>>>>>>>
>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>
>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>> * what different websites we are planning to create to give users
>>>>>>>>>> access to these different modules
>>>>>>>>>> * what websites are going to be driven from which modules or
>>>>>>>>>> projects
>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>
>>>>>>>>>> My lack of understanding is not just limited to the Scala modules
>>>>>>>>>> but is about the whole splitting up the release.
>>>>>>>>>>
>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>>>>>> would be very useful.)
>>>>>>>>>>
>>>>>>>>>> Remko
>>>>>>>>>>
>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j
>>>>>>>>>>> Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>
>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If you use that excuse they will never get released as it
>>>>>>>>>>> creates a catch-22. If I release without them then we have a regression
>>>>>>>>>>> until they are released.
>>>>>>>>>>>
>>>>>>>>>>> This is why you shouldn’t really be releasing them using the
>>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or
>>>>>>>>>>> whatever.
>>>>>>>>>>>
>>>>>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>>>>>> modify the web site to point to it.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of
>>>>>>>>>>> makes it harder to release from the log4j-scala repo when two of the three
>>>>>>>>>>> artifacts will already exist.
>>>>>>>>>>>
>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>>>>>> release.
>>>>>>>>>>>
>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since
>>>>>>>>>>> I thought that it would be released as part of 2.8, otherwise I would have
>>>>>>>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>>>>>>>> has been delayed and I start to get disappointed.
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Relative symlinks would work for that regardless of version.
>>>>>>>>>>> Option 1 it is, then?
>>>>>>>>>>>
>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <ralph.goers@dslextreme.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>> Note that the link in the log4j site can reference a symlink so
>>>>>>>>>>> that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the
>>>>>>>>>>> release manager for log4j-scala. In order for me to implement option 2 I
>>>>>>>>>>> would have to include the log4j-scala site into the log4j release process -
>>>>>>>>>>> as well as log4j-examples, etc if they move out. That is just not doable.
>>>>>>>>>>> Deploying the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>>>>> independently of log4j.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>
>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>> ...
>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>
>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's
>>>>>>>>>>> a pretty ugly URL honestly)
>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>
>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd
>>>>>>>>>>> have to manage it alongside log4j core releases. Option 1 still requires
>>>>>>>>>>> maintenance, too.
>>>>>>>>>>>
>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>> There is a specific location in svn where the site pages have to
>>>>>>>>>>> be committed, so I don’t really understand option 1.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>
>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what
>>>>>>>>>>> I started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>>>>>>> .htaccess if possible to keep links from breaking.
>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the
>>>>>>>>>>> main site. Depending on how you update the files in svn for a site update,
>>>>>>>>>>> could this be more annoying to maintain?
>>>>>>>>>>>
>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>> From my perspective that doesn’t matter. However, we would
>>>>>>>>>>> really need a Scala site before we can modify the Log4j site, otherwise it
>>>>>>>>>>> will be a dead link.
>>>>>>>>>>>
>>>>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>
>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>>>>>> fixes.
>>>>>>>>>>>
>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>>>>> mostly cosmetic.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <
>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving
>>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I really
>>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue I see that
>>>>>>>>>>> fixing now is the null classloader issue for which we have a patch but it
>>>>>>>>>>> does not work for me (see JIRA).
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'm hoping we can get this released soon as we have some
>>>>>>>>>>> bugfixes and such ready to go. I also want to move forward with 2.9 changes
>>>>>>>>>>> but don't really want to deal with creating a 2.9 branch or forking master
>>>>>>>>>>> into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>
>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo
>>>>>>>>>>> (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>
>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond,
>>>>>>>>>>> but that's for another day. I think getting everything working properly in
>>>>>>>>>>> Java 9 would be a good thing to start doing soon so we can figure out if
>>>>>>>>>>> our APIs will still work properly in the future or if we need to break
>>>>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>>>>
>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>>>>
>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>
>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>> Senior software developer
>>>>>>>>>>>
>>>>>>>>>>> *Magine TV*
>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>
>>>>>>>>>>> Privileged and/or Confidential Information may be contained in
>>>>>>>>>>> this message. If you are not the addressee indicated in this message
>>>>>>>>>>> (or responsible for delivery of the message to such a person),
>>>>>>>>>>> you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>>>>> reply email.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> [image: MagineTV]
>>>>>>>>
>>>>>>>> *Mikael Ståldal*
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> *Magine TV*
>>>>>>>> mikael.staldal@magine.com
>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>
>>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>> reply email.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.staldal@magine.com
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>> reply email.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Roadmap for 2.8.1
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes. Scala should be released asap and the site manually modified to point to it. We would then modify the log4j source to permanently point there.
Ralph
> On Mar 7, 2017, at 10:09 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Ralph pointed out that we can't make a release of the main repo without the scala modules until there is a release of the scala modules on their own. Otherwise, there'd be a regression in the main repo by removing modules that were there before.
>
> On 7 March 2017 at 10:54, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> No objection from me to release log4j-scala.
>
> Do you have a versioning scheme that lets log4j-scala and log4j upgrade independently?
>
> Sent from my iPhone
>
> On Mar 8, 2017, at 1:42, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>
>> Can we release log4j-scala now? Or to we have to wait for the next release of main repo with Scala modules removed? Should we remove the Scala modules from main repo now?
>>
>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>> The Scala language versions is already done the same standard way everyone implements Scala libraries (hence the strange naming scheme we already have). I'd imagine that the versions can be completely decoupled by specifying a minimum Log4j API version it requires (though should generally be whatever the latest was at release) and bumping its own version as new features or bugfixes are added. I'd like to see that follow semantic versioning properly, too.
>>
>> On 3 March 2017 at 06:15, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>> I guess the idea is that releases of Log4j 2 and log4j-scala should be independent in both ways, right?
>>
>> I think I have coordination between log4j-scala and Scala language covered already.
>>
>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>> Mikael, you probably need to plan your versioning scheme to handle any combination of the following:
>> * log4j 2 releases: do you want to do a release for the log4j-scala modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once they are decoupled, the log4j-scala modules won't be released automatically with log4j anymore, someone needs to do the work for a log4j-scala release separately.
>> * Scala releases: how do you want to sync up with Scala language versions? (I guess include major&minor Scala version in the log4j-scala module version)
>> * log4j-scala module versions: enhancements to these modules, independent of the above
>>
>>
>> Sent from my iPhone
>>
>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>
>>> I would like to keep package and artifact names, and bump version to 11.0.
>>>
>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boards@gmail.com <ma...@gmail.com>> wrote:
>>> If you change artifact ids, it's generally a good idea to change packages, too. I've had issues in the past with Feign for instance because they changed groupId/artifactId at one point but kept the same API, so I had two copies on the classpath until I found out there was a duplicate and excluded them (though admittedly not a problem in OSGi environments :P).
>>>
>>> On 1 March 2017 at 07:47, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> You can do that, but that will probably confuse users too. I would suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>
>>> Ralph
>>>
>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>>
>>>> OK, but then at least we have to start with a version > 2.8.
>>>>
>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>>
>>>>> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>>>>>
>>>>> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>>>>>
>>>>> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>>>>>
>>>>>
>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>>>>
>>>>> On 28 February 2017 at 01:44, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>>>> To be honest I still don't understand
>>>>>
>>>>> * the vision of what we ultimately want to achieve
>>>>> * how different repos fit into that vision
>>>>> * what different websites we are planning to create to give users access to these different modules
>>>>> * what websites are going to be driven from which modules or projects
>>>>> * who of us is going to be driving what aspect of the above
>>>>>
>>>>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>>>>
>>>>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>>>>
>>>>> Remko
>>>>>
>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>>
>>>>> On 27 February 2017 at 18:35, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>>>>
>>>>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>
>>>>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>>>>
>>>>>> On 27 February 2017 at 12:14, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>> Why is the release of log4j-scala delayed?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>>>>>
>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>>>>
>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>>>>
>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>>>>
>>>>>>> On 25 February 2017 at 00:22, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>>>
>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>
>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>> ...
>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>
>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>
>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>>>>
>>>>>>>>> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>
>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>>>>
>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>>>>
>>>>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>
>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>>>>
>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>
>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>
>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>>>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>>>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>>>>>>>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Mikael Ståldal
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> Magine TV
>>>>>>> mikael.staldal@magine.com <ma...@magine.com>
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Mikael Ståldal
>>>>> Senior software developer
>>>>>
>>>>> Magine TV
>>>>> mikael.staldal@magine.com <ma...@magine.com>
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Mikael Ståldal
>>>> Senior software developer
>>>>
>>>> Magine TV
>>>> mikael.staldal@magine.com <ma...@magine.com>
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>>>
>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply email.
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
Ralph pointed out that we can't make a release of the main repo without the
scala modules until there is a release of the scala modules on their own.
Otherwise, there'd be a regression in the main repo by removing modules
that were there before.
On 7 March 2017 at 10:54, Remko Popma <re...@gmail.com> wrote:
> No objection from me to release log4j-scala.
>
> Do you have a versioning scheme that lets log4j-scala and log4j upgrade
> independently?
>
> Sent from my iPhone
>
> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com> wrote:
>
> Can we release log4j-scala now? Or to we have to wait for the next release
> of main repo with Scala modules removed? Should we remove the Scala modules
> from main repo now?
>
> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> The Scala language versions is already done the same standard way
>> everyone implements Scala libraries (hence the strange naming scheme we
>> already have). I'd imagine that the versions can be completely decoupled by
>> specifying a minimum Log4j API version it requires (though should generally
>> be whatever the latest was at release) and bumping its own version as new
>> features or bugfixes are added. I'd like to see that follow semantic
>> versioning properly, too.
>>
>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be
>>> independent in both ways, right?
>>>
>>> I think I have coordination between log4j-scala and Scala language
>>> covered already.
>>>
>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> Mikael, you probably need to plan your versioning scheme to handle any
>>>> combination of the following:
>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>>>> once they are decoupled, the log4j-scala modules won't be released
>>>> automatically with log4j anymore, someone needs to do the work for
>>>> a log4j-scala release separately.
>>>> * Scala releases: how do you want to sync up with Scala language
>>>> versions? (I guess include major&minor Scala version in the log4j-scala
>>>> module version)
>>>> * log4j-scala module versions: enhancements to these modules,
>>>> independent of the above
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>>>> wrote:
>>>>
>>>> I would like to keep package and artifact names, and bump version to
>>>> 11.0.
>>>>
>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>
>>>>> If you change artifact ids, it's generally a good idea to change
>>>>> packages, too. I've had issues in the past with Feign for instance because
>>>>> they changed groupId/artifactId at one point but kept the same API, so I
>>>>> had two copies on the classpath until I found out there was a duplicate and
>>>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>
>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> You can do that, but that will probably confuse users too. I would
>>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com>
>>>>>> wrote:
>>>>>>
>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>
>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I guarantee if you try to keep the same versioning you will regret
>>>>>>> it.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <
>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>
>>>>>>> I was under the impression that we were not ready to integrate the
>>>>>>> site from log4j-scala. That's why I considered the release of log4j-scala
>>>>>>> as delayed, since there is no point of releasing it if we cannot get the
>>>>>>> site integrated.
>>>>>>>
>>>>>>> But now when Ralph says he's ready to integrate the site, I guess we
>>>>>>> can go ahead and release log4j-scala.
>>>>>>>
>>>>>>> I don't like the idea of having separate versioning for log4j-scala,
>>>>>>> that will be confusing since we have already started with the same
>>>>>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I
>>>>>>> think we want to keep that in sync.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One issue we came across in practice is that Scala 2.12 requires
>>>>>>>> Java 8, but we don't want to require that for the entire build, so we
>>>>>>>> separated the repo. This also helps avoid making the main log4j repo from
>>>>>>>> taking forever to build and release which can help the RERO idea. Plus,
>>>>>>>> these non-core modules don't change nearly as often as log4j-core or
>>>>>>>> log4j-api, so they don't really need new releases all that often.
>>>>>>>>
>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> To be honest I still don't understand
>>>>>>>>>
>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>> * how different repos fit into that vision
>>>>>>>>> * what different websites we are planning to create to give users
>>>>>>>>> access to these different modules
>>>>>>>>> * what websites are going to be driven from which modules or
>>>>>>>>> projects
>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>
>>>>>>>>> My lack of understanding is not just limited to the Scala modules
>>>>>>>>> but is about the whole splitting up the release.
>>>>>>>>>
>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>>>>> would be very useful.)
>>>>>>>>>
>>>>>>>>> Remko
>>>>>>>>>
>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j
>>>>>>>>>> Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>
>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>
>>>>>>>>>> If you use that excuse they will never get released as it creates
>>>>>>>>>> a catch-22. If I release without them then we have a regression until they
>>>>>>>>>> are released.
>>>>>>>>>>
>>>>>>>>>> This is why you shouldn’t really be releasing them using the
>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or
>>>>>>>>>> whatever.
>>>>>>>>>>
>>>>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>>>>> modify the web site to point to it.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes
>>>>>>>>>> it harder to release from the log4j-scala repo when two of the three
>>>>>>>>>> artifacts will already exist.
>>>>>>>>>>
>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since
>>>>>>>>>> I thought that it would be released as part of 2.8, otherwise I would have
>>>>>>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>>>>>>> has been delayed and I start to get disappointed.
>>>>>>>>>>
>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Relative symlinks would work for that regardless of version.
>>>>>>>>>> Option 1 it is, then?
>>>>>>>>>>
>>>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Note that the link in the log4j site can reference a symlink so
>>>>>>>>>> that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>>>>>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>>>>>>>> to include the log4j-scala site into the log4j release process - as well as
>>>>>>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>>>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>>>> independently of log4j.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>
>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>> ...
>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>
>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>>>>>>> pretty ugly URL honestly)
>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>
>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd
>>>>>>>>>> have to manage it alongside log4j core releases. Option 1 still requires
>>>>>>>>>> maintenance, too.
>>>>>>>>>>
>>>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> There is a specific location in svn where the site pages have to
>>>>>>>>>> be committed, so I don’t really understand option 1.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>
>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what
>>>>>>>>>> I started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>>>>>> .htaccess if possible to keep links from breaking.
>>>>>>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>>>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>>>>>>> this be more annoying to maintain?
>>>>>>>>>>
>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>>>>>> need a Scala site before we can modify the Log4j site, otherwise it will be
>>>>>>>>>> a dead link.
>>>>>>>>>>
>>>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>
>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>>>>> fixes.
>>>>>>>>>>
>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>>>> mostly cosmetic.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <
>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving
>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I really
>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue I see that
>>>>>>>>>> fixing now is the null classloader issue for which we have a patch but it
>>>>>>>>>> does not work for me (see JIRA).
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>>>>> don't really want to deal with creating a 2.9 branch or forking master into
>>>>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>
>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>>>>
>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>>>
>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>>>
>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>>> Spring Batch in Action
>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>
>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>> Senior software developer
>>>>>>>>>>
>>>>>>>>>> *Magine TV*
>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>
>>>>>>>>>> Privileged and/or Confidential Information may be contained in
>>>>>>>>>> this message. If you are not the addressee indicated in this message
>>>>>>>>>> (or responsible for delivery of the message to such a person),
>>>>>>>>>> you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>>>> reply email.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.staldal@magine.com
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>> reply email.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> [image: MagineTV]
>>>>>>
>>>>>> *Mikael Ståldal*
>>>>>> Senior software developer
>>>>>>
>>>>>> *Magine TV*
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>
>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>> message. If you are not the addressee indicated in this message
>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>> you should destroy this message and kindly notify the sender by reply
>>>>>> email.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Remko Popma <re...@gmail.com>.
No objection from me to release log4j-scala.
Do you have a versioning scheme that lets log4j-scala and log4j upgrade independently?
Sent from my iPhone
> On Mar 8, 2017, at 1:42, Mikael Ståldal <mi...@magine.com> wrote:
>
> Can we release log4j-scala now? Or to we have to wait for the next release of main repo with Scala modules removed? Should we remove the Scala modules from main repo now?
>
>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
>> The Scala language versions is already done the same standard way everyone implements Scala libraries (hence the strange naming scheme we already have). I'd imagine that the versions can be completely decoupled by specifying a minimum Log4j API version it requires (though should generally be whatever the latest was at release) and bumping its own version as new features or bugfixes are added. I'd like to see that follow semantic versioning properly, too.
>>
>>> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com> wrote:
>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be independent in both ways, right?
>>>
>>> I think I have coordination between log4j-scala and Scala language covered already.
>>>
>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com> wrote:
>>>> Mikael, you probably need to plan your versioning scheme to handle any combination of the following:
>>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once they are decoupled, the log4j-scala modules won't be released automatically with log4j anymore, someone needs to do the work for a log4j-scala release separately.
>>>> * Scala releases: how do you want to sync up with Scala language versions? (I guess include major&minor Scala version in the log4j-scala module version)
>>>> * log4j-scala module versions: enhancements to these modules, independent of the above
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>
>>>>> I would like to keep package and artifact names, and bump version to 11.0.
>>>>>
>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>>>> If you change artifact ids, it's generally a good idea to change packages, too. I've had issues in the past with Feign for instance because they changed groupId/artifactId at one point but kept the same API, so I had two copies on the classpath until I found out there was a duplicate and excluded them (though admittedly not a problem in OSGi environments :P).
>>>>>>
>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>> You can do that, but that will probably confuse users too. I would suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>
>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>>
>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>>>>>>>>>>
>>>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>>>>>>>>>>
>>>>>>>>>> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>>>>>>>>>>
>>>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>> To be honest I still don't understand
>>>>>>>>>>>>
>>>>>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>>>>>> * how different repos fit into that vision
>>>>>>>>>>>> * what different websites we are planning to create to give users access to these different modules
>>>>>>>>>>>> * what websites are going to be driven from which modules or projects
>>>>>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>>>>>
>>>>>>>>>>>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>>>>>>>>>>>
>>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>>>>>>>>>>>
>>>>>>>>>>>> Remko
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mikael Ståldal
>>>>>>>>>> Senior software developer
>>>>>>>>>>
>>>>>>>>>> Magine TV
>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>
>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Mikael Ståldal
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> Magine TV
>>>>>>>> mikael.staldal@magine.com
>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>
>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply email.
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
Can we release log4j-scala now? Or to we have to wait for the next release
of main repo with Scala modules removed? Should we remove the Scala modules
from main repo now?
On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <bo...@gmail.com> wrote:
> The Scala language versions is already done the same standard way everyone
> implements Scala libraries (hence the strange naming scheme we already
> have). I'd imagine that the versions can be completely decoupled by
> specifying a minimum Log4j API version it requires (though should generally
> be whatever the latest was at release) and bumping its own version as new
> features or bugfixes are added. I'd like to see that follow semantic
> versioning properly, too.
>
> On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> I guess the idea is that releases of Log4j 2 and log4j-scala should be
>> independent in both ways, right?
>>
>> I think I have coordination between log4j-scala and Scala language
>> covered already.
>>
>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> Mikael, you probably need to plan your versioning scheme to handle any
>>> combination of the following:
>>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>>> once they are decoupled, the log4j-scala modules won't be released
>>> automatically with log4j anymore, someone needs to do the work for
>>> a log4j-scala release separately.
>>> * Scala releases: how do you want to sync up with Scala language
>>> versions? (I guess include major&minor Scala version in the log4j-scala
>>> module version)
>>> * log4j-scala module versions: enhancements to these modules,
>>> independent of the above
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>> I would like to keep package and artifact names, and bump version to
>>> 11.0.
>>>
>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>>
>>>> If you change artifact ids, it's generally a good idea to change
>>>> packages, too. I've had issues in the past with Feign for instance because
>>>> they changed groupId/artifactId at one point but kept the same API, so I
>>>> had two copies on the classpath until I found out there was a duplicate and
>>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>>
>>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> You can do that, but that will probably confuse users too. I would
>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com>
>>>>> wrote:
>>>>>
>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>
>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com>
>>>>>> wrote:
>>>>>>
>>>>>> I was under the impression that we were not ready to integrate the
>>>>>> site from log4j-scala. That's why I considered the release of log4j-scala
>>>>>> as delayed, since there is no point of releasing it if we cannot get the
>>>>>> site integrated.
>>>>>>
>>>>>> But now when Ralph says he's ready to integrate the site, I guess we
>>>>>> can go ahead and release log4j-scala.
>>>>>>
>>>>>> I don't like the idea of having separate versioning for log4j-scala,
>>>>>> that will be confusing since we have already started with the same
>>>>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I
>>>>>> think we want to keep that in sync.
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> One issue we came across in practice is that Scala 2.12 requires
>>>>>>> Java 8, but we don't want to require that for the entire build, so we
>>>>>>> separated the repo. This also helps avoid making the main log4j repo from
>>>>>>> taking forever to build and release which can help the RERO idea. Plus,
>>>>>>> these non-core modules don't change nearly as often as log4j-core or
>>>>>>> log4j-api, so they don't really need new releases all that often.
>>>>>>>
>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> To be honest I still don't understand
>>>>>>>>
>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>> * how different repos fit into that vision
>>>>>>>> * what different websites we are planning to create to give users
>>>>>>>> access to these different modules
>>>>>>>> * what websites are going to be driven from which modules or
>>>>>>>> projects
>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>
>>>>>>>> My lack of understanding is not just limited to the Scala modules
>>>>>>>> but is about the whole splitting up the release.
>>>>>>>>
>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>>>> would be very useful.)
>>>>>>>>
>>>>>>>> Remko
>>>>>>>>
>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I'd be in favour of starting a new release train for the Log4j
>>>>>>>>> Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>
>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>
>>>>>>>>> If you use that excuse they will never get released as it creates
>>>>>>>>> a catch-22. If I release without them then we have a regression until they
>>>>>>>>> are released.
>>>>>>>>>
>>>>>>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>>>>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>>>
>>>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>>>> modify the web site to point to it.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes
>>>>>>>>> it harder to release from the log4j-scala repo when two of the three
>>>>>>>>> artifacts will already exist.
>>>>>>>>>
>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>
>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>
>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>>>>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>>>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>>>>>> has been delayed and I start to get disappointed.
>>>>>>>>>
>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Relative symlinks would work for that regardless of version.
>>>>>>>>> Option 1 it is, then?
>>>>>>>>>
>>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Note that the link in the log4j site can reference a symlink so
>>>>>>>>> that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>>>>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>>>>>>> to include the log4j-scala site into the log4j release process - as well as
>>>>>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>>> independently of log4j.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>
>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>> ...
>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>
>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>>>>>> pretty ugly URL honestly)
>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>
>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd
>>>>>>>>> have to manage it alongside log4j core releases. Option 1 still requires
>>>>>>>>> maintenance, too.
>>>>>>>>>
>>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> There is a specific location in svn where the site pages have to
>>>>>>>>> be committed, so I don’t really understand option 1.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>
>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>>>>> .htaccess if possible to keep links from breaking.
>>>>>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>>>>>> this be more annoying to maintain?
>>>>>>>>>
>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>>>>> need a Scala site before we can modify the Log4j site, otherwise it will be
>>>>>>>>> a dead link.
>>>>>>>>>
>>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>
>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>>>> fixes.
>>>>>>>>>
>>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>>> mostly cosmetic.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>>>>>> work for me (see JIRA).
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>>>> don't really want to deal with creating a 2.9 branch or forking master into
>>>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>
>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>>>
>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>>
>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>>
>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>> Spring Batch in Action
>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> [image: MagineTV]
>>>>>>>>>
>>>>>>>>> *Mikael Ståldal*
>>>>>>>>> Senior software developer
>>>>>>>>>
>>>>>>>>> *Magine TV*
>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>
>>>>>>>>> Privileged and/or Confidential Information may be contained in
>>>>>>>>> this message. If you are not the addressee indicated in this message
>>>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>>> reply email.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> [image: MagineTV]
>>>>>>
>>>>>> *Mikael Ståldal*
>>>>>> Senior software developer
>>>>>>
>>>>>> *Magine TV*
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>
>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>> message. If you are not the addressee indicated in this message
>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>> you should destroy this message and kindly notify the sender by reply
>>>>>> email.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@magine.com
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this
>>>>> message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may
>>>>> not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply
>>>>> email.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
The Scala language versions is already done the same standard way everyone
implements Scala libraries (hence the strange naming scheme we already
have). I'd imagine that the versions can be completely decoupled by
specifying a minimum Log4j API version it requires (though should generally
be whatever the latest was at release) and bumping its own version as new
features or bugfixes are added. I'd like to see that follow semantic
versioning properly, too.
On 3 March 2017 at 06:15, Mikael Ståldal <mi...@magine.com> wrote:
> I guess the idea is that releases of Log4j 2 and log4j-scala should be
> independent in both ways, right?
>
> I think I have coordination between log4j-scala and Scala language covered
> already.
>
> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com>
> wrote:
>
>> Mikael, you probably need to plan your versioning scheme to handle any
>> combination of the following:
>> * log4j 2 releases: do you want to do a release for the log4j-scala modules
>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
>> once they are decoupled, the log4j-scala modules won't be released
>> automatically with log4j anymore, someone needs to do the work for
>> a log4j-scala release separately.
>> * Scala releases: how do you want to sync up with Scala language
>> versions? (I guess include major&minor Scala version in the log4j-scala
>> module version)
>> * log4j-scala module versions: enhancements to these modules, independent
>> of the above
>>
>>
>> Sent from my iPhone
>>
>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> I would like to keep package and artifact names, and bump version to 11.0.
>>
>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>
>>> If you change artifact ids, it's generally a good idea to change
>>> packages, too. I've had issues in the past with Feign for instance because
>>> they changed groupId/artifactId at one point but kept the same API, so I
>>> had two copies on the classpath until I found out there was a duplicate and
>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>>
>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> You can do that, but that will probably confuse users too. I would
>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com>
>>>> wrote:
>>>>
>>>> OK, but then at least we have to start with a version > 2.8.
>>>>
>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com>
>>>>> wrote:
>>>>>
>>>>> I was under the impression that we were not ready to integrate the
>>>>> site from log4j-scala. That's why I considered the release of log4j-scala
>>>>> as delayed, since there is no point of releasing it if we cannot get the
>>>>> site integrated.
>>>>>
>>>>> But now when Ralph says he's ready to integrate the site, I guess we
>>>>> can go ahead and release log4j-scala.
>>>>>
>>>>> I don't like the idea of having separate versioning for log4j-scala,
>>>>> that will be confusing since we have already started with the same
>>>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I
>>>>> think we want to keep that in sync.
>>>>>
>>>>>
>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>>> One issue we came across in practice is that Scala 2.12 requires Java
>>>>>> 8, but we don't want to require that for the entire build, so we separated
>>>>>> the repo. This also helps avoid making the main log4j repo from taking
>>>>>> forever to build and release which can help the RERO idea. Plus, these
>>>>>> non-core modules don't change nearly as often as log4j-core or log4j-api,
>>>>>> so they don't really need new releases all that often.
>>>>>>
>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> To be honest I still don't understand
>>>>>>>
>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>> * how different repos fit into that vision
>>>>>>> * what different websites we are planning to create to give users
>>>>>>> access to these different modules
>>>>>>> * what websites are going to be driven from which modules or
>>>>>>> projects
>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>
>>>>>>> My lack of understanding is not just limited to the Scala modules
>>>>>>> but is about the whole splitting up the release.
>>>>>>>
>>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>>> would be very useful.)
>>>>>>>
>>>>>>> Remko
>>>>>>>
>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I'd be in favour of starting a new release train for the Log4j
>>>>>>>> Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>
>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>
>>>>>>>> If you use that excuse they will never get released as it creates a
>>>>>>>> catch-22. If I release without them then we have a regression until they
>>>>>>>> are released.
>>>>>>>>
>>>>>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>>>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>>
>>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>>> modify the web site to point to it.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes
>>>>>>>> it harder to release from the log4j-scala repo when two of the three
>>>>>>>> artifacts will already exist.
>>>>>>>>
>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>
>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>
>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>>> release.
>>>>>>>>
>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>>>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>>>>> has been delayed and I start to get disappointed.
>>>>>>>>
>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Relative symlinks would work for that regardless of version. Option
>>>>>>>> 1 it is, then?
>>>>>>>>
>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Note that the link in the log4j site can reference a symlink so
>>>>>>>> that the log4j site never has to change when the Scala site is updated.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>>>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>>>>>> to include the log4j-scala site into the log4j release process - as well as
>>>>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>>>>> independently of log4j.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> The site repository is laid out like this:
>>>>>>>>
>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>> ...
>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>
>>>>>>>> Option 1 is to put it here instead:
>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>>>>> pretty ugly URL honestly)
>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>
>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd
>>>>>>>> have to manage it alongside log4j core releases. Option 1 still requires
>>>>>>>> maintenance, too.
>>>>>>>>
>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> There is a specific location in svn where the site pages have to be
>>>>>>>> committed, so I don’t really understand option 1.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I see two ways of doing that, though:
>>>>>>>>
>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>>>> .htaccess if possible to keep links from breaking.
>>>>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>>>>> this be more annoying to maintain?
>>>>>>>>
>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>>>> need a Scala site before we can modify the Log4j site, otherwise it will be
>>>>>>>> a dead link.
>>>>>>>>
>>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>
>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>>> fixes.
>>>>>>>>
>>>>>>>> The modules stuff doesn’t require a major version bump. It is
>>>>>>>> mostly cosmetic.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>>>>> work for me (see JIRA).
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>>> don't really want to deal with creating a 2.9 branch or forking master into
>>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>
>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>>
>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>>
>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>> JUnit in Action, Second Edition
>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>>
>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>> Spring Batch in Action
>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> [image: MagineTV]
>>>>>>>>
>>>>>>>> *Mikael Ståldal*
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> *Magine TV*
>>>>>>>> mikael.staldal@magine.com
>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>
>>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>>> reply email.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@magine.com
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this
>>>>> message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may
>>>>> not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply
>>>>> email.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
I guess the idea is that releases of Log4j 2 and log4j-scala should be
independent in both ways, right?
I think I have coordination between log4j-scala and Scala language covered
already.
On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <re...@gmail.com> wrote:
> Mikael, you probably need to plan your versioning scheme to handle any
> combination of the following:
> * log4j 2 releases: do you want to do a release for the log4j-scala modules
> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
> once they are decoupled, the log4j-scala modules won't be released
> automatically with log4j anymore, someone needs to do the work for
> a log4j-scala release separately.
> * Scala releases: how do you want to sync up with Scala language versions?
> (I guess include major&minor Scala version in the log4j-scala module
> version)
> * log4j-scala module versions: enhancements to these modules, independent
> of the above
>
>
> Sent from my iPhone
>
> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com> wrote:
>
> I would like to keep package and artifact names, and bump version to 11.0.
>
> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>
>> If you change artifact ids, it's generally a good idea to change
>> packages, too. I've had issues in the past with Feign for instance because
>> they changed groupId/artifactId at one point but kept the same API, so I
>> had two copies on the classpath until I found out there was a duplicate and
>> excluded them (though admittedly not a problem in OSGi environments :P).
>>
>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>> You can do that, but that will probably confuse users too. I would
>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>
>>> Ralph
>>>
>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>> OK, but then at least we have to start with a version > 2.8.
>>>
>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com>
>>>> wrote:
>>>>
>>>> I was under the impression that we were not ready to integrate the site
>>>> from log4j-scala. That's why I considered the release of log4j-scala as
>>>> delayed, since there is no point of releasing it if we cannot get the site
>>>> integrated.
>>>>
>>>> But now when Ralph says he's ready to integrate the site, I guess we
>>>> can go ahead and release log4j-scala.
>>>>
>>>> I don't like the idea of having separate versioning for log4j-scala,
>>>> that will be confusing since we have already started with the same
>>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I
>>>> think we want to keep that in sync.
>>>>
>>>>
>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> One issue we came across in practice is that Scala 2.12 requires Java
>>>>> 8, but we don't want to require that for the entire build, so we separated
>>>>> the repo. This also helps avoid making the main log4j repo from taking
>>>>> forever to build and release which can help the RERO idea. Plus, these
>>>>> non-core modules don't change nearly as often as log4j-core or log4j-api,
>>>>> so they don't really need new releases all that often.
>>>>>
>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> To be honest I still don't understand
>>>>>>
>>>>>> * the vision of what we ultimately want to achieve
>>>>>> * how different repos fit into that vision
>>>>>> * what different websites we are planning to create to give users
>>>>>> access to these different modules
>>>>>> * what websites are going to be driven from which modules or projects
>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>
>>>>>> My lack of understanding is not just limited to the Scala modules but
>>>>>> is about the whole splitting up the release.
>>>>>>
>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>>> would be very useful.)
>>>>>>
>>>>>> Remko
>>>>>>
>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>>> I'd be in favour of starting a new release train for the Log4j Scala
>>>>>>> APIs. Not exactly sure which version to start from, though.
>>>>>>>
>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>
>>>>>>> If you use that excuse they will never get released as it creates a
>>>>>>> catch-22. If I release without them then we have a regression until they
>>>>>>> are released.
>>>>>>>
>>>>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>
>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>> modify the web site to point to it.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>>>>>>> harder to release from the log4j-scala repo when two of the three artifacts
>>>>>>> will already exist.
>>>>>>>
>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>
>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>
>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>> release.
>>>>>>>
>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>>>> has been delayed and I start to get disappointed.
>>>>>>>
>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Relative symlinks would work for that regardless of version. Option
>>>>>>> 1 it is, then?
>>>>>>>
>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Note that the link in the log4j site can reference a symlink so that
>>>>>>> the log4j site never has to change when the Scala site is updated.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>>>>> to include the log4j-scala site into the log4j release process - as well as
>>>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>>>> independently of log4j.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> The site repository is laid out like this:
>>>>>>>
>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>> ...
>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>
>>>>>>> Option 1 is to put it here instead:
>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>>>> pretty ugly URL honestly)
>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>
>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have
>>>>>>> to manage it alongside log4j core releases. Option 1 still requires
>>>>>>> maintenance, too.
>>>>>>>
>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> There is a specific location in svn where the site pages have to be
>>>>>>> committed, so I don’t really understand option 1.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> I see two ways of doing that, though:
>>>>>>>
>>>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>>> .htaccess if possible to keep links from breaking.
>>>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>>>> this be more annoying to maintain?
>>>>>>>
>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>>> need a Scala site before we can modify the Log4j site, otherwise it will be
>>>>>>> a dead link.
>>>>>>>
>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a
>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>
>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>> fixes.
>>>>>>>
>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>>>> cosmetic.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>>>> work for me (see JIRA).
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>> don't really want to deal with creating a 2.9 branch or forking master into
>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>
>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>
>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>> unorthodox abuse of the feature.
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>> JUnit in Action, Second Edition
>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>> Spring Batch in Action
>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.staldal@magine.com
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>> reply email.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Roadmap for 2.8.1
Posted by Remko Popma <re...@gmail.com>.
Mikael, you probably need to plan your versioning scheme to handle any combination of the following:
* log4j 2 releases: do you want to do a release for the log4j-scala modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once they are decoupled, the log4j-scala modules won't be released automatically with log4j anymore, someone needs to do the work for a log4j-scala release separately.
* Scala releases: how do you want to sync up with Scala language versions? (I guess include major&minor Scala version in the log4j-scala module version)
* log4j-scala module versions: enhancements to these modules, independent of the above
Sent from my iPhone
> On Mar 3, 2017, at 9:10, Mikael Ståldal <mi...@magine.com> wrote:
>
> I would like to keep package and artifact names, and bump version to 11.0.
>
>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
>>> If you change artifact ids, it's generally a good idea to change packages, too. I've had issues in the past with Feign for instance because they changed groupId/artifactId at one point but kept the same API, so I had two copies on the classpath until I found out there was a duplicate and excluded them (though admittedly not a problem in OSGi environments :P).
>>>
>>> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
>>> You can do that, but that will probably confuse users too. I would suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>
>>> Ralph
>>>
>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>
>>>> OK, but then at least we have to start with a version > 2.8.
>>>>
>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com> wrote:
>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>
>>>>>> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>>>>>>
>>>>>> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>>>>>>
>>>>>> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>>>>>>
>>>>>>
>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>>>>>>>
>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>>>>>>> To be honest I still don't understand
>>>>>>>>
>>>>>>>> * the vision of what we ultimately want to achieve
>>>>>>>> * how different repos fit into that vision
>>>>>>>> * what different websites we are planning to create to give users access to these different modules
>>>>>>>> * what websites are going to be driven from which modules or projects
>>>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>>>
>>>>>>>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>>>>>>>
>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>>>>>>>
>>>>>>>> Remko
>>>>>>>>
>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>>>>>>
>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>>>>>>>>
>>>>>>>>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>>>>
>>>>>>>>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>>>>>>>>
>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>>>>>>>>
>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>>>>>>>>
>>>>>>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The site repository is laid out like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Option 1 is to put it here instead:
>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>>>>>>
>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>> Senior software developer
>>>>>>>>>>>
>>>>>>>>>>> Magine TV
>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>>
>>>>>>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Mikael Ståldal
>>>>>> Senior software developer
>>>>>>
>>>>>> Magine TV
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>
>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Mikael Ståldal
>>>> Senior software developer
>>>>
>>>> Magine TV
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply email.
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
I would like to keep package and artifact names, and bump version to 11.0.
On Mar 1, 2017 4:04 PM, "Matt Sicker" <bo...@gmail.com> wrote:
> If you change artifact ids, it's generally a good idea to change packages,
> too. I've had issues in the past with Feign for instance because they
> changed groupId/artifactId at one point but kept the same API, so I had two
> copies on the classpath until I found out there was a duplicate and
> excluded them (though admittedly not a problem in OSGi environments :P).
>
> On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> You can do that, but that will probably confuse users too. I would
>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>
>> Ralph
>>
>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> OK, but then at least we have to start with a version > 2.8.
>>
>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com>
>> wrote:
>>
>>> I guarantee if you try to keep the same versioning you will regret it.
>>>
>>> Ralph
>>>
>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>> I was under the impression that we were not ready to integrate the site
>>> from log4j-scala. That's why I considered the release of log4j-scala as
>>> delayed, since there is no point of releasing it if we cannot get the site
>>> integrated.
>>>
>>> But now when Ralph says he's ready to integrate the site, I guess we can
>>> go ahead and release log4j-scala.
>>>
>>> I don't like the idea of having separate versioning for log4j-scala,
>>> that will be confusing since we have already started with the same
>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I
>>> think we want to keep that in sync.
>>>
>>>
>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> One issue we came across in practice is that Scala 2.12 requires Java
>>>> 8, but we don't want to require that for the entire build, so we separated
>>>> the repo. This also helps avoid making the main log4j repo from taking
>>>> forever to build and release which can help the RERO idea. Plus, these
>>>> non-core modules don't change nearly as often as log4j-core or log4j-api,
>>>> so they don't really need new releases all that often.
>>>>
>>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> To be honest I still don't understand
>>>>>
>>>>> * the vision of what we ultimately want to achieve
>>>>> * how different repos fit into that vision
>>>>> * what different websites we are planning to create to give users
>>>>> access to these different modules
>>>>> * what websites are going to be driven from which modules or projects
>>>>> * who of us is going to be driving what aspect of the above
>>>>>
>>>>> My lack of understanding is not just limited to the Scala modules but
>>>>> is about the whole splitting up the release.
>>>>>
>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>> there's already a JIRA or an epic for the above. Adding some diagrams there
>>>>> would be very useful.)
>>>>>
>>>>> Remko
>>>>>
>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>>> I'd be in favour of starting a new release train for the Log4j Scala
>>>>>> APIs. Not exactly sure which version to start from, though.
>>>>>>
>>>>>> On 27 February 2017 at 18:35, Ralph Goers <ralph.goers@dslextreme.com
>>>>>> > wrote:
>>>>>>
>>>>>> If you use that excuse they will never get released as it creates a
>>>>>> catch-22. If I release without them then we have a regression until they
>>>>>> are released.
>>>>>>
>>>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>>
>>>>>> Once you create the release and deploy it to the web site I can
>>>>>> modify the web site to point to it.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>>>>>> harder to release from the log4j-scala repo when two of the three artifacts
>>>>>> will already exist.
>>>>>>
>>>>>> On 27 February 2017 at 12:14, Ralph Goers <ralph.goers@dslextreme.com
>>>>>> > wrote:
>>>>>>
>>>>>> Why is the release of log4j-scala delayed?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>
>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>> release.
>>>>>>
>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>>> has been delayed and I start to get disappointed.
>>>>>>
>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Relative symlinks would work for that regardless of version. Option 1
>>>>>> it is, then?
>>>>>>
>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> Note that the link in the log4j site can reference a symlink so that
>>>>>> the log4j site never has to change when the Scala site is updated.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>>>> to include the log4j-scala site into the log4j release process - as well as
>>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>>> independently of log4j.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> The site repository is laid out like this:
>>>>>>
>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>> ...
>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>
>>>>>> Option 1 is to put it here instead:
>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>>> pretty ugly URL honestly)
>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>
>>>>>> Option 2 is to commit the scala site where it is now, but you'd have
>>>>>> to manage it alongside log4j core releases. Option 1 still requires
>>>>>> maintenance, too.
>>>>>>
>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> There is a specific location in svn where the site pages have to be
>>>>>> committed, so I don’t really understand option 1.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> I see two ways of doing that, though:
>>>>>>
>>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>> .htaccess if possible to keep links from breaking.
>>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>>> this be more annoying to maintain?
>>>>>>
>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>> need a Scala site before we can modify the Log4j site, otherwise it will be
>>>>>> a dead link.
>>>>>>
>>>>>> All that really needs to happen is the Scala site needs to be checked
>>>>>> in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to
>>>>>> the Scala site from the main menu. The two sites won’t really be
>>>>>> “integrated” - they will just have links to each other.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>
>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>> fixes.
>>>>>>
>>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>>> cosmetic.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>>> work for me (see JIRA).
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I'm hoping we can get this released soon as we have some bugfixes and
>>>>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>>>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>>>>> branch. Let's go over anything left to do for 2.8.1:
>>>>>>
>>>>>> * Integrated log4j-api-scala website into main site
>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>
>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>> APIs will still work properly in the future or if we need to break
>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>> unorthodox abuse of the feature.
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>
>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>> JUnit in Action, Second Edition
>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>
>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>> Spring Batch in Action
>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> [image: MagineTV]
>>>>>>
>>>>>> *Mikael Ståldal*
>>>>>> Senior software developer
>>>>>>
>>>>>> *Magine TV*
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>
>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>> message. If you are not the addressee indicated in this message
>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>> you should destroy this message and kindly notify the sender by reply
>>>>>> email.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
If you change artifact ids, it's generally a good idea to change packages,
too. I've had issues in the past with Feign for instance because they
changed groupId/artifactId at one point but kept the same API, so I had two
copies on the classpath until I found out there was a duplicate and
excluded them (though admittedly not a problem in OSGi environments :P).
On 1 March 2017 at 07:47, Ralph Goers <ra...@dslextreme.com> wrote:
> You can do that, but that will probably confuse users too. I would suggest
> changing the artifactId and then start at either 1.0 or 2.0.
>
> Ralph
>
> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> OK, but then at least we have to start with a version > 2.8.
>
> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com> wrote:
>
>> I guarantee if you try to keep the same versioning you will regret it.
>>
>> Ralph
>>
>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> I was under the impression that we were not ready to integrate the site
>> from log4j-scala. That's why I considered the release of log4j-scala as
>> delayed, since there is no point of releasing it if we cannot get the site
>> integrated.
>>
>> But now when Ralph says he's ready to integrate the site, I guess we can
>> go ahead and release log4j-scala.
>>
>> I don't like the idea of having separate versioning for log4j-scala, that
>> will be confusing since we have already started with the same versioning as
>> Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want
>> to keep that in sync.
>>
>>
>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> One issue we came across in practice is that Scala 2.12 requires Java 8,
>>> but we don't want to require that for the entire build, so we separated the
>>> repo. This also helps avoid making the main log4j repo from taking forever
>>> to build and release which can help the RERO idea. Plus, these non-core
>>> modules don't change nearly as often as log4j-core or log4j-api, so they
>>> don't really need new releases all that often.
>>>
>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>>
>>>> To be honest I still don't understand
>>>>
>>>> * the vision of what we ultimately want to achieve
>>>> * how different repos fit into that vision
>>>> * what different websites we are planning to create to give users
>>>> access to these different modules
>>>> * what websites are going to be driven from which modules or projects
>>>> * who of us is going to be driving what aspect of the above
>>>>
>>>> My lack of understanding is not just limited to the Scala modules but
>>>> is about the whole splitting up the release.
>>>>
>>>> Perhaps a diagram would help clarify my understanding. (I think there's
>>>> already a JIRA or an epic for the above. Adding some diagrams there would
>>>> be very useful.)
>>>>
>>>> Remko
>>>>
>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> I'd be in favour of starting a new release train for the Log4j Scala
>>>>> APIs. Not exactly sure which version to start from, though.
>>>>>
>>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> If you use that excuse they will never get released as it creates a
>>>>> catch-22. If I release without them then we have a regression until they
>>>>> are released.
>>>>>
>>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>>
>>>>> Once you create the release and deploy it to the web site I can modify
>>>>> the web site to point to it.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>>>>> harder to release from the log4j-scala repo when two of the three artifacts
>>>>> will already exist.
>>>>>
>>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> Why is the release of log4j-scala delayed?
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>> mikael.staldal@magine.com> wrote:
>>>>>
>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>> release.
>>>>>
>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>>> has been delayed and I start to get disappointed.
>>>>>
>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> Relative symlinks would work for that regardless of version. Option 1
>>>>> it is, then?
>>>>>
>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> Note that the link in the log4j site can reference a symlink so that
>>>>> the log4j site never has to change when the Scala site is updated.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>>> to include the log4j-scala site into the log4j release process - as well as
>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>> independently of log4j.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> The site repository is laid out like this:
>>>>>
>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>> log4j/log4j-2.8/log4j-api/
>>>>> ...
>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>
>>>>> Option 1 is to put it here instead:
>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>> pretty ugly URL honestly)
>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>
>>>>> Option 2 is to commit the scala site where it is now, but you'd have
>>>>> to manage it alongside log4j core releases. Option 1 still requires
>>>>> maintenance, too.
>>>>>
>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> There is a specific location in svn where the site pages have to be
>>>>> committed, so I don’t really understand option 1.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I see two ways of doing that, though:
>>>>>
>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>> .htaccess if possible to keep links from breaking.
>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>> this be more annoying to maintain?
>>>>>
>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> From my perspective that doesn’t matter. However, we would really need
>>>>> a Scala site before we can modify the Log4j site, otherwise it will be a
>>>>> dead link.
>>>>>
>>>>> All that really needs to happen is the Scala site needs to be checked
>>>>> in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to
>>>>> the Scala site from the main menu. The two sites won’t really be
>>>>> “integrated” - they will just have links to each other.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>
>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>
>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>> cosmetic.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>> work for me (see JIRA).
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I'm hoping we can get this released soon as we have some bugfixes and
>>>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>>>> branch. Let's go over anything left to do for 2.8.1:
>>>>>
>>>>> * Integrated log4j-api-scala website into main site
>>>>> * Remove scala modules from logging-log4j2 repo
>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>> shortly after releasing 2.8.1 of core?)
>>>>>
>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>> that's for another day. I think getting everything working properly in Java
>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>> APIs will still work properly in the future or if we need to break
>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>> unorthodox abuse of the feature.
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>
>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>> JUnit in Action, Second Edition
>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>
>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>> Spring Batch in Action
>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@magine.com
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this
>>>>> message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may
>>>>> not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply
>>>>> email.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Ralph Goers <ra...@dslextreme.com>.
You can do that, but that will probably confuse users too. I would suggest changing the artifactId and then start at either 1.0 or 2.0.
Ralph
> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mi...@magine.com> wrote:
>
> OK, but then at least we have to start with a version > 2.8.
>
> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I guarantee if you try to keep the same versioning you will regret it.
>
> Ralph
>
> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>
>> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>>
>> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>>
>> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>>
>>
>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>
>> On 28 February 2017 at 01:44, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>> To be honest I still don't understand
>>
>> * the vision of what we ultimately want to achieve
>> * how different repos fit into that vision
>> * what different websites we are planning to create to give users access to these different modules
>> * what websites are going to be driven from which modules or projects
>> * who of us is going to be driving what aspect of the above
>>
>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>
>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>
>> Remko
>>
>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>
>> On 27 February 2017 at 18:35, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>
>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>
>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>
>> Ralph
>>
>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>
>>> On 27 February 2017 at 12:14, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> Why is the release of log4j-scala delayed?
>>>
>>> Ralph
>>>
>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>>
>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>
>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>
>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>
>>>> On 25 February 2017 at 00:22, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>
>>>> Ralph
>>>>
>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>
>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> The site repository is laid out like this:
>>>>>>
>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>> ...
>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>
>>>>>> Option 1 is to put it here instead:
>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>
>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>
>>>>>> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>> I see two ways of doing that, though:
>>>>>>>
>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>
>>>>>>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>
>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>
>>>>>>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>
>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>
>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>
>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>>>>>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>>>>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>>>>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Mikael Ståldal
>>>> Senior software developer
>>>>
>>>> Magine TV
>>>> mikael.staldal@magine.com <ma...@magine.com>
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>>>
>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply email.
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com <ma...@magine.com>
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
OK, but then at least we have to start with a version > 2.8.
On Wed, Mar 1, 2017 at 1:33 PM, Apache <ra...@dslextreme.com> wrote:
> I guarantee if you try to keep the same versioning you will regret it.
>
> Ralph
>
> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> I was under the impression that we were not ready to integrate the site
> from log4j-scala. That's why I considered the release of log4j-scala as
> delayed, since there is no point of releasing it if we cannot get the site
> integrated.
>
> But now when Ralph says he's ready to integrate the site, I guess we can
> go ahead and release log4j-scala.
>
> I don't like the idea of having separate versioning for log4j-scala, that
> will be confusing since we have already started with the same versioning as
> Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want
> to keep that in sync.
>
>
> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> One issue we came across in practice is that Scala 2.12 requires Java 8,
>> but we don't want to require that for the entire build, so we separated the
>> repo. This also helps avoid making the main log4j repo from taking forever
>> to build and release which can help the RERO idea. Plus, these non-core
>> modules don't change nearly as often as log4j-core or log4j-api, so they
>> don't really need new releases all that often.
>>
>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>
>>> To be honest I still don't understand
>>>
>>> * the vision of what we ultimately want to achieve
>>> * how different repos fit into that vision
>>> * what different websites we are planning to create to give users access
>>> to these different modules
>>> * what websites are going to be driven from which modules or projects
>>> * who of us is going to be driving what aspect of the above
>>>
>>> My lack of understanding is not just limited to the Scala modules but is
>>> about the whole splitting up the release.
>>>
>>> Perhaps a diagram would help clarify my understanding. (I think there's
>>> already a JIRA or an epic for the above. Adding some diagrams there would
>>> be very useful.)
>>>
>>> Remko
>>>
>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> I'd be in favour of starting a new release train for the Log4j Scala
>>>> APIs. Not exactly sure which version to start from, though.
>>>>
>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> If you use that excuse they will never get released as it creates a
>>>> catch-22. If I release without them then we have a regression until they
>>>> are released.
>>>>
>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>
>>>> Once you create the release and deploy it to the web site I can modify
>>>> the web site to point to it.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>>>> harder to release from the log4j-scala repo when two of the three artifacts
>>>> will already exist.
>>>>
>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> Why is the release of log4j-scala delayed?
>>>>
>>>> Ralph
>>>>
>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com>
>>>> wrote:
>>>>
>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>
>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>>> has been delayed and I start to get disappointed.
>>>>
>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> Relative symlinks would work for that regardless of version. Option 1
>>>> it is, then?
>>>>
>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> Note that the link in the log4j site can reference a symlink so that
>>>> the log4j site never has to change when the Scala site is updated.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>> to include the log4j-scala site into the log4j release process - as well as
>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>> independently of log4j.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> The site repository is laid out like this:
>>>>
>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>> log4j/log4j-2.8/log4j-api/
>>>> ...
>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>
>>>> Option 1 is to put it here instead:
>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>> pretty ugly URL honestly)
>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>
>>>> Option 2 is to commit the scala site where it is now, but you'd have to
>>>> manage it alongside log4j core releases. Option 1 still requires
>>>> maintenance, too.
>>>>
>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> There is a specific location in svn where the site pages have to be
>>>> committed, so I don’t really understand option 1.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I see two ways of doing that, though:
>>>>
>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>> .htaccess if possible to keep links from breaking.
>>>> 2. Commit the Scala site where it would go when creating the main site.
>>>> Depending on how you update the files in svn for a site update, could this
>>>> be more annoying to maintain?
>>>>
>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> From my perspective that doesn’t matter. However, we would really need
>>>> a Scala site before we can modify the Log4j site, otherwise it will be a
>>>> dead link.
>>>>
>>>> All that really needs to happen is the Scala site needs to be checked
>>>> in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to
>>>> the Scala site from the main menu. The two sites won’t really be
>>>> “integrated” - they will just have links to each other.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>
>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>
>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>> cosmetic.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>> now is the null classloader issue for which we have a patch but it does not
>>>> work for me (see JIRA).
>>>>
>>>> Gary
>>>>
>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I'm hoping we can get this released soon as we have some bugfixes and
>>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>>> branch. Let's go over anything left to do for 2.8.1:
>>>>
>>>> * Integrated log4j-api-scala website into main site
>>>> * Remove scala modules from logging-log4j2 repo
>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>> shortly after releasing 2.8.1 of core?)
>>>>
>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>> that's for another day. I think getting everything working properly in Java
>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>> APIs will still work properly in the future or if we need to break
>>>> backwards compatibility. Although, multi-jar support could help in
>>>> migrating the API if needed for 9+, though that would be a rather
>>>> unorthodox abuse of the feature.
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>> JUnit in Action, Second Edition
>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>> Spring Batch in Action
>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
I guarantee if you try to keep the same versioning you will regret it.
Ralph
> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mi...@magine.com> wrote:
>
> I was under the impression that we were not ready to integrate the site from log4j-scala. That's why I considered the release of log4j-scala as delayed, since there is no point of releasing it if we cannot get the site integrated.
>
> But now when Ralph says he's ready to integrate the site, I guess we can go ahead and release log4j-scala.
>
> I don't like the idea of having separate versioning for log4j-scala, that will be confusing since we have already started with the same versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want to keep that in sync.
>
>
>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
>> One issue we came across in practice is that Scala 2.12 requires Java 8, but we don't want to require that for the entire build, so we separated the repo. This also helps avoid making the main log4j repo from taking forever to build and release which can help the RERO idea. Plus, these non-core modules don't change nearly as often as log4j-core or log4j-api, so they don't really need new releases all that often.
>>
>>> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>>> To be honest I still don't understand
>>>
>>> * the vision of what we ultimately want to achieve
>>> * how different repos fit into that vision
>>> * what different websites we are planning to create to give users access to these different modules
>>> * what websites are going to be driven from which modules or projects
>>> * who of us is going to be driving what aspect of the above
>>>
>>> My lack of understanding is not just limited to the Scala modules but is about the whole splitting up the release.
>>>
>>> Perhaps a diagram would help clarify my understanding. (I think there's already a JIRA or an epic for the above. Adding some diagrams there would be very useful.)
>>>
>>> Remko
>>>
>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. Not exactly sure which version to start from, though.
>>>>
>>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com> wrote:
>>>> If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
>>>>
>>>> This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>>
>>>> Once you create the release and deploy it to the web site I can modify the web site to point to it.
>>>>
>>>> Ralph
>>>>
>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>>>>>
>>>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> Why is the release of log4j-scala delayed?
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>
>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>>>>
>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>>>>>
>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>>>>>
>>>>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>>>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>>>>>
>>>>>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> The site repository is laid out like this:
>>>>>>>>
>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>>> ...
>>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>>
>>>>>>>> Option 1 is to put it here instead:
>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>>
>>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>>>>>
>>>>>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>>>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I see two ways of doing that, though:
>>>>>>>>>
>>>>>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>>>>>
>>>>>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>>>>>
>>>>>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>>>>
>>>>>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>>>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>>>>>
>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>>>>
>>>>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>>>>>
>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>> Spring Batch in Action
>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Mikael Ståldal
>>>>>> Senior software developer
>>>>>>
>>>>>> Magine TV
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>
>>>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>>>> you should destroy this message and kindly notify the sender by reply email.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
I was under the impression that we were not ready to integrate the site
from log4j-scala. That's why I considered the release of log4j-scala as
delayed, since there is no point of releasing it if we cannot get the site
integrated.
But now when Ralph says he's ready to integrate the site, I guess we can go
ahead and release log4j-scala.
I don't like the idea of having separate versioning for log4j-scala, that
will be confusing since we have already started with the same versioning as
Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want
to keep that in sync.
On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <bo...@gmail.com> wrote:
> One issue we came across in practice is that Scala 2.12 requires Java 8,
> but we don't want to require that for the entire build, so we separated the
> repo. This also helps avoid making the main log4j repo from taking forever
> to build and release which can help the RERO idea. Plus, these non-core
> modules don't change nearly as often as log4j-core or log4j-api, so they
> don't really need new releases all that often.
>
> On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
>
>> To be honest I still don't understand
>>
>> * the vision of what we ultimately want to achieve
>> * how different repos fit into that vision
>> * what different websites we are planning to create to give users access
>> to these different modules
>> * what websites are going to be driven from which modules or projects
>> * who of us is going to be driving what aspect of the above
>>
>> My lack of understanding is not just limited to the Scala modules but is
>> about the whole splitting up the release.
>>
>> Perhaps a diagram would help clarify my understanding. (I think there's
>> already a JIRA or an epic for the above. Adding some diagrams there would
>> be very useful.)
>>
>> Remko
>>
>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I'd be in favour of starting a new release train for the Log4j Scala
>>> APIs. Not exactly sure which version to start from, though.
>>>
>>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>> If you use that excuse they will never get released as it creates a
>>> catch-22. If I release without them then we have a regression until they
>>> are released.
>>>
>>> This is why you shouldn’t really be releasing them using the Log4j
>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>>
>>> Once you create the release and deploy it to the web site I can modify
>>> the web site to point to it.
>>>
>>> Ralph
>>>
>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>>> harder to release from the log4j-scala repo when two of the three artifacts
>>> will already exist.
>>>
>>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>> Why is the release of log4j-scala delayed?
>>>
>>> Ralph
>>>
>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>>
>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>> thought that it would be released as part of 2.8, otherwise I would have
>>> put it to the main repo as well. But now releasing of the log4j-scala repo
>>> has been delayed and I start to get disappointed.
>>>
>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Relative symlinks would work for that regardless of version. Option 1 it
>>> is, then?
>>>
>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>
>>> Note that the link in the log4j site can reference a symlink so that the
>>> log4j site never has to change when the Scala site is updated.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>
>>> Option 2 makes no sense to me. I don’t plan on being the release
>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>> to include the log4j-scala site into the log4j release process - as well as
>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>> the Scala site parallel to log4j makes it much easier to maintain
>>> independently of log4j.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> The site repository is laid out like this:
>>>
>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>> log4j/log4j-2.8/log4j-api/
>>> ...
>>> log4j/2.x/log4j-api-scala_2.11/
>>>
>>> Option 1 is to put it here instead:
>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
>>> ugly URL honestly)
>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>
>>> Option 2 is to commit the scala site where it is now, but you'd have to
>>> manage it alongside log4j core releases. Option 1 still requires
>>> maintenance, too.
>>>
>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>
>>> There is a specific location in svn where the site pages have to be
>>> committed, so I don’t really understand option 1.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I see two ways of doing that, though:
>>>
>>> 1. Commit the Scala site in a separate directory similar to what I
>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>> .htaccess if possible to keep links from breaking.
>>> 2. Commit the Scala site where it would go when creating the main site.
>>> Depending on how you update the files in svn for a site update, could this
>>> be more annoying to maintain?
>>>
>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>
>>> From my perspective that doesn’t matter. However, we would really need a
>>> Scala site before we can modify the Log4j site, otherwise it will be a dead
>>> link.
>>>
>>> All that really needs to happen is the Scala site needs to be checked in
>>> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
>>> Scala site from the main menu. The two sites won’t really be “integrated” -
>>> they will just have links to each other.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>
>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>
>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>
>>> The modules stuff doesn’t require a major version bump. It is mostly
>>> cosmetic.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>> around feels like a 2.9 item to me but that's just me. I really like the
>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>> now is the null classloader issue for which we have a patch but it does not
>>> work for me (see JIRA).
>>>
>>> Gary
>>>
>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I'm hoping we can get this released soon as we have some bugfixes and
>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>> branch. Let's go over anything left to do for 2.8.1:
>>>
>>> * Integrated log4j-api-scala website into main site
>>> * Remove scala modules from logging-log4j2 repo
>>> * Release scala modules from logging-log4j-scala repo (presumably
>>> shortly after releasing 2.8.1 of core?)
>>>
>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's
>>> for another day. I think getting everything working properly in Java 9
>>> would be a good thing to start doing soon so we can figure out if our APIs
>>> will still work properly in the future or if we need to break backwards
>>> compatibility. Although, multi-jar support could help in migrating the API
>>> if needed for 9+, though that would be a rather unorthodox abuse of the
>>> feature.
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>> JUnit in Action, Second Edition
>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>> Spring Batch in Action
>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
One issue we came across in practice is that Scala 2.12 requires Java 8,
but we don't want to require that for the entire build, so we separated the
repo. This also helps avoid making the main log4j repo from taking forever
to build and release which can help the RERO idea. Plus, these non-core
modules don't change nearly as often as log4j-core or log4j-api, so they
don't really need new releases all that often.
On 28 February 2017 at 01:44, Remko Popma <re...@gmail.com> wrote:
> To be honest I still don't understand
>
> * the vision of what we ultimately want to achieve
> * how different repos fit into that vision
> * what different websites we are planning to create to give users access
> to these different modules
> * what websites are going to be driven from which modules or projects
> * who of us is going to be driving what aspect of the above
>
> My lack of understanding is not just limited to the Scala modules but is
> about the whole splitting up the release.
>
> Perhaps a diagram would help clarify my understanding. (I think there's
> already a JIRA or an epic for the above. Adding some diagrams there would
> be very useful.)
>
> Remko
>
> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
>
>> I'd be in favour of starting a new release train for the Log4j Scala
>> APIs. Not exactly sure which version to start from, though.
>>
>> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> If you use that excuse they will never get released as it creates a
>> catch-22. If I release without them then we have a regression until they
>> are released.
>>
>> This is why you shouldn’t really be releasing them using the Log4j
>> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>>
>> Once you create the release and deploy it to the web site I can modify
>> the web site to point to it.
>>
>> Ralph
>>
>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>> harder to release from the log4j-scala repo when two of the three artifacts
>> will already exist.
>>
>> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> Why is the release of log4j-scala delayed?
>>
>> Ralph
>>
>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>
>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>> thought that it would be released as part of 2.8, otherwise I would have
>> put it to the main repo as well. But now releasing of the log4j-scala repo
>> has been delayed and I start to get disappointed.
>>
>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Relative symlinks would work for that regardless of version. Option 1 it
>> is, then?
>>
>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>
>> Note that the link in the log4j site can reference a symlink so that the
>> log4j site never has to change when the Scala site is updated.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>
>> Option 2 makes no sense to me. I don’t plan on being the release manager
>> for log4j-scala. In order for me to implement option 2 I would have to
>> include the log4j-scala site into the log4j release process - as well as
>> log4j-examples, etc if they move out. That is just not doable. Deploying
>> the Scala site parallel to log4j makes it much easier to maintain
>> independently of log4j.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> The site repository is laid out like this:
>>
>> log4j/2.x/ -(symlink)-> log4j-2.8/
>> log4j/log4j-2.8/log4j-api/
>> ...
>> log4j/2.x/log4j-api-scala_2.11/
>>
>> Option 1 is to put it here instead:
>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
>> ugly URL honestly)
>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>
>> Option 2 is to commit the scala site where it is now, but you'd have to
>> manage it alongside log4j core releases. Option 1 still requires
>> maintenance, too.
>>
>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>
>> There is a specific location in svn where the site pages have to be
>> committed, so I don’t really understand option 1.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I see two ways of doing that, though:
>>
>> 1. Commit the Scala site in a separate directory similar to what I
>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>> .htaccess if possible to keep links from breaking.
>> 2. Commit the Scala site where it would go when creating the main site.
>> Depending on how you update the files in svn for a site update, could this
>> be more annoying to maintain?
>>
>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>
>> From my perspective that doesn’t matter. However, we would really need a
>> Scala site before we can modify the Log4j site, otherwise it will be a dead
>> link.
>>
>> All that really needs to happen is the Scala site needs to be checked in
>> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
>> Scala site from the main menu. The two sites won’t really be “integrated” -
>> they will just have links to each other.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>
>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>
>> I don’t have the numbers but I have a couple of issues that need fixes.
>>
>> The modules stuff doesn’t require a major version bump. It is mostly
>> cosmetic.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>> I think we can do 2.8.1 with our current bug fixes. Moving modules around
>> feels like a 2.9 item to me but that's just me. I really like the idea of
>> making bug fixes available ASAP. The only issue I see that fixing now is
>> the null classloader issue for which we have a patch but it does not work
>> for me (see JIRA).
>>
>> Gary
>>
>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I'm hoping we can get this released soon as we have some bugfixes and
>> such ready to go. I also want to move forward with 2.9 changes but don't
>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>> branch. Let's go over anything left to do for 2.8.1:
>>
>> * Integrated log4j-api-scala website into main site
>> * Remove scala modules from logging-log4j2 repo
>> * Release scala modules from logging-log4j-scala repo (presumably shortly
>> after releasing 2.8.1 of core?)
>>
>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's
>> for another day. I think getting everything working properly in Java 9
>> would be a good thing to start doing soon so we can figure out if our APIs
>> will still work properly in the future or if we need to break backwards
>> compatibility. Although, multi-jar support could help in migrating the API
>> if needed for 9+, though that would be a rather unorthodox abuse of the
>> feature.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>
>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>> JUnit in Action, Second Edition
>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>
>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>> Spring Batch in Action
>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Remko Popma <re...@gmail.com>.
To be honest I still don't understand
* the vision of what we ultimately want to achieve
* how different repos fit into that vision
* what different websites we are planning to create to give users access to
these different modules
* what websites are going to be driven from which modules or projects
* who of us is going to be driving what aspect of the above
My lack of understanding is not just limited to the Scala modules but is
about the whole splitting up the release.
Perhaps a diagram would help clarify my understanding. (I think there's
already a JIRA or an epic for the above. Adding some diagrams there would
be very useful.)
Remko
On Tue, Feb 28, 2017 at 2:26 Matt Sicker <bo...@gmail.com> wrote:
> I'd be in favour of starting a new release train for the Log4j Scala APIs.
> Not exactly sure which version to start from, though.
>
> On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> If you use that excuse they will never get released as it creates a
> catch-22. If I release without them then we have a regression until they
> are released.
>
> This is why you shouldn’t really be releasing them using the Log4j
> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>
> Once you create the release and deploy it to the web site I can modify the
> web site to point to it.
>
> Ralph
>
> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
> harder to release from the log4j-scala repo when two of the three artifacts
> will already exist.
>
> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> Why is the release of log4j-scala delayed?
>
> Ralph
>
> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>
> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought
> that it would be released as part of 2.8, otherwise I would have put it to
> the main repo as well. But now releasing of the log4j-scala repo has been
> delayed and I start to get disappointed.
>
> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Relative symlinks would work for that regardless of version. Option 1 it
> is, then?
>
> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>
> Note that the link in the log4j site can reference a symlink so that the
> log4j site never has to change when the Scala site is updated.
>
> Ralph
>
> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>
> Option 2 makes no sense to me. I don’t plan on being the release manager
> for log4j-scala. In order for me to implement option 2 I would have to
> include the log4j-scala site into the log4j release process - as well as
> log4j-examples, etc if they move out. That is just not doable. Deploying
> the Scala site parallel to log4j makes it much easier to maintain
> independently of log4j.
>
> Ralph
>
> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> The site repository is laid out like this:
>
> log4j/2.x/ -(symlink)-> log4j-2.8/
> log4j/log4j-2.8/log4j-api/
> ...
> log4j/2.x/log4j-api-scala_2.11/
>
> Option 1 is to put it here instead:
> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
> ugly URL honestly)
> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>
> Option 2 is to commit the scala site where it is now, but you'd have to
> manage it alongside log4j core releases. Option 1 still requires
> maintenance, too.
>
> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>
> There is a specific location in svn where the site pages have to be
> committed, so I don’t really understand option 1.
>
> Ralph
>
> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I see two ways of doing that, though:
>
> 1. Commit the Scala site in a separate directory similar to what I started
> doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if
> possible to keep links from breaking.
> 2. Commit the Scala site where it would go when creating the main site.
> Depending on how you update the files in svn for a site update, could this
> be more annoying to maintain?
>
> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>
> From my perspective that doesn’t matter. However, we would really need a
> Scala site before we can modify the Log4j site, otherwise it will be a dead
> link.
>
> All that really needs to happen is the Scala site needs to be checked in
> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
> Scala site from the main menu. The two sites won’t really be “integrated” -
> they will just have links to each other.
>
> Ralph
>
> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>
> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>
> I don’t have the numbers but I have a couple of issues that need fixes.
>
> The modules stuff doesn’t require a major version bump. It is mostly
> cosmetic.
>
> Ralph
>
> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> I think we can do 2.8.1 with our current bug fixes. Moving modules around
> feels like a 2.9 item to me but that's just me. I really like the idea of
> making bug fixes available ASAP. The only issue I see that fixing now is
> the null classloader issue for which we have a patch but it does not work
> for me (see JIRA).
>
> Gary
>
> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I'm hoping we can get this released soon as we have some bugfixes and such
> ready to go. I also want to move forward with 2.9 changes but don't really
> want to deal with creating a 2.9 branch or forking master into a 2.8
> branch. Let's go over anything left to do for 2.8.1:
>
> * Integrated log4j-api-scala website into main site
> * Remove scala modules from logging-log4j2 repo
> * Release scala modules from logging-log4j-scala repo (presumably shortly
> after releasing 2.8.1 of core?)
>
> I also have ideas on what we can shoot for in 2.9 and beyond, but that's
> for another day. I think getting everything working properly in Java 9
> would be a good thing to start doing soon so we can figure out if our APIs
> will still work properly in the future or if we need to break backwards
> compatibility. Although, multi-jar support could help in migrating the API
> if needed for 9+, though that would be a rather unorthodox abuse of the
> feature.
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
I'd be in favour of starting a new release train for the Log4j Scala APIs.
Not exactly sure which version to start from, though.
On 27 February 2017 at 18:35, Ralph Goers <ra...@dslextreme.com>
wrote:
> If you use that excuse they will never get released as it creates a
> catch-22. If I release without them then we have a regression until they
> are released.
>
> This is why you shouldn’t really be releasing them using the Log4j
> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>
> Once you create the release and deploy it to the web site I can modify the
> web site to point to it.
>
> Ralph
>
> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
> harder to release from the log4j-scala repo when two of the three artifacts
> will already exist.
>
> On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Why is the release of log4j-scala delayed?
>>
>> Ralph
>>
>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>
>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>> thought that it would be released as part of 2.8, otherwise I would have
>> put it to the main repo as well. But now releasing of the log4j-scala repo
>> has been delayed and I start to get disappointed.
>>
>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Relative symlinks would work for that regardless of version. Option 1 it
>>> is, then?
>>>
>>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>>
>>>> Note that the link in the log4j site can reference a symlink so that
>>>> the log4j site never has to change when the Scala site is updated.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>> Option 2 makes no sense to me. I don’t plan on being the release
>>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>>> to include the log4j-scala site into the log4j release process - as well as
>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>> independently of log4j.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> The site repository is laid out like this:
>>>>
>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>> log4j/log4j-2.8/log4j-api/
>>>> ...
>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>
>>>> Option 1 is to put it here instead:
>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>> pretty ugly URL honestly)
>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>
>>>> Option 2 is to commit the scala site where it is now, but you'd have to
>>>> manage it alongside log4j core releases. Option 1 still requires
>>>> maintenance, too.
>>>>
>>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> There is a specific location in svn where the site pages have to be
>>>>> committed, so I don’t really understand option 1.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I see two ways of doing that, though:
>>>>>
>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>> .htaccess if possible to keep links from breaking.
>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>> site. Depending on how you update the files in svn for a site update, could
>>>>> this be more annoying to maintain?
>>>>>
>>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>> need a Scala site before we can modify the Log4j site, otherwise it will be
>>>>>> a dead link.
>>>>>>
>>>>>> All that really needs to happen is the Scala site needs to be checked
>>>>>> in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to
>>>>>> the Scala site from the main menu. The two sites won’t really be
>>>>>> “integrated” - they will just have links to each other.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>
>>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>> fixes.
>>>>>>>
>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>>>> cosmetic.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>>>> work for me (see JIRA).
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>>> don't really want to deal with creating a 2.9 branch or forking master into
>>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>>
>>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>>
>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>>> unorthodox abuse of the feature.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>> JUnit in Action, Second Edition
>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>> Spring Batch in Action
>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Ralph Goers <ra...@dslextreme.com>.
If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
Once you create the release and deploy it to the web site I can modify the web site to point to it.
Ralph
> On Feb 27, 2017, at 5:19 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder to release from the log4j-scala repo when two of the three artifacts will already exist.
>
> On 27 February 2017 at 12:14, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> Why is the release of log4j-scala delayed?
>
> Ralph
>
>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>
>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>>
>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>>
>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>>
>> On 25 February 2017 at 00:22, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>>
>> Ralph
>>
>>> On Feb 24, 2017, at 11:21 PM, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>
>>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>>
>>> Ralph
>>>
>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> The site repository is laid out like this:
>>>>
>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>> log4j/log4j-2.8/log4j-api/
>>>> ...
>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>
>>>> Option 1 is to put it here instead:
>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>
>>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>>
>>>> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>>
>>>> Ralph
>>>>
>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> I see two ways of doing that, though:
>>>>>
>>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>>
>>>>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>>
>>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>
>>>>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>>
>>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>
>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>>
>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>>>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder
to release from the log4j-scala repo when two of the three artifacts will
already exist.
On 27 February 2017 at 12:14, Ralph Goers <ra...@dslextreme.com>
wrote:
> Why is the release of log4j-scala delayed?
>
> Ralph
>
> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>
> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought
> that it would be released as part of 2.8, otherwise I would have put it to
> the main repo as well. But now releasing of the log4j-scala repo has been
> delayed and I start to get disappointed.
>
> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Relative symlinks would work for that regardless of version. Option 1 it
>> is, then?
>>
>> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>>
>>> Note that the link in the log4j site can reference a symlink so that the
>>> log4j site never has to change when the Scala site is updated.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>>
>>> Option 2 makes no sense to me. I don’t plan on being the release
>>> manager for log4j-scala. In order for me to implement option 2 I would have
>>> to include the log4j-scala site into the log4j release process - as well as
>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>> the Scala site parallel to log4j makes it much easier to maintain
>>> independently of log4j.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> The site repository is laid out like this:
>>>
>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>> log4j/log4j-2.8/log4j-api/
>>> ...
>>> log4j/2.x/log4j-api-scala_2.11/
>>>
>>> Option 1 is to put it here instead:
>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
>>> ugly URL honestly)
>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>
>>> Option 2 is to commit the scala site where it is now, but you'd have to
>>> manage it alongside log4j core releases. Option 1 still requires
>>> maintenance, too.
>>>
>>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>>
>>>> There is a specific location in svn where the site pages have to be
>>>> committed, so I don’t really understand option 1.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I see two ways of doing that, though:
>>>>
>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>> .htaccess if possible to keep links from breaking.
>>>> 2. Commit the Scala site where it would go when creating the main site.
>>>> Depending on how you update the files in svn for a site update, could this
>>>> be more annoying to maintain?
>>>>
>>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> From my perspective that doesn’t matter. However, we would really need
>>>>> a Scala site before we can modify the Log4j site, otherwise it will be a
>>>>> dead link.
>>>>>
>>>>> All that really needs to happen is the Scala site needs to be checked
>>>>> in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to
>>>>> the Scala site from the main menu. The two sites won’t really be
>>>>> “integrated” - they will just have links to each other.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>
>>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>> fixes.
>>>>>>
>>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>>> cosmetic.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>>> work for me (see JIRA).
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>> don't really want to deal with creating a 2.9 branch or forking master into
>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>
>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>
>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>> unorthodox abuse of the feature.
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>
>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>> JUnit in Action, Second Edition
>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>
>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>> Spring Batch in Action
>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Ralph Goers <ra...@dslextreme.com>.
Why is the release of log4j-scala delayed?
Ralph
> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mi...@magine.com> wrote:
>
> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>
> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought that it would be released as part of 2.8, otherwise I would have put it to the main repo as well. But now releasing of the log4j-scala repo has been delayed and I start to get disappointed.
>
> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> Relative symlinks would work for that regardless of version. Option 1 it is, then?
>
> On 25 February 2017 at 00:22, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
>
> Ralph
>
>> On Feb 24, 2017, at 11:21 PM, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>
>> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>>
>> Ralph
>>
>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> The site repository is laid out like this:
>>>
>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>> log4j/log4j-2.8/log4j-api/
>>> ...
>>> log4j/2.x/log4j-api-scala_2.11/
>>>
>>> Option 1 is to put it here instead:
>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>
>>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>>
>>> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>>
>>> Ralph
>>>
>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> I see two ways of doing that, though:
>>>>
>>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>>
>>>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>>
>>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>>
>>>> Ralph
>>>>
>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>
>>>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>
>>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>
>>>>>> * Integrated log4j-api-scala website into main site
>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>>
>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com <ma...@magine.com>
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Roadmap for 2.8.1
Posted by Mikael Ståldal <mi...@magine.com>.
I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought
that it would be released as part of 2.8, otherwise I would have put it to
the main repo as well. But now releasing of the log4j-scala repo has been
delayed and I start to get disappointed.
On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <bo...@gmail.com> wrote:
> Relative symlinks would work for that regardless of version. Option 1 it
> is, then?
>
> On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
>
>> Note that the link in the log4j site can reference a symlink so that the
>> log4j site never has to change when the Scala site is updated.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>>
>> Option 2 makes no sense to me. I don’t plan on being the release manager
>> for log4j-scala. In order for me to implement option 2 I would have to
>> include the log4j-scala site into the log4j release process - as well as
>> log4j-examples, etc if they move out. That is just not doable. Deploying
>> the Scala site parallel to log4j makes it much easier to maintain
>> independently of log4j.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> The site repository is laid out like this:
>>
>> log4j/2.x/ -(symlink)-> log4j-2.8/
>> log4j/log4j-2.8/log4j-api/
>> ...
>> log4j/2.x/log4j-api-scala_2.11/
>>
>> Option 1 is to put it here instead:
>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
>> ugly URL honestly)
>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>
>> Option 2 is to commit the scala site where it is now, but you'd have to
>> manage it alongside log4j core releases. Option 1 still requires
>> maintenance, too.
>>
>> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>>
>>> There is a specific location in svn where the site pages have to be
>>> committed, so I don’t really understand option 1.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I see two ways of doing that, though:
>>>
>>> 1. Commit the Scala site in a separate directory similar to what I
>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>> .htaccess if possible to keep links from breaking.
>>> 2. Commit the Scala site where it would go when creating the main site.
>>> Depending on how you update the files in svn for a site update, could this
>>> be more annoying to maintain?
>>>
>>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>>
>>>> From my perspective that doesn’t matter. However, we would really need
>>>> a Scala site before we can modify the Log4j site, otherwise it will be a
>>>> dead link.
>>>>
>>>> All that really needs to happen is the Scala site needs to be checked
>>>> in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to
>>>> the Scala site from the main menu. The two sites won’t really be
>>>> “integrated” - they will just have links to each other.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>
>>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>>
>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>> cosmetic.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>>> now is the null classloader issue for which we have a patch but it does not
>>>>> work for me (see JIRA).
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>>> I'm hoping we can get this released soon as we have some bugfixes and
>>>>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>>>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>>>>> branch. Let's go over anything left to do for 2.8.1:
>>>>>>
>>>>>> * Integrated log4j-api-scala website into main site
>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>
>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>> that's for another day. I think getting everything working properly in Java
>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>> APIs will still work properly in the future or if we need to break
>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>> unorthodox abuse of the feature.
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>
>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>> JUnit in Action, Second Edition
>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>
>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>> Spring Batch in Action
>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
Relative symlinks would work for that regardless of version. Option 1 it
is, then?
On 25 February 2017 at 00:22, Apache <ra...@dslextreme.com> wrote:
> Note that the link in the log4j site can reference a symlink so that the
> log4j site never has to change when the Scala site is updated.
>
> Ralph
>
> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>
> Option 2 makes no sense to me. I don’t plan on being the release manager
> for log4j-scala. In order for me to implement option 2 I would have to
> include the log4j-scala site into the log4j release process - as well as
> log4j-examples, etc if they move out. That is just not doable. Deploying
> the Scala site parallel to log4j makes it much easier to maintain
> independently of log4j.
>
> Ralph
>
> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> The site repository is laid out like this:
>
> log4j/2.x/ -(symlink)-> log4j-2.8/
> log4j/log4j-2.8/log4j-api/
> ...
> log4j/2.x/log4j-api-scala_2.11/
>
> Option 1 is to put it here instead:
> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
> ugly URL honestly)
> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>
> Option 2 is to commit the scala site where it is now, but you'd have to
> manage it alongside log4j core releases. Option 1 still requires
> maintenance, too.
>
> On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
>
>> There is a specific location in svn where the site pages have to be
>> committed, so I don’t really understand option 1.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I see two ways of doing that, though:
>>
>> 1. Commit the Scala site in a separate directory similar to what I
>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>> .htaccess if possible to keep links from breaking.
>> 2. Commit the Scala site where it would go when creating the main site.
>> Depending on how you update the files in svn for a site update, could this
>> be more annoying to maintain?
>>
>> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>>
>>> From my perspective that doesn’t matter. However, we would really need a
>>> Scala site before we can modify the Log4j site, otherwise it will be a dead
>>> link.
>>>
>>> All that really needs to happen is the Scala site needs to be checked in
>>> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
>>> Scala site from the main menu. The two sites won’t really be “integrated” -
>>> they will just have links to each other.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>
>>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>>
>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>
>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>> cosmetic.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>>> now is the null classloader issue for which we have a patch but it does not
>>>> work for me (see JIRA).
>>>>
>>>> Gary
>>>>
>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> I'm hoping we can get this released soon as we have some bugfixes and
>>>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>>>> branch. Let's go over anything left to do for 2.8.1:
>>>>>
>>>>> * Integrated log4j-api-scala website into main site
>>>>> * Remove scala modules from logging-log4j2 repo
>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>> shortly after releasing 2.8.1 of core?)
>>>>>
>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>> that's for another day. I think getting everything working properly in Java
>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>> APIs will still work properly in the future or if we need to break
>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>> unorthodox abuse of the feature.
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>> JUnit in Action, Second Edition
>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>> Spring Batch in Action
>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
Note that the link in the log4j site can reference a symlink so that the log4j site never has to change when the Scala site is updated.
Ralph
> On Feb 24, 2017, at 11:21 PM, Apache <ra...@dslextreme.com> wrote:
>
> Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
>
> Ralph
>
>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>> The site repository is laid out like this:
>>
>> log4j/2.x/ -(symlink)-> log4j-2.8/
>> log4j/log4j-2.8/log4j-api/
>> ...
>> log4j/2.x/log4j-api-scala_2.11/
>>
>> Option 1 is to put it here instead:
>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>
>> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>>
>> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>>
>> Ralph
>>
>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> I see two ways of doing that, though:
>>>
>>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>>
>>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>>
>>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>>
>>> Ralph
>>>
>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>
>>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>>
>>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>>
>>>> Ralph
>>>>
>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>
>>>>> * Integrated log4j-api-scala website into main site
>>>>> * Remove scala modules from logging-log4j2 repo
>>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>>
>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
Ralph
> On Feb 24, 2017, at 11:15 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> The site repository is laid out like this:
>
> log4j/2.x/ -(symlink)-> log4j-2.8/
> log4j/log4j-2.8/log4j-api/
> ...
> log4j/2.x/log4j-api-scala_2.11/
>
> Option 1 is to put it here instead:
> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly URL honestly)
> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>
> Option 2 is to commit the scala site where it is now, but you'd have to manage it alongside log4j core releases. Option 1 still requires maintenance, too.
>
> On 25 February 2017 at 00:05, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
>
> Ralph
>
>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>> I see two ways of doing that, though:
>>
>> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
>> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>>
>> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>>
>> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>>
>> Ralph
>>
>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>
>>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>
>>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>>
>>> Ralph
>>>
>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>>
>>>> Gary
>>>>
>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>
>>>> * Integrated log4j-api-scala website into main site
>>>> * Remove scala modules from logging-log4j2 repo
>>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>>
>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
The site repository is laid out like this:
log4j/2.x/ -(symlink)-> log4j-2.8/
log4j/log4j-2.8/log4j-api/
...
log4j/2.x/log4j-api-scala_2.11/
Option 1 is to put it here instead:
log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
ugly URL honestly)
log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
Option 2 is to commit the scala site where it is now, but you'd have to
manage it alongside log4j core releases. Option 1 still requires
maintenance, too.
On 25 February 2017 at 00:05, Apache <ra...@dslextreme.com> wrote:
> There is a specific location in svn where the site pages have to be
> committed, so I don’t really understand option 1.
>
> Ralph
>
> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I see two ways of doing that, though:
>
> 1. Commit the Scala site in a separate directory similar to what I started
> doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if
> possible to keep links from breaking.
> 2. Commit the Scala site where it would go when creating the main site.
> Depending on how you update the files in svn for a site update, could this
> be more annoying to maintain?
>
> On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
>
>> From my perspective that doesn’t matter. However, we would really need a
>> Scala site before we can modify the Log4j site, otherwise it will be a dead
>> link.
>>
>> All that really needs to happen is the Scala site needs to be checked in
>> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
>> Scala site from the main menu. The two sites won’t really be “integrated” -
>> they will just have links to each other.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>
>> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>>
>>> I don’t have the numbers but I have a couple of issues that need fixes.
>>>
>>> The modules stuff doesn’t require a major version bump. It is mostly
>>> cosmetic.
>>>
>>> Ralph
>>>
>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>> around feels like a 2.9 item to me but that's just me. I really like the
>>> idea of making bug fixes available ASAP. The only issue I see that fixing
>>> now is the null classloader issue for which we have a patch but it does not
>>> work for me (see JIRA).
>>>
>>> Gary
>>>
>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> I'm hoping we can get this released soon as we have some bugfixes and
>>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>>> branch. Let's go over anything left to do for 2.8.1:
>>>>
>>>> * Integrated log4j-api-scala website into main site
>>>> * Remove scala modules from logging-log4j2 repo
>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>> shortly after releasing 2.8.1 of core?)
>>>>
>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>> that's for another day. I think getting everything working properly in Java
>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>> APIs will still work properly in the future or if we need to break
>>>> backwards compatibility. Although, multi-jar support could help in
>>>> migrating the API if needed for 9+, though that would be a rather
>>>> unorthodox abuse of the feature.
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>> JUnit in Action, Second Edition
>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>> Spring Batch in Action
>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
There is a specific location in svn where the site pages have to be committed, so I don’t really understand option 1.
Ralph
> On Feb 24, 2017, at 9:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I see two ways of doing that, though:
>
> 1. Commit the Scala site in a separate directory similar to what I started doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if possible to keep links from breaking.
> 2. Commit the Scala site where it would go when creating the main site. Depending on how you update the files in svn for a site update, could this be more annoying to maintain?
>
> On 24 February 2017 at 22:30, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
>
> All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
>
> Ralph
>
>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>
>> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> I don’t have the numbers but I have a couple of issues that need fixes.
>>
>> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>>
>> Ralph
>>
>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>>
>>> Gary
>>>
>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>
>>> * Integrated log4j-api-scala website into main site
>>> * Remove scala modules from logging-log4j2 repo
>>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>>
>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
I see two ways of doing that, though:
1. Commit the Scala site in a separate directory similar to what I started
doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if
possible to keep links from breaking.
2. Commit the Scala site where it would go when creating the main site.
Depending on how you update the files in svn for a site update, could this
be more annoying to maintain?
On 24 February 2017 at 22:30, Apache <ra...@dslextreme.com> wrote:
> From my perspective that doesn’t matter. However, we would really need a
> Scala site before we can modify the Log4j site, otherwise it will be a dead
> link.
>
> All that really needs to happen is the Scala site needs to be checked in
> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
> Scala site from the main menu. The two sites won’t really be “integrated” -
> they will just have links to each other.
>
> Ralph
>
> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>
> On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
>
>> I don’t have the numbers but I have a couple of issues that need fixes.
>>
>> The modules stuff doesn’t require a major version bump. It is mostly
>> cosmetic.
>>
>> Ralph
>>
>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>> I think we can do 2.8.1 with our current bug fixes. Moving modules around
>> feels like a 2.9 item to me but that's just me. I really like the idea of
>> making bug fixes available ASAP. The only issue I see that fixing now is
>> the null classloader issue for which we have a patch but it does not work
>> for me (see JIRA).
>>
>> Gary
>>
>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I'm hoping we can get this released soon as we have some bugfixes and
>>> such ready to go. I also want to move forward with 2.9 changes but don't
>>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>>> branch. Let's go over anything left to do for 2.8.1:
>>>
>>> * Integrated log4j-api-scala website into main site
>>> * Remove scala modules from logging-log4j2 repo
>>> * Release scala modules from logging-log4j-scala repo (presumably
>>> shortly after releasing 2.8.1 of core?)
>>>
>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's
>>> for another day. I think getting everything working properly in Java 9
>>> would be a good thing to start doing soon so we can figure out if our APIs
>>> will still work properly in the future or if we need to break backwards
>>> compatibility. Although, multi-jar support could help in migrating the API
>>> if needed for 9+, though that would be a rather unorthodox abuse of the
>>> feature.
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>
>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>> JUnit in Action, Second Edition
>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>
>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>> Spring Batch in Action
>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
From my perspective that doesn’t matter. However, we would really need a Scala site before we can modify the Log4j site, otherwise it will be a dead link.
All that really needs to happen is the Scala site needs to be checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the Scala site from the main menu. The two sites won’t really be “integrated” - they will just have links to each other.
Ralph
> On Feb 24, 2017, at 5:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>
> On 24 February 2017 at 14:17, Apache <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I don’t have the numbers but I have a couple of issues that need fixes.
>
> The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
>
> Ralph
>
>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>
>> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>>
>> Gary
>>
>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>
>> * Integrated log4j-api-scala website into main site
>> * Remove scala modules from logging-log4j2 repo
>> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>>
>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Roadmap for 2.8.1
Posted by Matt Sicker <bo...@gmail.com>.
It is cosmetic, but we'd also be adding the Scala 2.12 module.
On 24 February 2017 at 14:17, Apache <ra...@dslextreme.com> wrote:
> I don’t have the numbers but I have a couple of issues that need fixes.
>
> The modules stuff doesn’t require a major version bump. It is mostly
> cosmetic.
>
> Ralph
>
> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> I think we can do 2.8.1 with our current bug fixes. Moving modules around
> feels like a 2.9 item to me but that's just me. I really like the idea of
> making bug fixes available ASAP. The only issue I see that fixing now is
> the null classloader issue for which we have a patch but it does not work
> for me (see JIRA).
>
> Gary
>
> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> I'm hoping we can get this released soon as we have some bugfixes and
>> such ready to go. I also want to move forward with 2.9 changes but don't
>> really want to deal with creating a 2.9 branch or forking master into a 2.8
>> branch. Let's go over anything left to do for 2.8.1:
>>
>> * Integrated log4j-api-scala website into main site
>> * Remove scala modules from logging-log4j2 repo
>> * Release scala modules from logging-log4j-scala repo (presumably shortly
>> after releasing 2.8.1 of core?)
>>
>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's
>> for another day. I think getting everything working properly in Java 9
>> would be a good thing to start doing soon so we can figure out if our APIs
>> will still work properly in the future or if we need to break backwards
>> compatibility. Although, multi-jar support could help in migrating the API
>> if needed for 9+, though that would be a rather unorthodox abuse of the
>> feature.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Roadmap for 2.8.1
Posted by Apache <ra...@dslextreme.com>.
I don’t have the numbers but I have a couple of issues that need fixes.
The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
Ralph
> On Feb 24, 2017, at 12:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> I think we can do 2.8.1 with our current bug fixes. Moving modules around feels like a 2.9 item to me but that's just me. I really like the idea of making bug fixes available ASAP. The only issue I see that fixing now is the null classloader issue for which we have a patch but it does not work for me (see JIRA).
>
> Gary
>
> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> I'm hoping we can get this released soon as we have some bugfixes and such ready to go. I also want to move forward with 2.9 changes but don't really want to deal with creating a 2.9 branch or forking master into a 2.8 branch. Let's go over anything left to do for 2.8.1:
>
> * Integrated log4j-api-scala website into main site
> * Remove scala modules from logging-log4j2 repo
> * Release scala modules from logging-log4j-scala repo (presumably shortly after releasing 2.8.1 of core?)
>
> I also have ideas on what we can shoot for in 2.9 and beyond, but that's for another day. I think getting everything working properly in Java 9 would be a good thing to start doing soon so we can figure out if our APIs will still work properly in the future or if we need to break backwards compatibility. Although, multi-jar support could help in migrating the API if needed for 9+, though that would be a rather unorthodox abuse of the feature.
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Roadmap for 2.8.1
Posted by Gary Gregory <ga...@gmail.com>.
I think we can do 2.8.1 with our current bug fixes. Moving modules around
feels like a 2.9 item to me but that's just me. I really like the idea of
making bug fixes available ASAP. The only issue I see that fixing now is
the null classloader issue for which we have a patch but it does not work
for me (see JIRA).
Gary
On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <bo...@gmail.com> wrote:
> I'm hoping we can get this released soon as we have some bugfixes and such
> ready to go. I also want to move forward with 2.9 changes but don't really
> want to deal with creating a 2.9 branch or forking master into a 2.8
> branch. Let's go over anything left to do for 2.8.1:
>
> * Integrated log4j-api-scala website into main site
> * Remove scala modules from logging-log4j2 repo
> * Release scala modules from logging-log4j-scala repo (presumably shortly
> after releasing 2.8.1 of core?)
>
> I also have ideas on what we can shoot for in 2.9 and beyond, but that's
> for another day. I think getting everything working properly in Java 9
> would be a good thing to start doing soon so we can figure out if our APIs
> will still work properly in the future or if we need to break backwards
> compatibility. Although, multi-jar support could help in migrating the API
> if needed for 9+, though that would be a rather unorthodox abuse of the
> feature.
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory