Re: [VOTE] Apache Jena 3.7.0 RC1

Please vote to approve this release:    [ ] +1 Approve the release    [ ]  0 Don't care    [ ] -1 Don't release, because ... +1 This vote will be open until at least    2018-04-01 22:00 UTC

[VOTE] Apache Jena 3.7.0 RC1

Hi, Here is a vote on a release of Jena 3.7.0. This is the first proposed candidate for a 3.7.0 release. There are process changes. Deadline: 2018-04-01 22:00 UTC April 1st! Process Changes 1/ MD5 files are being discouraged because MD5 is not secure. Projects are now asked

Re: Build 3.7.0

On 29/03/18 17:44, Claude Warren wrote: Fuseki was only adding Server header when SNAPSHOT was in the version? Yes. "is only" There was a suggestion/request for no "Server" (Jetty and Fuseki) which is a good practice apparently. Development builds do add one for Fuseki. Andy On

Re: Build 3.7.0

I see the logic here, but mightn't it be good to add some config for this to override it in certain settings? ajs6f > On Mar 29, 2018, at 1:06 PM, Rob Vesse wrote: > > Yeah it's a security think > > In production it is recommended not to include the Server header

Re: Build 3.7.0

Yeah it's a security think In production it is recommended not to include the Server header because it discloses the software you are running making you more easily targeted if vulnerabilities are known in specific servers Since most people will use stable releases for their production

Re: Build 3.7.0

Fuseki was only adding Server header when SNAPSHOT was in the version? On Thu, Mar 29, 2018 at 4:40 PM, Andy Seaborne wrote: > Security !!! > > The difference is that the version did not have "SNAPSHOT" in it > ... > which means Fuseki does not add a "Server:" header in

Re: Build 3.7.0

Security !!! The difference is that the version did not have "SNAPSHOT" in it ... which means Fuseki does not add a "Server:" header in responses ... and the "is it Fuseki?" test failed. Andy On 29/03/18 14:13, Andy Seaborne wrote: Could be last resort. In the release plugin, maven calls

Re: Build 3.7.0

Could be last resort. In the release plugin, maven calls maven recursively. And the integration tests are 5 minutes into the build after several modules. Andy On 29/03/18 14:01, Claude Warren wrote: A quick look at the maven script show that there is a MAVEN_DEBUG_OPTS environment

Re: Build 3.7.0

A quick look at the maven script show that there is a MAVEN_DEBUG_OPTS environment variable that it uses. You could cause the mvn startup to stop and wait for the eclipse debugger to attach to it. Not sure what you would be stopping on though after that. Claude On Thu, Mar 29, 2018 at 1:51 PM,

Re: Build 3.7.0

On 29/03/18 13:41, Claude Warren wrote: just to double check, do you start with a clean? mvn clean? Yes. Also started with a completely empty maven repo this morning. And I've rebooted the machine :-) Might be an issue with an older/newer version appearing somewhere. The release plugin

Re: Build 3.7.0

just to double check, do you start with a clean? Might be an issue with an older/newer version appearing somewhere. On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne wrote: > I've started to do the release. > > However, I've encountered a test failure that only happens with >

Build 3.7.0

I've started to do the release. However, I've encountered a test failure that only happens with "release:prepare". The -DdryRun=true is fine, and it has never occurred on Jenkins. What's more, it's an NPE and the line reported can't NPE line 57, TestRDFConnectionFusekiBinary.java which is :