[jira] [Commented] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867391#comment-16867391
 ] 

Cao Manh Dat commented on SOLR-13549:
-

Thanks [~dancollins]

> Maven build fails to build Solr core tests due to missing dependency
> 
>
> Key: SOLR-13549
> URL: https://issues.apache.org/jira/browse/SOLR-13549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (9.0), 8.2
>Reporter: Daniel Collins
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> If I run
> ant get-maven-poms 
>  mvn -f maven-build/pom.xml install -DskipTests
> On master or branch_8x, it fails to build the Solr tests due to a dependency 
> on opentracing-mock.  Eclipse builds fine (because it uses a single classpath 
> with everything in it), and not entirely sure how ant builds...
> But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock 
> (though it has all the other opentracing modules)
> [https://github.com/apache/lucene-solr/pull/720] for the fix
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Daniel Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Collins resolved SOLR-13549.
---
   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

The patch was merged as part of SOLR-13434, so this is fixed.

> Maven build fails to build Solr core tests due to missing dependency
> 
>
> Key: SOLR-13549
> URL: https://issues.apache.org/jira/browse/SOLR-13549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (9.0), 8.2
>Reporter: Daniel Collins
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> If I run
> ant get-maven-poms 
>  mvn -f maven-build/pom.xml install -DskipTests
> On master or branch_8x, it fails to build the Solr tests due to a dependency 
> on opentracing-mock.  Eclipse builds fine (because it uses a single classpath 
> with everything in it), and not entirely sure how ant builds...
> But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock 
> (though it has all the other opentracing modules)
> [https://github.com/apache/lucene-solr/pull/720] for the fix
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864290#comment-16864290
 ] 

Steve Rowe commented on SOLR-13549:
---

See also 
https://issues.apache.org/jira/browse/SOLR-13434?focusedCommentId=16861794&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16861794

> Maven build fails to build Solr core tests due to missing dependency
> 
>
> Key: SOLR-13549
> URL: https://issues.apache.org/jira/browse/SOLR-13549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (9.0), 8.2
>Reporter: Daniel Collins
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If I run
> ant get-maven-poms 
>  mvn -f maven-build/pom.xml install -DskipTests
> On master or branch_8x, it fails to build the Solr tests due to a dependency 
> on opentracing-mock.  Eclipse builds fine (because it uses a single classpath 
> with everything in it), and not entirely sure how ant builds...
> But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock 
> (though it has all the other opentracing modules)
> [https://github.com/apache/lucene-solr/pull/720] for the fix
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Daniel Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Collins updated SOLR-13549:
--
Description: 
If I run

ant get-maven-poms 
 mvn -f maven-build/pom.xml install -DskipTests

On master or branch_8x, it fails to build the Solr tests due to a dependency on 
opentracing-mock.  Eclipse builds fine (because it uses a single classpath with 
everything in it), and not entirely sure how ant builds...

But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though 
it has all the other opentracing modules)

[https://github.com/apache/lucene-solr/pull/720] for the fix

 

  was:
If I run

ant get-maven-poms 
mvn -f maven-build/pom.xml install -DskipTests

On master or branch_8x, it fails to build the Solr tests due to a dependency on 
opentracing-mock.  Eclipse builds fine (because it uses a single classpath with 
everything in it), and not entirely sure how ant builds...

But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though 
it has all the other opentracing modules)

Will create a simple PR to add that dependency.

 


> Maven build fails to build Solr core tests due to missing dependency
> 
>
> Key: SOLR-13549
> URL: https://issues.apache.org/jira/browse/SOLR-13549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (9.0), 8.2
>Reporter: Daniel Collins
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If I run
> ant get-maven-poms 
>  mvn -f maven-build/pom.xml install -DskipTests
> On master or branch_8x, it fails to build the Solr tests due to a dependency 
> on opentracing-mock.  Eclipse builds fine (because it uses a single classpath 
> with everything in it), and not entirely sure how ant builds...
> But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock 
> (though it has all the other opentracing modules)
> [https://github.com/apache/lucene-solr/pull/720] for the fix
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Daniel Collins (JIRA)]

Daniel Collins created SOLR-13549:
-

 Summary: Maven build fails to build Solr core tests due to missing 
dependency
 Key: SOLR-13549
 URL: https://issues.apache.org/jira/browse/SOLR-13549
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: master (9.0), 8.2
Reporter: Daniel Collins


If I run

ant get-maven-poms 
mvn -f maven-build/pom.xml install -DskipTests

On master or branch_8x, it fails to build the Solr tests due to a dependency on 
opentracing-mock.  Eclipse builds fine (because it uses a single classpath with 
everything in it), and not entirely sure how ant builds...

But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though 
it has all the other opentracing modules)

Will create a simple PR to add that dependency.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

[Michael Braun (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425588#comment-16425588
 ] 

Michael Braun commented on LUCENE-8189:
---

Ant 1.10.3 has been released which includes the fix.

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382690#comment-16382690
 ] 

Uwe Schindler commented on LUCENE-8189:
---

There is already a check in common-build for a workaround. We can fail the same 
way.

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.Impo

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382679#comment-16382679
 ] 

Shawn Heisey commented on LUCENE-8189:
--

bq. add a check for the exact ANT version 

Good idea.  Have it check the versions of all relevant tools and fail with a 
helpful message if they are outside of the range that we consider acceptable.


> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTas

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382435#comment-16382435
 ] 

Uwe Schindler commented on LUCENE-8189:
---

As Adrien said, this is a well-known bug. We cannot work around it.

We might only add a check for the exact ANT version to our common-build.xml 
that fails early with a message "don't user ANT 1.10.2"

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.tas

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382418#comment-16382418
 ] 

Shawn Heisey commented on LUCENE-8189:
--

On a solr-user thread that prompted me to file this issue, [~erickoerickson] 
mentioned that 1.10.1 works.  So this might indeed be a bug in ant.  I only 
tried 1.10.2.

I hadn't gotten around to replying to the mailing list thread yet.


> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectH

[jira] [Resolved] (LUCENE-8189) Build fails with ant version 1.10.x

[Adrien Grand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand resolved LUCENE-8189.
--
Resolution: Invalid

Hello Shawn. This is an Ant bug indeed: 
http://markmail.org/message/wshnt7ok2rlvy5w7.

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
&g

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382393#comment-16382393
 ] 

