You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2018/03/29 12:01:04 UTC
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 :
assertTrue(FusekiLib.isFuseki(dsURL));
no object access!
As it only when running the release for real, the only way to
investigate is changing master and the release plugin may demand that
changes are pushed to origin so there may be some commit-foo happening.
Andy
Re: Build 3.7.0
Posted by Andy Seaborne <an...@apache.org>.
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 Thu, Mar 29, 2018 at 4:40 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> 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 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 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, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>>
>>>>>
>>>>> 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 checks for SNAPSHOTS.
>>>>>
>>>>> So the dry/real difference is version numbers have been advanced.
>>>>> And I can't run this in the Eclipse debugger.
>>>>>
>>>>> Going old school with System.err.println. Bad memories.
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>> 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 :
>>>>>>>
>>>>>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>>>>>
>>>>>>> no object access!
>>>>>>>
>>>>>>> As it only when running the release for real, the only way to
>>>>>>> investigate
>>>>>>> is changing master and the release plugin may demand that changes are
>>>>>>> pushed to origin so there may be some commit-foo happening.
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
>
Re: Build 3.7.0
Posted by ajs6f <aj...@apache.org>.
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 <rv...@dotnetrdf.org> wrote:
>
> 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 environments this is the default behaviour when not using a development i.e. SNAPSHOT build
>
> Rob
>
> On 29/03/2018, 17:45, "Claude Warren" <cl...@xenei.com> wrote:
>
> Fuseki was only adding Server header when SNAPSHOT was in the version?
>
> On Thu, Mar 29, 2018 at 4:40 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> 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 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 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, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>>
>>>>>
>>>>> 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 checks for SNAPSHOTS.
>>>>>
>>>>> So the dry/real difference is version numbers have been advanced.
>>>>> And I can't run this in the Eclipse debugger.
>>>>>
>>>>> Going old school with System.err.println. Bad memories.
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>> 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 :
>>>>>>>
>>>>>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>>>>>
>>>>>>> no object access!
>>>>>>>
>>>>>>> As it only when running the release for real, the only way to
>>>>>>> investigate
>>>>>>> is changing master and the release plugin may demand that changes are
>>>>>>> pushed to origin so there may be some commit-foo happening.
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
>
>
>
Re: Build 3.7.0
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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 environments this is the default behaviour when not using a development i.e. SNAPSHOT build
Rob
On 29/03/2018, 17:45, "Claude Warren" <cl...@xenei.com> wrote:
Fuseki was only adding Server header when SNAPSHOT was in the version?
On Thu, Mar 29, 2018 at 4:40 PM, Andy Seaborne <an...@apache.org> wrote:
> 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 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 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, Andy Seaborne <an...@apache.org> wrote:
>>>
>>>
>>>>
>>>> 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 checks for SNAPSHOTS.
>>>>
>>>> So the dry/real difference is version numbers have been advanced.
>>>> And I can't run this in the Eclipse debugger.
>>>>
>>>> Going old school with System.err.println. Bad memories.
>>>>
>>>> Andy
>>>>
>>>>
>>>> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>>>
>>>>> 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 :
>>>>>>
>>>>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>>>>
>>>>>> no object access!
>>>>>>
>>>>>> As it only when running the release for real, the only way to
>>>>>> investigate
>>>>>> is changing master and the release plugin may demand that changes are
>>>>>> pushed to origin so there may be some commit-foo happening.
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Build 3.7.0
Posted by Claude Warren <cl...@xenei.com>.
Fuseki was only adding Server header when SNAPSHOT was in the version?
On Thu, Mar 29, 2018 at 4:40 PM, Andy Seaborne <an...@apache.org> wrote:
> 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 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 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, Andy Seaborne <an...@apache.org> wrote:
>>>
>>>
>>>>
>>>> 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 checks for SNAPSHOTS.
>>>>
>>>> So the dry/real difference is version numbers have been advanced.
>>>> And I can't run this in the Eclipse debugger.
>>>>
>>>> Going old school with System.err.println. Bad memories.
>>>>
>>>> Andy
>>>>
>>>>
>>>> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>>>
>>>>> 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 :
>>>>>>
>>>>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>>>>
>>>>>> no object access!
>>>>>>
>>>>>> As it only when running the release for real, the only way to
>>>>>> investigate
>>>>>> is changing master and the release plugin may demand that changes are
>>>>>> pushed to origin so there may be some commit-foo happening.
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Build 3.7.0
Posted by Andy Seaborne <an...@apache.org>.
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 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 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, Andy Seaborne <an...@apache.org> wrote:
>>
>>>
>>>
>>> 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 checks for SNAPSHOTS.
>>>
>>> So the dry/real difference is version numbers have been advanced.
>>> And I can't run this in the Eclipse debugger.
>>>
>>> Going old school with System.err.println. Bad memories.
>>>
>>> Andy
>>>
>>>
>>> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>> 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 :
>>>>>
>>>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>>>
>>>>> no object access!
>>>>>
>>>>> As it only when running the release for real, the only way to
>>>>> investigate
>>>>> is changing master and the release plugin may demand that changes are
>>>>> pushed to origin so there may be some commit-foo happening.
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
Re: Build 3.7.0
Posted by Andy Seaborne <an...@apache.org>.
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 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, Andy Seaborne <an...@apache.org> wrote:
>
>>
>>
>> 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 checks for SNAPSHOTS.
>>
>> So the dry/real difference is version numbers have been advanced.
>> And I can't run this in the Eclipse debugger.
>>
>> Going old school with System.err.println. Bad memories.
>>
>> Andy
>>
>>
>> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> 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 :
>>>>
>>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>>
>>>> no object access!
>>>>
>>>> As it only when running the release for real, the only way to investigate
>>>> is changing master and the release plugin may demand that changes are
>>>> pushed to origin so there may be some commit-foo happening.
>>>>
>>>> Andy
>>>>
>>>>
>>>
>>>
>>>
>
>
Re: Build 3.7.0
Posted by Claude Warren <cl...@xenei.com>.
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, Andy Seaborne <an...@apache.org> wrote:
>
>
> 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 checks for SNAPSHOTS.
>
> So the dry/real difference is version numbers have been advanced.
> And I can't run this in the Eclipse debugger.
>
> Going old school with System.err.println. Bad memories.
>
> Andy
>
>
> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>>
>> 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 :
>>>
>>> assertTrue(FusekiLib.isFuseki(dsURL));
>>>
>>> no object access!
>>>
>>> As it only when running the release for real, the only way to investigate
>>> is changing master and the release plugin may demand that changes are
>>> pushed to origin so there may be some commit-foo happening.
>>>
>>> Andy
>>>
>>>
>>
>>
>>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Build 3.7.0
Posted by Andy Seaborne <an...@apache.org>.
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 checks for SNAPSHOTS.
So the dry/real difference is version numbers have been advanced.
And I can't run this in the Eclipse debugger.
Going old school with System.err.println. Bad memories.
Andy
> On Thu, Mar 29, 2018 at 1:01 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> 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 :
>>
>> assertTrue(FusekiLib.isFuseki(dsURL));
>>
>> no object access!
>>
>> As it only when running the release for real, the only way to investigate
>> is changing master and the release plugin may demand that changes are
>> pushed to origin so there may be some commit-foo happening.
>>
>> Andy
>>
>
>
>
Re: Build 3.7.0
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> wrote:
> 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 :
>
> assertTrue(FusekiLib.isFuseki(dsURL));
>
> no object access!
>
> As it only when running the release for real, the only way to investigate
> is changing master and the release plugin may demand that changes are
> pushed to origin so there may be some commit-foo happening.
>
> Andy
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren