You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Ulrich Stärk <ul...@apache.org> on 2013/11/04 22:07:24 UTC
UIMA-SDK build tied to tapestry-only node in Jenkins
Hi UIMA devs,
the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
your build so as not to use that node.
Thanks,
Uli
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Richard Eckart de Castilho <re...@apache.org>.
Hello Uli,
actually, the UIMA-SDK build is tied to "ubuntu" already. I was recently trying to find a good
rule for binding builds, starting with not tying it at all, then adding exclusions for those slaves
where the build did not run. During that quest, at some point, a build was run on the tapestry VM,
which was actually very helpful, because it showed us that a bug he thought to have fixed long ago
hadn't been properly fixed at all. We fixed the issue again and a second build was run on the
tapestry VM after that to verify it had gone. After this, the job was tied again to "ubuntu"
(I just checked, it says "ubuntu" in the job configuration).
I am not sure why the tapestry slave was chosen when I started excluding certain nodes. The Jenkins
documentation at ASF says "If your build is not system-dependent (most simple Java builds, etc.)
you can leave your build untied to maximize the number of executors available for the build."
So I would assume, that certain reserved slaves are neither used when a job is not bound, nor
when it excludes specific nodes which are known to have issues (e.g. solaris1).
Sorry for the inconvenience. In any case, we did not have the intention of appropriating exclusive
slaves.
Best regards,
-- Richard
On 04.11.2013, at 22:07, Ulrich Stärk <ul...@apache.org> wrote:
> Hi UIMA devs,
>
> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
> your build so as not to use that node.
>
> Thanks,
>
> Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Richard Eckart de Castilho <re...@apache.org>.
Hello Uli,
actually, the UIMA-SDK build is tied to "ubuntu" already. I was recently trying to find a good
rule for binding builds, starting with not tying it at all, then adding exclusions for those slaves
where the build did not run. During that quest, at some point, a build was run on the tapestry VM,
which was actually very helpful, because it showed us that a bug he thought to have fixed long ago
hadn't been properly fixed at all. We fixed the issue again and a second build was run on the
tapestry VM after that to verify it had gone. After this, the job was tied again to "ubuntu"
(I just checked, it says "ubuntu" in the job configuration).
I am not sure why the tapestry slave was chosen when I started excluding certain nodes. The Jenkins
documentation at ASF says "If your build is not system-dependent (most simple Java builds, etc.)
you can leave your build untied to maximize the number of executors available for the build."
So I would assume, that certain reserved slaves are neither used when a job is not bound, nor
when it excludes specific nodes which are known to have issues (e.g. solaris1).
Sorry for the inconvenience. In any case, we did not have the intention of appropriating exclusive
slaves.
Best regards,
-- Richard
On 04.11.2013, at 22:07, Ulrich Stärk <ul...@apache.org> wrote:
> Hi UIMA devs,
>
> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
> your build so as not to use that node.
>
> Thanks,
>
> Uli
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Ulrich Stärk <ul...@apache.org>.
Hi Marshall,
as long as it doesn't interfere too much with the tapestry builds our sponsor should be fine with
you sharing the node. Just please don't tie it to the node indefinitely. If a build gets assigned to
the node by Jenkins' round-robin mechanism that's fine too.
Uli
On 2013-11-05 16:21, Marshall Schor wrote:
> Hi Uli,
>
> Sorry about that.
>
> We would like to continue to use it just a little bit longer, because it has a
> special property for our Jenkins build - it solidly reproduces a build failure
> that doesn't occur on other build platforms!
>
> The failure is caused, we think, by having a version of Java installed, that has
> a buggy version of XML XALAN installed... We're trying to figure out how to
> detect this case and work around this.
>
> It shouldn't take more than a few more days...
>
> -Marshall Schor
>
> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>> Hi UIMA devs,
>>
>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>> your build so as not to use that node.
>>
>> Thanks,
>>
>> Uli
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Ulrich Stärk <ul...@apache.org>.
Hi Marshall,
as long as it doesn't interfere too much with the tapestry builds our sponsor should be fine with
you sharing the node. Just please don't tie it to the node indefinitely. If a build gets assigned to
the node by Jenkins' round-robin mechanism that's fine too.
Uli
On 2013-11-05 16:21, Marshall Schor wrote:
> Hi Uli,
>
> Sorry about that.
>
> We would like to continue to use it just a little bit longer, because it has a
> special property for our Jenkins build - it solidly reproduces a build failure
> that doesn't occur on other build platforms!
>
> The failure is caused, we think, by having a version of Java installed, that has
> a buggy version of XML XALAN installed... We're trying to figure out how to
> detect this case and work around this.
>
> It shouldn't take more than a few more days...
>
> -Marshall Schor
>
> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>> Hi UIMA devs,
>>
>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>> your build so as not to use that node.
>>
>> Thanks,
>>
>> Uli
>>
>
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Richard Eckart de Castilho <re...@apache.org>.
Yeah, we should just let it be.
-- Richard
On 05.11.2013, at 22:41, Marshall Schor <ms...@schor.com> wrote:
>
> On 11/5/2013 3:25 PM, Richard Eckart de Castilho wrote:
>> Just to make sure we're on the same page here…
>>
>> with "latest checkout", you mean revision 1538773, right?
>> In that commit, you added bypassing code to XmiCasSerializerTest.
>> The error I get is, however, in XMLSerializerTest.
>>
>> I locally added you XML1_1_SUPPORTED in XMLSerializerTest, but that
>> doesn't work.
>>
>> It looks like you are checking the features of the XML parser,
>> but the problem appears to be in the XML/XSLT serializer (Xalan).
> Right, I was hoping they would be correlated...
>
> Thanks for testing... I'll probably not work on this further - too little value...
>
> -Marshall
>>
>> Skimming over the XML 1.1 patch for Xalan [1], I do not see a
>> portable way to query if XML 1.1 is supported.
>>
>> -- Richard
>>
>> [1] https://issues.apache.org/jira/browse/XALANJ-2070
>>
>>
>> On 05.11.2013, at 17:13, Marshall Schor <ms...@schor.com> wrote:
>>
>>> Hi,
>>>
>>> I committed another patch that tries to bypass the failing tests (for proper xml
>>> 1.1 operation) on those platforms where 1.1 xml isn't available.
>>>
>>> Can you rerun the test which had that failure, with the latest checkout (to see
>>> if the bypass works)?
>>>
>>> Thanks. -Marshall
>>>
>>> On 11/5/2013 10:41 AM, Richard Eckart de Castilho wrote:
>>>> Mind, that only the XML 1.1 thing appears to remain a problem, the issue
>>>> with the XML comments appears to be gone now.
>>>>
>>>> I think we can detect the issue on any platform by adding a dependency to
>>>> xalan:xalan:2.6.0 to the uimaj-core pom and running the uimaj-core tests.
>>>> That is, at least, how I can reproduce it locally on my Mac. If that
>>>> also works for you, we needn't use the tapestry slave again.
>>>>
>>>> It was just that on the tapestry slave, we accidentally stumbled over the fact
>>>> that the fix we did already have long ago had never been merged.
>>>>
>>>> -- Richard
>>>>
>>>> On 05.11.2013, at 16:21, Marshall Schor <ms...@schor.com> wrote:
>>>>
>>>>> Hi Uli,
>>>>>
>>>>> Sorry about that.
>>>>>
>>>>> We would like to continue to use it just a little bit longer, because it has a
>>>>> special property for our Jenkins build - it solidly reproduces a build failure
>>>>> that doesn't occur on other build platforms!
>>>>>
>>>>> The failure is caused, we think, by having a version of Java installed, that has
>>>>> a buggy version of XML XALAN installed... We're trying to figure out how to
>>>>> detect this case and work around this.
>>>>>
>>>>> It shouldn't take more than a few more days...
>>>>>
>>>>> -Marshall Schor
>>>>>
>>>>> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>>>>>> Hi UIMA devs,
>>>>>>
>>>>>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>>>>>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>>>>>> your build so as not to use that node.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Uli
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Marshall Schor <ms...@schor.com>.
On 11/5/2013 3:25 PM, Richard Eckart de Castilho wrote:
> Just to make sure we're on the same page here…
>
> with "latest checkout", you mean revision 1538773, right?
> In that commit, you added bypassing code to XmiCasSerializerTest.
> The error I get is, however, in XMLSerializerTest.
>
> I locally added you XML1_1_SUPPORTED in XMLSerializerTest, but that
> doesn't work.
>
> It looks like you are checking the features of the XML parser,
> but the problem appears to be in the XML/XSLT serializer (Xalan).
Right, I was hoping they would be correlated...
Thanks for testing... I'll probably not work on this further - too little value...
-Marshall
>
> Skimming over the XML 1.1 patch for Xalan [1], I do not see a
> portable way to query if XML 1.1 is supported.
>
> -- Richard
>
> [1] https://issues.apache.org/jira/browse/XALANJ-2070
>
>
> On 05.11.2013, at 17:13, Marshall Schor <ms...@schor.com> wrote:
>
>> Hi,
>>
>> I committed another patch that tries to bypass the failing tests (for proper xml
>> 1.1 operation) on those platforms where 1.1 xml isn't available.
>>
>> Can you rerun the test which had that failure, with the latest checkout (to see
>> if the bypass works)?
>>
>> Thanks. -Marshall
>>
>> On 11/5/2013 10:41 AM, Richard Eckart de Castilho wrote:
>>> Mind, that only the XML 1.1 thing appears to remain a problem, the issue
>>> with the XML comments appears to be gone now.
>>>
>>> I think we can detect the issue on any platform by adding a dependency to
>>> xalan:xalan:2.6.0 to the uimaj-core pom and running the uimaj-core tests.
>>> That is, at least, how I can reproduce it locally on my Mac. If that
>>> also works for you, we needn't use the tapestry slave again.
>>>
>>> It was just that on the tapestry slave, we accidentally stumbled over the fact
>>> that the fix we did already have long ago had never been merged.
>>>
>>> -- Richard
>>>
>>> On 05.11.2013, at 16:21, Marshall Schor <ms...@schor.com> wrote:
>>>
>>>> Hi Uli,
>>>>
>>>> Sorry about that.
>>>>
>>>> We would like to continue to use it just a little bit longer, because it has a
>>>> special property for our Jenkins build - it solidly reproduces a build failure
>>>> that doesn't occur on other build platforms!
>>>>
>>>> The failure is caused, we think, by having a version of Java installed, that has
>>>> a buggy version of XML XALAN installed... We're trying to figure out how to
>>>> detect this case and work around this.
>>>>
>>>> It shouldn't take more than a few more days...
>>>>
>>>> -Marshall Schor
>>>>
>>>> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>>>>> Hi UIMA devs,
>>>>>
>>>>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>>>>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>>>>> your build so as not to use that node.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Uli
>
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Richard Eckart de Castilho <re...@apache.org>.
Just to make sure we're on the same page here…
with "latest checkout", you mean revision 1538773, right?
In that commit, you added bypassing code to XmiCasSerializerTest.
The error I get is, however, in XMLSerializerTest.
I locally added you XML1_1_SUPPORTED in XMLSerializerTest, but that
doesn't work.
It looks like you are checking the features of the XML parser,
but the problem appears to be in the XML/XSLT serializer (Xalan).
Skimming over the XML 1.1 patch for Xalan [1], I do not see a
portable way to query if XML 1.1 is supported.
-- Richard
[1] https://issues.apache.org/jira/browse/XALANJ-2070
On 05.11.2013, at 17:13, Marshall Schor <ms...@schor.com> wrote:
> Hi,
>
> I committed another patch that tries to bypass the failing tests (for proper xml
> 1.1 operation) on those platforms where 1.1 xml isn't available.
>
> Can you rerun the test which had that failure, with the latest checkout (to see
> if the bypass works)?
>
> Thanks. -Marshall
>
> On 11/5/2013 10:41 AM, Richard Eckart de Castilho wrote:
>> Mind, that only the XML 1.1 thing appears to remain a problem, the issue
>> with the XML comments appears to be gone now.
>>
>> I think we can detect the issue on any platform by adding a dependency to
>> xalan:xalan:2.6.0 to the uimaj-core pom and running the uimaj-core tests.
>> That is, at least, how I can reproduce it locally on my Mac. If that
>> also works for you, we needn't use the tapestry slave again.
>>
>> It was just that on the tapestry slave, we accidentally stumbled over the fact
>> that the fix we did already have long ago had never been merged.
>>
>> -- Richard
>>
>> On 05.11.2013, at 16:21, Marshall Schor <ms...@schor.com> wrote:
>>
>>> Hi Uli,
>>>
>>> Sorry about that.
>>>
>>> We would like to continue to use it just a little bit longer, because it has a
>>> special property for our Jenkins build - it solidly reproduces a build failure
>>> that doesn't occur on other build platforms!
>>>
>>> The failure is caused, we think, by having a version of Java installed, that has
>>> a buggy version of XML XALAN installed... We're trying to figure out how to
>>> detect this case and work around this.
>>>
>>> It shouldn't take more than a few more days...
>>>
>>> -Marshall Schor
>>>
>>> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>>>> Hi UIMA devs,
>>>>
>>>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>>>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>>>> your build so as not to use that node.
>>>>
>>>> Thanks,
>>>>
>>>> Uli
>
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Marshall Schor <ms...@schor.com>.
Hi,
I committed another patch that tries to bypass the failing tests (for proper xml
1.1 operation) on those platforms where 1.1 xml isn't available.
Can you rerun the test which had that failure, with the latest checkout (to see
if the bypass works)?
Thanks. -Marshall
On 11/5/2013 10:41 AM, Richard Eckart de Castilho wrote:
> Mind, that only the XML 1.1 thing appears to remain a problem, the issue
> with the XML comments appears to be gone now.
>
> I think we can detect the issue on any platform by adding a dependency to
> xalan:xalan:2.6.0 to the uimaj-core pom and running the uimaj-core tests.
> That is, at least, how I can reproduce it locally on my Mac. If that
> also works for you, we needn't use the tapestry slave again.
>
> It was just that on the tapestry slave, we accidentally stumbled over the fact
> that the fix we did already have long ago had never been merged.
>
> -- Richard
>
> On 05.11.2013, at 16:21, Marshall Schor <ms...@schor.com> wrote:
>
>> Hi Uli,
>>
>> Sorry about that.
>>
>> We would like to continue to use it just a little bit longer, because it has a
>> special property for our Jenkins build - it solidly reproduces a build failure
>> that doesn't occur on other build platforms!
>>
>> The failure is caused, we think, by having a version of Java installed, that has
>> a buggy version of XML XALAN installed... We're trying to figure out how to
>> detect this case and work around this.
>>
>> It shouldn't take more than a few more days...
>>
>> -Marshall Schor
>>
>> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>>> Hi UIMA devs,
>>>
>>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>>> your build so as not to use that node.
>>>
>>> Thanks,
>>>
>>> Uli
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Richard Eckart de Castilho <re...@apache.org>.
Mind, that only the XML 1.1 thing appears to remain a problem, the issue
with the XML comments appears to be gone now.
I think we can detect the issue on any platform by adding a dependency to
xalan:xalan:2.6.0 to the uimaj-core pom and running the uimaj-core tests.
That is, at least, how I can reproduce it locally on my Mac. If that
also works for you, we needn't use the tapestry slave again.
It was just that on the tapestry slave, we accidentally stumbled over the fact
that the fix we did already have long ago had never been merged.
-- Richard
On 05.11.2013, at 16:21, Marshall Schor <ms...@schor.com> wrote:
> Hi Uli,
>
> Sorry about that.
>
> We would like to continue to use it just a little bit longer, because it has a
> special property for our Jenkins build - it solidly reproduces a build failure
> that doesn't occur on other build platforms!
>
> The failure is caused, we think, by having a version of Java installed, that has
> a buggy version of XML XALAN installed... We're trying to figure out how to
> detect this case and work around this.
>
> It shouldn't take more than a few more days...
>
> -Marshall Schor
>
> On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
>> Hi UIMA devs,
>>
>> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
>> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
>> your build so as not to use that node.
>>
>> Thanks,
>>
>> Uli
Re: UIMA-SDK build tied to tapestry-only node in Jenkins
Posted by Marshall Schor <ms...@schor.com>.
Hi Uli,
Sorry about that.
We would like to continue to use it just a little bit longer, because it has a
special property for our Jenkins build - it solidly reproduces a build failure
that doesn't occur on other build platforms!
The failure is caused, we think, by having a version of Java installed, that has
a buggy version of XML XALAN installed... We're trying to figure out how to
detect this case and work around this.
It shouldn't take more than a few more days...
-Marshall Schor
On 11/4/2013 4:07 PM, Ulrich Stärk wrote:
> Hi UIMA devs,
>
> the Tapestry project has a donated built host exclusively for Tapestry builds. It seems that despite
> the exclusiveness you are building UIMA builds on that node. I'd like to ask you to please configure
> your build so as not to use that node.
>
> Thanks,
>
> Uli
>