Shawn Heisey commented on LUCENE-8189:
--

Looked for a previous issue on this, didn't find one.  If this is a duplicate, 
feel free to close as a duplicate.

Although it's always possible that this is a bug in Ant, that seems unlikely.  
Version 1.10 has been out for more than a year, and is on its third point 
release.


> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHel

[jira] [Created] (LUCENE-8189) Build fails with ant version 1.10.x

[Shawn Heisey (JIRA)]

Shawn Heisey created LUCENE-8189:


 Summary: Build fails with ant version 1.10.x
 Key: LUCENE-8189
 URL: https://issues.apache.org/jira/browse/LUCENE-8189
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Affects Versions: master (8.0)
Reporter: Shawn Heisey


Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
everything's fine.

{noformat}
C:\Users\sheisey\git\lucene-solr>ant clean
Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml

BUILD FAILED
C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
while executing this line:
C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
java.lang.NullPointerException
at java.util.Arrays.stream(Arrays.java:5004)
at java.util.stream.Stream.of(Stream.java:1000)
at 
java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at 
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
at 
java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at 
java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
at 
org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
at 
org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
at 
org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
at 
java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at 
java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
at 
org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
at 
org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:346)
at org.apache.tools.ant.Target.execute(Target.java:448)
at 
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
at 
org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:346)
at org.apache.tools.ant.Target.execute(Target.java:448)
at 
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:183)
at 
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper

[jira] [Updated] (LUCENE-6673) Maven build fails for target javadoc:jar

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-6673:
---
Summary: Maven build fails for target javadoc:jar  (was: Maven build fails 
for target javadoc:jar on trunk/Java8)

> Maven build fails for target javadoc:jar
> 
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 7.1, master (8.0)
>
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe resolved LUCENE-6673.

   Resolution: Fixed
Fix Version/s: master (8.0)
   7.1

Thanks Daniel and Ramkumar.

> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 7.1, master (8.0)
>
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187571#comment-16187571
 ] 

ASF subversion and git services commented on LUCENE-6673:
-

Commit 0062e999203fb6dbb7bd9d37e1c4a95cc2367504 in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0062e99 ]

LUCENE-6673: Maven build fails for target javadoc:jar.


> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187570#comment-16187570
 ] 

ASF subversion and git services commented on LUCENE-6673:
-

Commit 9c10d2ab176ef41f7380382ab16c81af3c7933d7 in lucene-solr's branch 
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9c10d2a ]

LUCENE-6673: Maven build fails for target javadoc:jar.


> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe reassigned LUCENE-6673:
--

Assignee: Steve Rowe  (was: Ramkumar Aiyengar)

> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[Daniel Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182148#comment-16182148
 ] 

Daniel Collins commented on LUCENE-6673:


Any blockers here?  Patch still holds, it matches the settings that 
common-build.xml uses (for ant).  We are trying to move to branch_7x and test 
on master, and without this we can't build javadocs (fails at the first hurdle 
of Lucene core)

> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855751#comment-15855751
 ] 

Uwe Schindler commented on LUCENE-7651:
---

We don't have access to recent paid only Java 7 JDKs, but as the Javadocs fix 
was declared a security issue, I assume that it is also applied to Java 7, so 
without this fix Java 7 paid updates will fail the build, too.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler]

Hi Adrien,

what do you think about this issue?
https://issues.apache.org/jira/browse/LUCENE-7651

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler (JIRA) [mailto:j...@apache.org]
> Sent: Tuesday, February 7, 2017 11:44 AM
> To: dev@lucene.apache.org
> Subject: [jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8
> update 121
> 
> 
> [ https://issues.apache.org/jira/browse/LUCENE-
> 7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=15855724#comment-15855724 ]
> 
> Uwe Schindler commented on LUCENE-7651:
> ---
> 
> I backported this change to Lucene 5.5.4, because otherwise we cannot run
> the build with Java 8 anymore. The problem is the following: Java 7's
> Javadocs do not add a "script.js" file to the Javadocs output, so this fix 
> injects
> the javadocs, but because a "script.js" is nowhere referenced in the HTML
> files, prettyprint is not loaded.
> 
> We have the following possibilities:
> - revert this backport commit, but it prevents smoketester from suceeding (as
> it checks also Java 8). It also makes it impossible to build the 5.5.4 release
> with Java 8
> - add more hacks to inject a script tag into the head element, but that's 
> really
> complicated as you have to do it in every HTML file!
> - ignore the fact that Javadocs do not code-prettyprint correctly anymore in
> Java 7. The Javadocs are fine, just the code exaples are no longer syntax
> highlighted.
> 
> I'd go for the third item. Any comments? If we go this route, I will add a
> comment to the Changelog that prettyprinting Javadocs is no longer working,
> if docs are build with Java 7.
> 
> > Javadocs build fails with Java 8 update 121
> > ---
> >
> > Key: LUCENE-7651
> > URL: https://issues.apache.org/jira/browse/LUCENE-7651
> > Project: Lucene - Core
> >  Issue Type: Bug
> >  Components: general/javadocs
> >Affects Versions: 6.4
> > Environment: Java 8 update 121
> >Reporter: Uwe Schindler
> >Assignee: Uwe Schindler
> >Priority: Critical
> >  Labels: Java8
> > Fix For: 6.x, master (7.0), 6.5, 6.4.1
> >
> > Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-
> 7651.patch, LUCENE-7651.patch
> >
> >
> > Oracle released the recent Java 8 security update (u121). The Jenkins builds
> fail with the following error while building the Javadocs:
> > {noformat}
> >   [javadoc] Constructing Javadoc information...
> >   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
> >   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
> >   [javadoc] 1 error
> > {noformat}
> > This is caused by the Javascript added to pretty-print code examples. We
> load this in the page footer "{{}}" parameter.
> > Surely, it will be posisble to simply add the mentioned argument, but this
> will break builds with earlier Java 8 versions.
> > This is nowhere documented, I haven't seen any documentation about this
> flag nowhere, so I assume this is a bug in Java. They can't change or add
> command line parameters in minor updates of Java 8. I will ask on the
> OpenJDK mailing lists if this is a bug (maybe accidentally backported from
> Java 9).
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855724#comment-15855724
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I backported this change to Lucene 5.5.4, because otherwise we cannot run the 
build with Java 8 anymore. The problem is the following: Java 7's Javadocs do 
not add a "script.js" file to the Javadocs output, so this fix injects the 
javadocs, but because a "script.js" is nowhere referenced in the HTML files, 
prettyprint is not loaded.

We have the following possibilities:
- revert this backport commit, but it prevents smoketester from suceeding (as 
it checks also Java 8). It also makes it impossible to build the 5.5.4 release 
with Java 8
- add more hacks to inject a script tag into the head element, but that's 
really complicated as you have to do it in every HTML file!
- ignore the fact that Javadocs do not code-prettyprint correctly anymore in 
Java 7. The Javadocs are fine, just the code exaples are no longer syntax 
highlighted.

I'd go for the third item. Any comments? If we go this route, I will add a 
comment to the Changelog that prettyprinting Javadocs is no longer working, if 
docs are build with Java 7.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855605#comment-15855605
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit cffa82062c5be766db6bc87bc232a39a413600ec in lucene-solr's branch 
refs/heads/branch_5_5 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cffa820 ]

LUCENE-7651: Fix Javadocs build for Java 8u121 by injecting "Google Code 
Prettify" without adding Javascript to Javadocs's -bottom parameter. Also 
update Prettify to latest version to fix Google Chrome issue.

# Conflicts:
#   lucene/CHANGES.txt


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854186#comment-15854186
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit 9dcfcb6e6fcbab36d50c4baca697c1104c2a72ff in lucene-solr's branch 
refs/heads/master from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9dcfcb6 ]

