On 2017-05-22, Dominik Psenner wrote:
> This is a vote to introduce gitflow on the log4net subproject. gitflow
> would mean that we make use of the following named branches:
> * master
> Marks stable milestones and is moves on with a release.
> * develop
> Development of the next milesto
I've been through the vi vs emacs debate more than twenty years ago,
both are decent.
Yes, feel free to unify the solution files, just keep in mind we've also
got a .NET Core project file that may need to get adapted (as it
excludes files explicitly, this is less work).
Stefan
On 2017-05-22, Dom
[
https://issues.apache.org/jira/browse/LOG4J2-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020508#comment-16020508
]
Gary Gregory commented on LOG4J2-1911:
--
You can either attach a diff file to this ti
[
https://issues.apache.org/jira/browse/LOG4J2-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020503#comment-16020503
]
Jerry Chin commented on LOG4J2-1911:
[~garydgregory] can you tell where I can supply
[
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020489#comment-16020489
]
ASF GitHub Bot commented on LOG4J2-1874:
Github user leventov commented on the is
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop thanks for commitment
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enable
[
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020426#comment-16020426
]
ASF GitHub Bot commented on LOG4J2-1874:
Github user remkop commented on the issu
Github user remkop commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
I got distracted by other things but still reviewing.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not h
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020351#comment-16020351
]
Dominik Psenner commented on LOG4NET-565:
-
That's something that the xml configur
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020275#comment-16020275
]
Hitesh Chauhan commented on LOG4NET-565:
Thanks Dominik for the pseudo code. My q
This is a vote to introduce gitflow on the log4net subproject. gitflow
would mean that we make use of the following named branches:
* master
Marks stable milestones and is moves on with a release.
* develop
Development of the next milestone should happen here.
* feature/featurename
Right now I could use the develop branch because I have made the
modifications that remove the old solution files and updates the solution
to visual studio 2015. It makes no sense to make those changes either in
the feature branch, nore the master branch but I would like to push those
changes somew
I'm a vi guy and have no need for a decent window manager. ;-)
Can I proceed with bumping the solution to visual studio 2015 and removing
all solution files on the master branch?
2017-05-22 18:19 GMT+02:00 Stefan Bodewig :
> On 2017-05-22, Dominik Psenner wrote:
>
> > On 2017-05-22 13:59, Stefan
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020094#comment-16020094
]
Dominik Psenner commented on LOG4NET-565:
-
I imagined an Appender that works almo
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop any extra comments on this?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
[
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020029#comment-16020029
]
ASF GitHub Bot commented on LOG4J2-1874:
Github user leventov commented on the is
Then I keep it as "set" in HttpAppender.
On 2017-05-22 20:26, Gary Gregory wrote:
On Mon, May 22, 2017 at 8:54 AM, Mikael Ståldal wrote:
SocketAppender uses "with" like this:
public B withSslConfiguration(final SslConfiguration sslConfiguration) {
this.sslConfiguration = sslConfiguratio
[
https://issues.apache.org/jira/browse/LOG4J2-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020002#comment-16020002
]
Gary Gregory commented on LOG4J2-1914:
--
Would you mind posting the 2.8.2 stack trace
[
https://issues.apache.org/jira/browse/LOG4J2-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019995#comment-16019995
]
Leon Finker commented on LOG4J2-1914:
-
Hi Gary,
Tried with 2.8.2 and same exception.
On Mon, May 22, 2017 at 8:54 AM, Mikael Ståldal wrote:
> SocketAppender uses "with" like this:
>
> public B withSslConfiguration(final SslConfiguration sslConfiguration) {
> this.sslConfiguration = sslConfiguration;
> return asBuilder();
> }
>
> is that wrong?
>
In my mind, yes, but it i
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019915#comment-16019915
]
Hitesh Chauhan edited comment on LOG4NET-565 at 5/22/17 6:20 PM:
--
On Mon, May 22, 2017 at 9:02 AM, wrote:
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/LOG4J2-1442 42dcb4588 -> 93ac8ab82
>
>
> Https support (W.I.P.)
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/loggin
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019915#comment-16019915
]
Hitesh Chauhan commented on LOG4NET-565:
To me, this is similar to what core does
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019870#comment-16019870
]
Dominik Psenner commented on LOG4NET-565:
-
Further it would reduce the service lo
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019867#comment-16019867
]
Dominik Psenner commented on LOG4NET-565:
-
Is there a reason why you have not put
Splitting the Java 9 code into its own module and shading that back in to
log4j-api seems like it could work for now. I'd imagine that as Java 9 gets
released or sometime soon hopefully, the IDEs will start adding support for
multi-version modules/projects.
On 22 May 2017 at 11:16, Remko Popma wr
On 2017-05-22, Dominik Psenner wrote:
> On 2017-05-22 13:59, Stefan Bodewig wrote:
>> As long as we keep NAnt as the build tool of truth the solution files
>> are "only" a convenience feature for people using VS (likely everybody
>> except myself :-).
> How do you develop log4net if not with vis
One idea: we could move (actually copy) the StackLocator interface to the
Java 9 module.
This allows us to build the Java 9 module first. Then, when building the
log4j-api module, the Java 9 classes can be shaded into the log4j-api jar
(excluding StackLocator since we want to compile that interface
I like that distinction, Gary. For example, the withers in Lombok are used
for creating copies with the named property updated. A builder pattern
using the same builder instance would then make sense to use setter names
instead of wither names.
On 22 May 2017 at 10:54, Mikael Ståldal wrote:
> So
Is Monodevelop still a thing? I used to use that back in college in my C#
class.
On 22 May 2017 at 10:21, Dominik Psenner wrote:
>
> On 2017-05-22 13:59, Stefan Bodewig wrote:
>
>> As long as we keep NAnt as the build tool of truth the solution files
>> are "only" a convenience feature for peopl
The master branch holding only production tags is useful for making a
production hotfix release. For example, this would be useful in making
security patches. As for holding release branches, in my use of git-flow,
I've always deleted them after merging back to develop&master, but in
theory, it cou
Java 9 now has a —release option which should help. However, if we set it to
Java 7 I suspect the build will fail on the Java 9 stuff even though we are
using the Java 9 compiler. I really don’t see a way to do this except by
calling the compiler multiple times.
Ralph
> On May 22, 2017, at 8:4
I’ll look at it as well provided I have the time.
Ralph
> On May 22, 2017, at 8:12 AM, Mikael Ståldal wrote:
>
> If I remembered correctly, Gary was willing to test it and vote if there were
> building instructions. And now there are.
>
>
> On 2017-05-22 17:01, Matt Sicker wrote:
>> I haven'
SocketAppender uses "with" like this:
public B withSslConfiguration(final SslConfiguration sslConfiguration) {
this.sslConfiguration = sslConfiguration;
return asBuilder();
}
is that wrong?
On 2017-05-22 17:50, Gary Gregory wrote:
I like "with" for methods that return a new instance an
I like "with" for methods that return a new instance and "set" for those
that do not.
Since most if not all of our builders don't create new instances on setter
calls I would go with "set".
2c,
Gary
Gary
On May 22, 2017 8:36 AM, "Mikael Ståldal" wrote:
> What is the preferred naming conventio
I still want to see a better Maven plugin for handling Java 9 multi-release
jars and things like that. The whole Java 9 build is still rather hacky. If
the entire project was buildable in Java 9 and could still target 7, 8, and
9, then that would be a simpler solution IMO.
On 22 May 2017 at 06:16,
What is the preferred naming convention for plugin builder setter
methods? It is setXXX or withXXX? I see both being used in the code base.
I wonder which to use for the upcoming HttpAppender (LOG4J2-1442).
On 2017-05-22 13:59, Stefan Bodewig wrote:
As long as we keep NAnt as the build tool of truth the solution files
are "only" a convenience feature for people using VS (likely everybody
except myself :-).
How do you develop log4net if not with visual studio?
If I remembered correctly, Gary was willing to test it and vote if there
were building instructions. And now there are.
On 2017-05-22 17:01, Matt Sicker wrote:
I haven't had any time lately to make rc2. Based on the last vote, I'm
wondering if we'll get a third vote since nobody but us two are
I haven't had any time lately to make rc2. Based on the last vote, I'm
wondering if we'll get a third vote since nobody but us two are even using
Scala. ;)
On 22 May 2017 at 09:30, Mikael Ståldal wrote:
> How is it going with release of log4j-scala?
>
>
>
--
Matt Sicker
How is it going with release of log4j-scala?
[
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019609#comment-16019609
]
Hitesh Chauhan commented on LOG4NET-565:
I disabled my VS settings. This time you
Hi
Gary Gregory wrote on 19.05.2017 23:01:10:
> Howdy,
>
> Thank you for the link.
>
> This is fine until you want to manage more than once major version in
one
> repo, right?
>
> Over at HttpComponents, we have decided for now to keep to one repo, as
> opposed to one repo per major version.
[
https://issues.apache.org/jira/browse/LOG4J2-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019530#comment-16019530
]
Ralph Goers commented on LOG4J2-1917:
-
Yes, that was the last version where a change
[
https://issues.apache.org/jira/browse/LOG4J2-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019504#comment-16019504
]
Mikael Ståldal commented on LOG4J2-1917:
Should the version in Log4jProvider be 2
On 2017-05-21, Dominik Psenner wrote:
> To me the gitflow concept boils down to a way of tydying up the
> historical mess that piles up over the years. The branch
> feature/RollingFileAppender-NG dates actually back to 2012. I'd be
> happy already if we had a naming convention for the different br
As long as we keep NAnt as the build tool of truth the solution files
are "only" a convenience feature for people using VS (likely everybody
except myself :-).
Actually this is not completely true as we use "dotnet build" as well,
so it's not only NAnt.
I'd be fine with a single sln and laze vote
[
https://issues.apache.org/jira/browse/LOG4J2-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019479#comment-16019479
]
ASF subversion and git services commented on LOG4J2-1917:
-
Commit
IntelliJ IDEA is "smart" enough to automatically pick up the
src/main/java9 folder.
On 2017-05-21 22:26, Ralph Goers wrote:
Since src/main/java9 isn’t normally considered a source directory you should be
able to work with Java 7 as well. It will just ignore the Java 9 files.
Ralph
On May 2
49 matches
Mail list logo
