Re: [Log4j] log4j-server

For normal development I run Eclipse. I run mvn clean install before I commit anything non-trivial. So whether I do that in last step in Maven or Gradle is the same to me. The RM's job should be #1 consideration IMO. Gary On Fri, May 5, 2017 at 9:32 PM, Remko Popma

Re: [Log4j] log4j-server

The gitflow plugin looks promising. It seems to address the problem of the tests being run twice head-on : > >- Only builds your project once in the finish goal. e.g. if you do >release-start and

[jira] [Created] (LOG4J2-1896) Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[] to represent its password

Gary Gregory created LOG4J2-1896: Summary: Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[] to represent its password Key: LOG4J2-1896 URL:

[jira] [Updated] (LOG4J2-1896) Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[] to represent its password

[ https://issues.apache.org/jira/browse/LOG4J2-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1896: - Summary: Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[]

Re: [OT] Java 9 modules drama

On Fri, May 5, 2017 at 1:58 PM, Ralph Goers wrote: > A response from RedHat - http://mail.openjdk.java.net/ > pipermail/jpms-spec-experts/2017-May/000690.html < > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2017-May/000690.html>. > Quite sensitive it

Re: [OT] Java 9 modules drama

My take on a higher level is that Java 9 should be released without Jigsaw and make sure all the toolchains work out of the box, Maven, Gradle, and so on. Java 9 modules smell of NIH and if I really want modules today there are solutions out there: OSGi with many implementations, JBoss Modules,

[OT] Java 9 modules drama

FYI: http://mreinhold.org/blog/to-the-jcp-ec Gary

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

I agree with using char[] for this due to the overwriting of contents that Remko explained. Here's a neat Stack Overflow post to back us up: https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords On 5 May 2017 at 04:50, Remko Popma

Re: [Log4j] log4j-server

Yeah, it seems a bit easier to try experimenting with different Maven plugins first before going all in on Gradle or something else. On 5 May 2017 at 13:26, Ralph Goers wrote: > We could try using the maven gitflow plugin instead of the release plugin. > > Ralph > >

Re: [Log4j] log4j-server

We could try using the maven gitflow plugin instead of the release plugin. Ralph > On May 5, 2017, at 11:22 AM, Gary Gregory wrote: > > Is it possible to do mvn test and then the rest with -DskipTests? > > G > > On May 5, 2017 11:11 AM, "Ralph Goers"

Re: [Log4j] log4j-server

Is it possible to do mvn test and then the rest with -DskipTests? G On May 5, 2017 11:11 AM, "Ralph Goers" wrote: > Probably both. > > Ralph > > > On May 5, 2017, at 10:13 AM, Matt Sicker wrote: > > > > It seems like it. I'm not sure if it's in

Re: [Log4j] log4j-server

It seems like it. I'm not sure if it's in release:prepare or release:perform. On 5 May 2017 at 12:12, Gary Gregory wrote: > Are the tests run 3 times from within the same mvn call? > > Gary > > On May 5, 2017 5:54 AM, "Remko Popma" wrote: > > > I

Re: [Log4j] log4j-server

Are the tests run 3 times from within the same mvn call? Gary On May 5, 2017 5:54 AM, "Remko Popma" wrote: > I don't oppose breaking things up into modules, but I'm not sure that we > want to move modules into separate repos: I've seen this in practice at > work and I

Re: [Log4j] log4j-server

Gradle could be faster for development purposes as well as it implements the incremental compilation feature far better than Maven does. In fact, I almost never have to run "gradle clean", but "mvn clean" is a common necessity. On 5 May 2017 at 09:37, Ralph Goers

Re: Bogus GitHub repository

Quite likely since it's not on the list here: https://git.apache.org/ On 5 May 2017 at 10:47, Mikael Ståldal wrote: > Maybe they only deleted the Git repo at Apache? > > On Fri, May 5, 2017 at 4:08 PM, Matt Sicker wrote: > > > I could have sworn I

Re: Bogus GitHub repository

Maybe they only deleted the Git repo at Apache? On Fri, May 5, 2017 at 4:08 PM, Matt Sicker wrote: > I could have sworn I asked infra to delete that already. Guess we need a > new jira ticket for it. > > On 5 May 2017 at 08:33, Mikael Ståldal wrote:

Re: [Log4j] log4j-server

I don’t know that switching from Maven to Gradle or something else is going to solve anything. The issue isn’t Maven but how the release plugin works. If we could disable surefire during the actual release pass that would go a long way. Ralph > On May 5, 2017, at 7:33 AM, Matt Sicker

Re: [Log4j] log4j-server

I'd be open to using Gradle if it simplifies the build system in general and especially brings speed improvements. I mostly use Gradle at work (also starting to use SBT with Scala projects, but that remains to be seen if we'll switch back to Gradle or not), and it's been pretty fast there. As I've

Re: [Log4j] log4j-server

Then I think we agree. I am open to change build tool to e.g. Gradle if that makes things easier and faster for us. On Fri, May 5, 2017 at 2:53 PM, Remko Popma wrote: > I don't oppose breaking things up into modules, but I'm not sure that we > want to move modules into

Re: [Log4j] log4j-server

I don't oppose breaking things up into modules, but I'm not sure that we want to move modules into separate repos: I've seen this in practice at work and I worry we'll end up with a very complicated build. Are we open to the idea of using a different build tool that supports incremental