LUCENE-7651: Move under the 6.4.1 section.


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854184#comment-15854184
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit d3a2ed8487f3934d53f864b092f91966814d4cf7 in lucene-solr's branch 
refs/heads/branch_6x from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d3a2ed8 ]

LUCENE-7651: Move under the 6.4.1 section.


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833620#comment-15833620
 ] 

Uwe Schindler edited comment on LUCENE-7651 at 2/5/17 4:35 PM:
---

I committed this to master and branch_6x. I will now disable all 6.4 branch 
builds. If we will have a further bugfix release on this branch, we should 
backport this. Please reopen in that case.


was (Author: thetaphi):
I committed this to master and branch_5x. I will now disable all 6.4 branch 
builds. If we will have a further bugfix release on this branch, we should 
backport this. Please reopen in that case.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848332#comment-15848332
 ] 

Uwe Schindler commented on LUCENE-7651:
---

BTW, the release notes of Java 8u121 was updated to mention this change: 
http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html
It still breaks our previous releases, but we can tell people that its caused 
by Oracle, not us.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837757#comment-15837757
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit 680153de29c5b01d4a8afad88d4a7b84ab01e145 in lucene-solr's branch 
refs/heads/branch_6_4 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=680153d ]

LUCENE-7651: Fix Javadocs build for Java 8u121 by injecting "Google Code 
Prettify" without adding Javascript to Javadocs's -bottom parameter. Also 
update Prettify to latest version to fix Google Chrome issue.

# Conflicts:
#   lucene/CHANGES.txt


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Fix Version/s: 6.4.1

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Test passes, build fails with "Could not remove temporary path"

[Uwe Schindler]

Hi,

The problem is also the security manager and it's policy file. This is why we 
have the temp dir in current folder. As there is no easy way to have an 
absolute path in the policy file, we have it like this. Another way would be to 
pass a sys prop for the temp directory and add a policy file rule.

Uwe

Am 24. Januar 2017 12:06:12 MEZ schrieb Dawid Weiss :
>It's exactly that, actually. We place java.io.tmpdir under ./, so this
>directory always remains after the tests are done. I filed this issue:
>
>https://github.com/randomizedtesting/randomizedtesting/issues/247
>
>But I honestly don't know what the "right" way to fix it is. The
>runner assumes cwd should be left clean -- perhaps this should be a
>switch too (with similar wipe|ignore|warn options, defaulting to warn
>for backcompat).
>
>Note that LuceneTestCase already has leftover file detection facility
>it manages internally anyway (TestRuleTemporaryFilesCleanup).
>
>Dawid
>
>On Mon, Jan 23, 2017 at 7:22 PM, Dawid Weiss 
>wrote:
>> No problem at all. I wonder if we (in Lucene) don't point the temp
>> folder under cwd -- we probably do... If so then this is something I
>> didn't give much thought to... special case which should probably be
>> allowed. Check common-build and confirm if this is the case.
>>
>> Dawid
>>
>> On Mon, Jan 23, 2017 at 3:41 PM, David Smiley
> wrote:
>>> Thanks very much Dawid.  So indeed, the directory in question isn't
>quite
>>> empty; it contains a "temp" directory (that is empty).  Off to the
>next
>>> thing to debug
>>>
>>> Thanks again.
>>> ~ David
>>>
>>> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss 
>wrote:

 I've committed LUCENE-7653 which should help you diagnose the
>problem,
 David. First, it'll clean the cwd of a forked process before the
>tests
 start (something that wasn't done before). Second, it'll report
>what
 files remained uncleaned after a run.

 Hope it'll help.

 Dawid

 On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss
>
 wrote:
 > Hi David!
 >
 >> I can't find the string "Could not remove temporary path" in our
 >> codebase;
 >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how
>to
 >> debug
 >> this... maybe Solr wasn't closed properly?  Although this
>doesn't
 >> happen
 >
 > Yes, this message has a source in ANT's unit test runner code,
>here:
 >
 >
 >
>https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
 >
 > Specifically, it couldn't delete the temporary folder -- most
>likely
 > it wasn't empty (there were some files inside the folder). I
>think the
 > message here should be improved -- I'll do that -- but in the
>mean
 > time make sure the test's folder is empty; if it isn't, the build
>will
 > fail.
 >
 > Dawid
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Test passes, build fails with "Could not remove temporary path"

[David Smiley]

Check this out: (FYI this is my test; doesn't exist upstream yet):

> ant test -Dtestcase=HeatmapSpatialFieldTest
BUILD SUCCESSFUL, 1 minute 40 seconds
> ant test-core -Dtestcase=HeatmapSpatialFieldTest
BUILD FAILED, 25 seconds





So it turns out the "-init-totals" task sets up the temp dir along with a
deleteonexit.

Just to verify, I temporarily modified test-core to first invoke
"-init-totals", and it passed!  Perhaps all the test-* tasks should
simply have an "-init-totals" and "-check-totals" then?

~ David


On Tue, Jan 24, 2017 at 6:06 AM Dawid Weiss  wrote:

> It's exactly that, actually. We place java.io.tmpdir under ./, so this
> directory always remains after the tests are done. I filed this issue:
>
> https://github.com/randomizedtesting/randomizedtesting/issues/247
>
> But I honestly don't know what the "right" way to fix it is. The
> runner assumes cwd should be left clean -- perhaps this should be a
> switch too (with similar wipe|ignore|warn options, defaulting to warn
> for backcompat).
>
> Note that LuceneTestCase already has leftover file detection facility
> it manages internally anyway (TestRuleTemporaryFilesCleanup).
>
> Dawid
>
> On Mon, Jan 23, 2017 at 7:22 PM, Dawid Weiss 
> wrote:
> > No problem at all. I wonder if we (in Lucene) don't point the temp
> > folder under cwd -- we probably do... If so then this is something I
> > didn't give much thought to... special case which should probably be
> > allowed. Check common-build and confirm if this is the case.
> >
> > Dawid
> >
> > On Mon, Jan 23, 2017 at 3:41 PM, David Smiley 
> wrote:
> >> Thanks very much Dawid.  So indeed, the directory in question isn't
> quite
> >> empty; it contains a "temp" directory (that is empty).  Off to the next
> >> thing to debug
> >>
> >> Thanks again.
> >> ~ David
> >>
> >> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss 
> wrote:
> >>>
> >>> I've committed LUCENE-7653 which should help you diagnose the problem,
> >>> David. First, it'll clean the cwd of a forked process before the tests
> >>> start (something that wasn't done before). Second, it'll report what
> >>> files remained uncleaned after a run.
> >>>
> >>> Hope it'll help.
> >>>
> >>> Dawid
> >>>
> >>> On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss 
> >>> wrote:
> >>> > Hi David!
> >>> >
> >>> >> I can't find the string "Could not remove temporary path" in our
> >>> >> codebase;
> >>> >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to
> >>> >> debug
> >>> >> this... maybe Solr wasn't closed properly?  Although this doesn't
> >>> >> happen
> >>> >
> >>> > Yes, this message has a source in ANT's unit test runner code, here:
> >>> >
> >>> >
> >>> >
> https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
> >>> >
> >>> > Specifically, it couldn't delete the temporary folder -- most likely
> >>> > it wasn't empty (there were some files inside the folder). I think
> the
> >>> > message here should be improved -- I'll do that -- but in the mean
> >>> > time make sure the test's folder is empty; if it isn't, the build
> will
> >>> > fail.
> >>> >
> >>> > Dawid
> >>
> >> --
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> http://www.solrenterprisesearchserver.com
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Test passes, build fails with "Could not remove temporary path"

[Dawid Weiss]

It's exactly that, actually. We place java.io.tmpdir under ./, so this
directory always remains after the tests are done. I filed this issue:

https://github.com/randomizedtesting/randomizedtesting/issues/247

But I honestly don't know what the "right" way to fix it is. The
runner assumes cwd should be left clean -- perhaps this should be a
switch too (with similar wipe|ignore|warn options, defaulting to warn
for backcompat).

Note that LuceneTestCase already has leftover file detection facility
it manages internally anyway (TestRuleTemporaryFilesCleanup).

Dawid

On Mon, Jan 23, 2017 at 7:22 PM, Dawid Weiss  wrote:
> No problem at all. I wonder if we (in Lucene) don't point the temp
> folder under cwd -- we probably do... If so then this is something I
> didn't give much thought to... special case which should probably be
> allowed. Check common-build and confirm if this is the case.
>
> Dawid
>
> On Mon, Jan 23, 2017 at 3:41 PM, David Smiley  
> wrote:
>> Thanks very much Dawid.  So indeed, the directory in question isn't quite
>> empty; it contains a "temp" directory (that is empty).  Off to the next
>> thing to debug
>>
>> Thanks again.
>> ~ David
>>
>> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss  wrote:
>>>
>>> I've committed LUCENE-7653 which should help you diagnose the problem,
>>> David. First, it'll clean the cwd of a forked process before the tests
>>> start (something that wasn't done before). Second, it'll report what
>>> files remained uncleaned after a run.
>>>
>>> Hope it'll help.
>>>
>>> Dawid
>>>
>>> On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss 
>>> wrote:
>>> > Hi David!
>>> >
>>> >> I can't find the string "Could not remove temporary path" in our
>>> >> codebase;
>>> >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to
>>> >> debug
>>> >> this... maybe Solr wasn't closed properly?  Although this doesn't
>>> >> happen
>>> >
>>> > Yes, this message has a source in ANT's unit test runner code, here:
>>> >
>>> >
>>> > https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
>>> >
>>> > Specifically, it couldn't delete the temporary folder -- most likely
>>> > it wasn't empty (there were some files inside the folder). I think the
>>> > message here should be improved -- I'll do that -- but in the mean
>>> > time make sure the test's folder is empty; if it isn't, the build will
>>> > fail.
>>> >
>>> > Dawid
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Test passes, build fails with "Could not remove temporary path"

[Dawid Weiss]

No problem at all. I wonder if we (in Lucene) don't point the temp
folder under cwd -- we probably do... If so then this is something I
didn't give much thought to... special case which should probably be
allowed. Check common-build and confirm if this is the case.

Dawid

On Mon, Jan 23, 2017 at 3:41 PM, David Smiley  wrote:
> Thanks very much Dawid.  So indeed, the directory in question isn't quite
> empty; it contains a "temp" directory (that is empty).  Off to the next
> thing to debug
>
> Thanks again.
> ~ David
>
> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss  wrote:
>>
>> I've committed LUCENE-7653 which should help you diagnose the problem,
>> David. First, it'll clean the cwd of a forked process before the tests
>> start (something that wasn't done before). Second, it'll report what
>> files remained uncleaned after a run.
>>
>> Hope it'll help.
>>
>> Dawid
>>
>> On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss 
>> wrote:
>> > Hi David!
>> >
>> >> I can't find the string "Could not remove temporary path" in our
>> >> codebase;
>> >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to
>> >> debug
>> >> this... maybe Solr wasn't closed properly?  Although this doesn't
>> >> happen
>> >
>> > Yes, this message has a source in ANT's unit test runner code, here:
>> >
>> >
>> > https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
>> >
>> > Specifically, it couldn't delete the temporary folder -- most likely
>> > it wasn't empty (there were some files inside the folder). I think the
>> > message here should be improved -- I'll do that -- but in the mean
>> > time make sure the test's folder is empty; if it isn't, the build will
>> > fail.
>> >
>> > Dawid
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Test passes, build fails with "Could not remove temporary path"

[David Smiley]

Thanks very much Dawid.  So indeed, the directory in question isn't quite
empty; it contains a "temp" directory (that is empty).  Off to the next
thing to debug

Thanks again.
~ David

On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss  wrote:

> I've committed LUCENE-7653 which should help you diagnose the problem,
> David. First, it'll clean the cwd of a forked process before the tests
> start (something that wasn't done before). Second, it'll report what
> files remained uncleaned after a run.
>
> Hope it'll help.
>
> Dawid
>
> On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss 
> wrote:
> > Hi David!
> >
> >> I can't find the string "Could not remove temporary path" in our
> codebase;
> >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to debug
> >> this... maybe Solr wasn't closed properly?  Although this doesn't happen
> >
> > Yes, this message has a source in ANT's unit test runner code, here:
> >
> >
> https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
> >
> > Specifically, it couldn't delete the temporary folder -- most likely
> > it wasn't empty (there were some files inside the folder). I think the
> > message here should be improved -- I'll do that -- but in the mean
> > time make sure the test's folder is empty; if it isn't, the build will
> > fail.
> >
> > Dawid
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Test passes, build fails with "Could not remove temporary path"

[Dawid Weiss]

I've committed LUCENE-7653 which should help you diagnose the problem,
David. First, it'll clean the cwd of a forked process before the tests
start (something that wasn't done before). Second, it'll report what
files remained uncleaned after a run.

Hope it'll help.

Dawid

On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss  wrote:
> Hi David!
>
>> I can't find the string "Could not remove temporary path" in our codebase;
>> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to debug
>> this... maybe Solr wasn't closed properly?  Although this doesn't happen
>
> Yes, this message has a source in ANT's unit test runner code, here:
>
> https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
>
> Specifically, it couldn't delete the temporary folder -- most likely
> it wasn't empty (there were some files inside the folder). I think the
> message here should be improved -- I'll do that -- but in the mean
> time make sure the test's folder is empty; if it isn't, the build will
> fail.
>
> Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-7651.
---
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)
   6.x

Fixed for now, please reopen for every bugfix release on any branch that was 
not yet updated to use this.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833620#comment-15833620
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I committed this to master and branch_5x. I will now disable all 6.4 branch 
builds. If we will have a further bugfix release on this branch, we should 
backport this. Please reopen in that case.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833619#comment-15833619
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit b808ee6099d03d1fdbccd5a17720069d74d0b8a4 in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b808ee6 ]

LUCENE-7651: Fix Javadocs build for Java 8u121 by injecting "Google Code 
Prettify" without adding Javascript to Javadocs's -bottom parameter. Also 
update Prettify to latest version to fix Google Chrome issue.


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833617#comment-15833617
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit ee5a36011220bd2a7a8e45de27d5321cc7610bff in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee5a360 ]

LUCENE-7651: Fix Javadocs build for Java 8u121 by injecting "Google Code 
Prettify" without adding Javascript to Javadocs's -bottom parameter. Also 
update Prettify to latest version to fix Google Chrome issue.


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833484#comment-15833484
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I sent the following message to OpenJDK: 
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833480#comment-15833480
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I just checked. The "hack" also works with IBM J9, so I see no problem doing 
this. I was afraid that maybe IBM does not have script.js in the Javadoc output.

Nevertheless, this is not risky like the previous hack. If the Javadocs 
generator no longer produces script.js or stylesheet.css the Code Prettify 
would just no longer work, but not break Javadocs or build.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Add correct license header to CSS file.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Final updates, I think this is committable.

Any suggestions?

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Attached is a patch that also updates Prettify to latest version. The used one 
produced Javascript errors in Chrome, so I updated. I also removed the useless 
additional language plugin files.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833424#comment-15833424
 ] 

Uwe Schindler edited comment on LUCENE-7651 at 1/22/17 9:50 AM:


This would be my proposal.


was (Author: thetaphi):
This would be my proposal. Unfortunately, Prettify never worked from local 
filesystem, so I have to quicly spawn a webserver here...

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: (was: LUCENE-7651.patch)

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Sorry last patch had a missing pair of brackets. This fixes it any also works 
locally. Stupid Javascript! K!

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

This would be my proposal. Unfortunately, Prettify never worked from local 
filesystem, so I have to quicly spawn a webserver here...

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833417#comment-15833417
 ] 

Uwe Schindler commented on LUCENE-7651:
---

This implements first option:

{noformat}
 lucene/common-build.xml | 14 --
 1 file changed, 14 deletions(-)

diff --git a/lucene/common-build.xml b/lucene/common-build.xml
index 48cf457..61948bb 100644
--- a/lucene/common-build.xml
+++ b/lucene/common-build.xml
@@ -2107,20 +2107,6 @@ 
${ant.project.name}.test.dependencies=${test.classpath.list}
 
 
 
 
{noformat}

I checked our sources. We allready append the CSS of prettify to Javadocs's 
main CSS files. As Java 8 contains also a Javadocs-generated scripts.js file, 
we could do the same here. I am working on that...

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833412#comment-15833412
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I checked it out, it disallows any {{

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Labels: Java8  (was: )

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Affects Version/s: 6.4

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned LUCENE-7651:
-

Assignee: Uwe Schindler

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833398#comment-15833398
 ] 

Uwe Schindler edited comment on LUCENE-7651 at 1/22/17 9:19 AM:


I set to "critical", because this also breaks our latest release 6.4, which 
can't be build from source with Java 8 update 121.


was (Author: thetaphi):
I se to "critical", because this also breaks our latest release 6.4, which 
can't be build from source with Java 8 update 121.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833399#comment-15833399
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I will try to figure out if moving the Javascript to a separate file helps 
here. In HTML 5 inline Javascript in HTML files is a no-go.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833398#comment-15833398
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I se to "critical", because this also breaks our latest release 6.4, which 
can't be build from source with Java 8 update 121.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

Uwe Schindler created LUCENE-7651:
-

 Summary: Javadocs build fails with Java 8 update 121
 Key: LUCENE-7651
 URL: https://issues.apache.org/jira/browse/LUCENE-7651
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/javadocs
 Environment: Java 8 update 121
Reporter: Uwe Schindler
Priority: Critical


Oracle released the recent Java 8 security update (u121). The Jenkins builds 
fail with the following error while building the Javadocs:

{noformat}
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
  [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
  [javadoc] 1 error
{noformat}

This is caused by the Javascript added to pretty-print code examples. We load 
this in the page footer "{{}}" parameter.

Surely, it will be posisble to simply add the mentioned argument, but this will 
break builds with earlier Java 8 versions.

This is nowhere documented, I haven't seen any documentation about this flag 
nowhere, so I assume this is a bug in Java. They can't change or add command 
line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Test passes, build fails with "Could not remove temporary path"

[Dawid Weiss]

Hi David!

> I can't find the string "Could not remove temporary path" in our codebase;
> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to debug
> this... maybe Solr wasn't closed properly?  Although this doesn't happen

Yes, this message has a source in ANT's unit test runner code, here:

https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041

Specifically, it couldn't delete the temporary folder -- most likely
it wasn't empty (there were some files inside the folder). I think the
message here should be improved -- I'll do that -- but in the mean
time make sure the test's folder is empty; if it isn't, the build will
fail.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Test passes, build fails with "Could not remove temporary path"

[David Smiley]

I wrote a test in Solr extending SolrTestCaseJ4 that sets up Solr a bit
differently than some tests.  Essentially instead of writing yet another
test schema.xml file, I decided to use some stock configs that are already
in a managed-schema mode that allow me to manipulate the schema via test
code -- but not persist it since I don't want/need that.  I could share the
code if it helps.  Any way, my test passes when run via IntelliJ; the test
JVM ends normally.

But when I run via "ant test-core -Dtestcase=mytestclassname" the test
itself passes but the build fails.  Right before the "5 slowest tests"
printout is the following curious message:

Could not remove temporary path:
/SmileyDev/Search/lucene-solr_6x/solr/build/solr-core/test/J0
(/SmileyDev/Search/lucene-solr_6x/solr/build/solr-core/test/J0)

I can't find the string "Could not remove temporary path" in our codebase;
maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to debug
this... maybe Solr wasn't closed properly?  Although this doesn't happen
when run via IntelliJ; maybe there's a race.

Here's my @BeforeClass:

@BeforeClass
private static void initManagedSchemaCore() throws Exception {
  // This testing approach means no new solrconfig or schema file or
per-test temp solr-home!
  System.setProperty("managed.schema.mutable", "true");
  System.setProperty("managed.schema.resourceName",
"schema-one-field-no-dynamic-field-unique-key.xml");
  System.setProperty("enable.update.log", "false");
  initCore("solrconfig-managed-schema.xml", "ignoredSchemaName?");

  IndexSchema oldSchema = h.getCore().getLatestSchema();

  HeatmapSpatialField fieldType = new HeatmapSpatialField();
  Map ftInitMap = new HashMap<>();
  ftInitMap.put("prefixTree", "packedQuad");
  ftInitMap.put("square", "true");
  ftInitMap.put("minDistErr", "1000");
  ftInitMap.put("maxDistErr", "50");
  ftInitMap.put("distanceUnits", "kilometers");
  fieldType.init(oldSchema, ftInitMap);
  fieldType.setTypeName("heatmapType");
  SchemaField schemaField = new SchemaField(HM_FLD, fieldType,
SchemaField.STORED | SchemaField.INDEXED, null);
  boolean persist = false; // don't write to test resource dir
  IndexSchema newSchema = oldSchema.addField(schemaField, persist);

  h.getCore().setLatestSchema(newSchema);

  strategy = fieldType.getStrategy(schemaField.getName());
  ctx = strategy.getSpatialContext();
}


Or maybe most of that info is a red herring and the problem is something
else.  Any way, it'd be nice if someone else who ran into this problem
before could share some advice.

Thanks in advance,
~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[Daniel Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715106#comment-15715106
 ] 

Daniel Collins commented on LUCENE-6673:


We had patched this locally on our 4.8 branch (with the added complication that 
in Java 7 this flag isn't needed).  Getting back to trunk, this still applies, 
any thoughts on this being applied?

> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[Ramkumar Aiyengar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramkumar Aiyengar updated LUCENE-6673:
--
Attachment: LUCENE-6673.patch

I am not Maven expert, but this seems to fix it. If there are no objections, 
will go ahead and commit it..

> Maven build fails for target javadoc:jar on trunk/Java8
> ---
>
> Key: LUCENE-6673
> URL: https://issues.apache.org/jira/browse/LUCENE-6673
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Daniel Collins
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Attachments: LUCENE-6673.patch
>
>
> We currently disable missing checks for doclint, but the maven poms don't 
> have it, as a result javadoc:jar fails.
> (thanks to [~dancollins] for spotting this)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-6673) Maven build fails for target javadoc:jar on trunk/Java8

[Ramkumar Aiyengar (JIRA)]

Ramkumar Aiyengar created LUCENE-6673:
-

 Summary: Maven build fails for target javadoc:jar on trunk/Java8
 Key: LUCENE-6673
 URL: https://issues.apache.org/jira/browse/LUCENE-6673
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Reporter: Daniel Collins
Assignee: Ramkumar Aiyengar
Priority: Minor


We currently disable missing checks for doclint, but the maven poms don't have 
it, as a result javadoc:jar fails.

(thanks to [~dancollins] for spotting this)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr 5 build fails - who do I tell?

[Chris Hostetter]

: Please provide the details of the errors you’re seeing, and any relevant 
: environmental details - that would have been higher impact than not 
: providing details :)

when in doubt: file a jira, attach all the details.


-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr 5 build fails - who do I tell?

[Erick Erickson]

Do note, though, that this should be fixed very quickly if it happens.
There'll be all sorts of messages here on the dev list about build failures
and someone usually notices/fixes ASAP.

On Sun, Jan 4, 2015 at 9:51 AM, Erik Hatcher  wrote:

> Alex - in general, I think you did the right thing by e-mailing here.
> However, you could also ping in the #lucene-dev IRC channel if you wanted
> more real-time attention.
>
> Please provide the details of the errors you’re seeing, and any relevant
> environmental details - that would have been higher impact than not
> providing details :)
>
> Erik
>
>
> > On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch 
> wrote:
> >
> > Hi,
> >
> > I did a checkout of the latest 5.0 and the build fails (with ant clean
> > package). With errors from two different JIRAs ports it seems.
> >
> > Should I provide the feedback or do I assume that the Jenkins builds
> > catch this? I can see the build fails, but does not seem to be where
> > mine is? Does it exercise the same build path?
> >
> > If I do need to contact somebody, do I just ping this mailing list or
> > should I notify the JIRAs that I think caused this? Or both?
> >
> > What's the minimum noise + highest impact strategy here?
> >
> > Thanks,
> >   Alex.
> > 
> > Sign up for my Solr resources newsletter at http://www.solr-start.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Solr 5 build fails - who do I tell?

[Erik Hatcher]

Alex - in general, I think you did the right thing by e-mailing here.  However, 
you could also ping in the #lucene-dev IRC channel if you wanted more real-time 
attention.

Please provide the details of the errors you’re seeing, and any relevant 
environmental details - that would have been higher impact than not providing 
details :)

Erik


> On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch  wrote:
> 
> Hi,
> 
> I did a checkout of the latest 5.0 and the build fails (with ant clean
> package). With errors from two different JIRAs ports it seems.
> 
> Should I provide the feedback or do I assume that the Jenkins builds
> catch this? I can see the build fails, but does not seem to be where
> mine is? Does it exercise the same build path?
> 
> If I do need to contact somebody, do I just ping this mailing list or
> should I notify the JIRAs that I think caused this? Or both?
> 
> What's the minimum noise + highest impact strategy here?
> 
> Thanks,
>   Alex.
> 
> Sign up for my Solr resources newsletter at http://www.solr-start.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr 5 build fails - who do I tell?

[Alexandre Rafalovitch]

Yeah,

I must have been caught in between the commits or something. 30
minutes later, everything built.

But I think the question is still valid for the next time somebody
hits the problem, assuming it stays there after another hour or
whatever.

Regards,
   Alex.

Sign up for my Solr resources newsletter at http://www.solr-start.com/


On 4 January 2015 at 12:43, Erik Hatcher  wrote:
> I just ran (cd solr; ant clean package) on a clean 5x checkout:
>
>   BUILD SUCCESSFUL
>   Total time: 6 minutes 15 seconds
>
> Mac OS X 10.10.1
>
> $ ant -version
> Apache Ant(TM) version 1.9.4 compiled on April 29 2014
>
> $ java -version
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>
>
>> On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch  
>> wrote:
>>
>> Hi,
>>
>> I did a checkout of the latest 5.0 and the build fails (with ant clean
>> package). With errors from two different JIRAs ports it seems.
>>
>> Should I provide the feedback or do I assume that the Jenkins builds
>> catch this? I can see the build fails, but does not seem to be where
>> mine is? Does it exercise the same build path?
>>
>> If I do need to contact somebody, do I just ping this mailing list or
>> should I notify the JIRAs that I think caused this? Or both?
>>
>> What's the minimum noise + highest impact strategy here?
>>
>> Thanks,
>>   Alex.
>> 
>> Sign up for my Solr resources newsletter at http://www.solr-start.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr 5 build fails - who do I tell?

[Erik Hatcher]

I just ran (cd solr; ant clean package) on a clean 5x checkout:

  BUILD SUCCESSFUL
  Total time: 6 minutes 15 seconds

Mac OS X 10.10.1

$ ant -version
Apache Ant(TM) version 1.9.4 compiled on April 29 2014

$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)


> On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch  wrote:
> 
> Hi,
> 
> I did a checkout of the latest 5.0 and the build fails (with ant clean
> package). With errors from two different JIRAs ports it seems.
> 
> Should I provide the feedback or do I assume that the Jenkins builds
> catch this? I can see the build fails, but does not seem to be where
> mine is? Does it exercise the same build path?
> 
> If I do need to contact somebody, do I just ping this mailing list or
> should I notify the JIRAs that I think caused this? Or both?
> 
> What's the minimum noise + highest impact strategy here?
> 
> Thanks,
>   Alex.
> 
> Sign up for my Solr resources newsletter at http://www.solr-start.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Solr 5 build fails - who do I tell?

[Alexandre Rafalovitch]

Hi,

I did a checkout of the latest 5.0 and the build fails (with ant clean
package). With errors from two different JIRAs ports it seems.

Should I provide the feedback or do I assume that the Jenkins builds
catch this? I can see the build fails, but does not seem to be where
mine is? Does it exercise the same build path?

If I do need to contact somebody, do I just ping this mailing list or
should I notify the JIRAs that I think caused this? Or both?

What's the minimum noise + highest impact strategy here?

Thanks,
   Alex.

Sign up for my Solr resources newsletter at http://www.solr-start.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: JCC build fails on Mac OS X Mavericks

[Andi Vajda]

> On Mar 12, 2014, at 4:44, Peter Ganong  wrote:
> 
> Hi,
> 
> I'm having trouble installing JCC. I don't know if this is the right forum,
> but I figured I would post here, since
> thispage said
> this was the list to post build issues.
> 
> I'm trying to install JCC as a first step to installing PyLucene. I've
> installed JDK 1.7, Python 2.7, Python 3.3, XCode, XCode Command Line Tools
> and setuptools 3.1. I've pasted the error I'm getting below.
> 
> Thanks,
> 
> Peter
> 
> Macintosh-58:jcc ganong$ python setup.py build
> 
> found JAVAHOME =
> /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
> 
> found JAVAFRAMEWORKS = /System/Library/Frameworks/JavaVM.framework
> 
> Loading source files for package org.apache.jcc...
> 
> Constructing Javadoc information...
> 
> Standard Doclet version 1.7.0_51
> 
> Building tree for all the packages and classes...
> 
> Generating javadoc/org/apache/jcc/PythonException.html...
> 
> Generating javadoc/org/apache/jcc/PythonVM.html...
> 
> Generating javadoc/org/apache/jcc/package-frame.html...
> 
> Generating javadoc/org/apache/jcc/package-summary.html...
> 
> Generating javadoc/org/apache/jcc/package-tree.html...
> 
> Generating javadoc/constant-values.html...
> 
> Generating javadoc/serialized-form.html...
> 
> Building index for all the packages and classes...
> 
> Generating javadoc/overview-tree.html...
> 
> Generating javadoc/index-all.html...
> 
> Generating javadoc/deprecated-list.html...
> 
> Building index for all classes...
> 
> Generating javadoc/allclasses-frame.html...
> 
> Generating javadoc/allclasses-noframe.html...
> 
> Generating javadoc/index.html...
> 
> Generating javadoc/help-doc.html...
> 
> running build
> 
> running build_py
> 
> writing /Users/ganong/Downloads/pylucene-4.6.1-1/jcc/jcc/config.py
> 
> copying jcc/config.py -> build/lib.macosx-10.9-intel-2.7/jcc
> 
> copying jcc/classes/org/apache/jcc/PythonVM.class ->
> build/lib.macosx-10.9-intel-2.7/jcc/classes/org/apache/jcc
> 
> copying jcc/classes/org/apache/jcc/PythonException.class ->
> build/lib.macosx-10.9-intel-2.7/jcc/classes/org/apache/jcc
> 
> running build_ext
> 
> building 'jcc' extension
> 
> cc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -arch i386 -g -Os
> -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd
> -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes
> -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes
> -DENABLE_DTRACE -dynamiclib -D_jcc_lib -DJCC_VER="2.19"
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/include
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/include/darwin
> -I_jcc -Ijcc/sources
> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
> -c jcc/sources/jcc.cpp -o
> build/temp.macosx-10.9-intel-2.7/jcc/sources/jcc.o -DPYTHON
> -fno-strict-aliasing -Wno-write-strings
> 
> clang: error: unknown argument: '-mno-fused-madd'
> [-Wunused-command-line-argument-hard-error-in-future]

The wrong compiler flag here is produced by Python based on the compiler 
knowledge it gained while it was built. In other words, you must use the same 
compiler for building JCC than the one used to build your python VM.
The easiest way to ensure that is to build python 2.7 from sources yourself.

Andi..

> 
> clang: note: this will be a hard error (cannot be downgraded to a warning)
> in the future
> 
> error: command 'cc' failed with exit status 1
> 
> -- 
> Peter Ganong
> PhD Candidate in Economics at Harvard
> scholar.harvard.edu/ganong/

build fails

[Noble Paul നോബിള്‍ नोब्ळ्]

is it just me?

BUILD FAILED
C:\work\lucene_dev_fresh\build.xml:23: The following error occurred while execut
ing this line:
C:\work\lucene_dev_fresh\solr\build.xml:135: The following error occurred while
executing this line:
C:\work\lucene_dev_fresh\solr\core\build.xml:21: The following error occurred wh
ile executing this line:
C:\work\lucene_dev_fresh\solr\common-build.xml:67: C:\work\lucene_dev_fresh\solr
\core\lib not found.

-- 
-
Noble Paul

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: solr build fails with java 1.5

[Uwe Schindler]

Even the 3.x branch will compile with Java 5. Only trunk not.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: abhayd [mailto:ajdabhol...@hotmail.com]
> Sent: Saturday, October 23, 2010 6:17 PM
> To: solr-...@lucene.apache.org
> Subject: Re: solr build fails with java 1.5
> 
> 
> hi yonik,
> Thanks for reply, I totally understand this.
> 
> But our prod systems are not going to be on 6 for a year or so.
> 
> We have solr 1.3 currently and wanted to have suggester component so I was
> trying to do upgrade and get suggester component.
> 
> If i take SOLR 1.3 branch ( it seems to have suggester component) will it
> compile with 1.5?
> --
> View this message in context:
http://lucene.472066.n3.nabble.com/solr-build-
> fails-with-java-1-5-tp1756553p1758724.html
> Sent from the Solr - Dev mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: solr build fails with java 1.5

[abhayd]

hi yonik,
Thanks for reply, I totally understand this. 

But our prod systems are not going to be on 6 for a year or so. 

We have solr 1.3 currently and wanted to have suggester component so I was
trying to do upgrade and get suggester component.

If i take SOLR 1.3 branch ( it seems to have suggester component) will it
compile with 1.5?
-- 
View this message in context: 
http://lucene.472066.n3.nabble.com/solr-build-fails-with-java-1-5-tp1756553p1758724.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: solr build fails with java 1.5

[Yonik Seeley]

Solr trunk (4.0-dev) requires Java6, as does zookeeper, a new Solr dependency.
Not much we can do about it.
Java6 has been out for almost 4 years now though, so it's not an
unrealistic requirement either.

-Yonik
http://www.lucidimagination.com

On Sat, Oct 23, 2010 at 2:13 AM, abhayd  wrote:
>
> hi
> i downloaded solr trunk and was trying to build using jdk 1.5.
>
> I keep getting error
>     [echo] Java Runtime Environment          version: 1.5.0_22
>    [javac] Compiling 1 source file to
> C:\search\workspace\solr\solr\build\solr
>    [javac] javac: invalid target release: 1.6
>
> I am using eclipse
>
> I can compile with 1.6 fine, but our production is at 1.5.
>
> Any thoughts?
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/solr-build-fails-with-java-1-5-tp1756553p1756553.html
> Sent from the Solr - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

solr build fails with java 1.5

[abhayd]

hi 
i downloaded solr trunk and was trying to build using jdk 1.5. 

I keep getting error
 [echo] Java Runtime Environment  version: 1.5.0_22
[javac] Compiling 1 source file to
C:\search\workspace\solr\solr\build\solr
[javac] javac: invalid target release: 1.6

I am using eclipse

I can compile with 1.6 fine, but our production is at 1.5.

Any thoughts?
-- 
View this message in context: 
http://lucene.472066.n3.nabble.com/solr-build-fails-with-java-1-5-tp1756553p1756553.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org