[jira] [Updated] (SUREFIRE-1172) Incompatibility with MultipleFailureException
[
https://issues.apache.org/jira/browse/SUREFIRE-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Scotto updated SUREFIRE-1172:
-
Environment:
junit 4.12
maven-surefire-plugin 2.18.1
> Incompatibility with MultipleFailureException
> -
>
> Key: SUREFIRE-1172
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1172
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
> Environment: junit 4.12
> maven-surefire-plugin 2.18.1
>Reporter: Alberto Scotto
>
> Given this test:
> {code}
> public class MyTest {
> @Rule public ErrorCollector errorCollector = new ErrorCollector();
> @Test
> public void test() {
> errorCollector.checkThat("asd", CoreMatchers.startsWith("B"));
> errorCollector.checkThat("asd", CoreMatchers.startsWith("C"));
> }
> }
> {code}
> mvn clean test will produce the following output:
> {code}
> ---
> T E S T S
> ---
> Running MyTest
> Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.089 sec <<<
> FAILURE!
> test(MyTest) Time elapsed: 0.019 sec <<< FAILURE!
> java.lang.AssertionError:
> Expected: a string starting with "B"
> but: was "asd"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:956)
> at org.junit.rules.ErrorCollector$1.call(ErrorCollector.java:65)
> at org.junit.rules.ErrorCollector.checkSucceeds(ErrorCollector.java:78)
> at org.junit.rules.ErrorCollector.checkThat(ErrorCollector.java:63)
> at org.junit.rules.ErrorCollector.checkThat(ErrorCollector.java:54)
> at MyTest.test(MyTest.java:19)
> 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:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> 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:497)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> test(MyTest) Time elapsed: 0.02 sec <<< FAILURE!
> java.lang.AssertionError:
> Expected: a string starting with "C"
> but: was "asd"
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:956)
> at org.junit.rules.ErrorCollector$1.call(ErrorCollector.java:65)
> at org.junit.rules.
[jira] [Created] (SUREFIRE-1172) Incompatibility with MultipleFailureException
Alberto Scotto created SUREFIRE-1172:
Summary: Incompatibility with MultipleFailureException
Key: SUREFIRE-1172
URL: https://issues.apache.org/jira/browse/SUREFIRE-1172
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Surefire Plugin
Reporter: Alberto Scotto
Given this test:
{code}
public class MyTest {
@Rule public ErrorCollector errorCollector = new ErrorCollector();
@Test
public void test() {
errorCollector.checkThat("asd", CoreMatchers.startsWith("B"));
errorCollector.checkThat("asd", CoreMatchers.startsWith("C"));
}
}
{code}
mvn clean test will produce the following output:
{code}
---
T E S T S
---
Running MyTest
Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.089 sec <<<
FAILURE!
test(MyTest) Time elapsed: 0.019 sec <<< FAILURE!
java.lang.AssertionError:
Expected: a string starting with "B"
but: was "asd"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.rules.ErrorCollector$1.call(ErrorCollector.java:65)
at org.junit.rules.ErrorCollector.checkSucceeds(ErrorCollector.java:78)
at org.junit.rules.ErrorCollector.checkThat(ErrorCollector.java:63)
at org.junit.rules.ErrorCollector.checkThat(ErrorCollector.java:54)
at MyTest.test(MyTest.java:19)
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:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
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:497)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
test(MyTest) Time elapsed: 0.02 sec <<< FAILURE!
java.lang.AssertionError:
Expected: a string starting with "C"
but: was "asd"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.rules.ErrorCollector$1.call(ErrorCollector.java:65)
at org.junit.rules.ErrorCollector.checkSucceeds(ErrorCollector.java:78)
at org.junit.rules.ErrorCollector.checkThat(ErrorCollector.java:63)
at org.junit.rules.ErrorCollector.checkThat(ErrorCollector.java:54)
at MyTest.test(MyTest.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(
[jira] [Commented] (MSHADE-156) shade plugin is transforming also strings that are not supposed to be transformed
[
https://issues.apache.org/jira/browse/MSHADE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680987#comment-14680987
]
Elliott Clark commented on MSHADE-156:
--
Pretty sure that we're seeing this in
https://issues.apache.org/jira/browse/HBASE-13889
We have the shad plugin configured like so:
{code}
org.apache.maven.plugins
maven-shade-plugin
package
shade
false
true
${project.build.directory}/dependency-reduced-pom.xml
*:*
org.apache.hbase:hbase-resource-bundle
org.slf4j:*
com.google.code.findbugs:*
com.github.stephenc.findbugs:*
org.apache.htrace:*
log4j:*
commons-logging:*
com
org.apache.hadoop.hbase.shaded.com
com.sun.**
com.ibm.**
net
org.apache.hadoop.hbase.shaded.net
io
org.apache.hadoop.hbase.shaded.io
org
org.apache.hadoop.hbase.shaded.org
org.apache.hadoop.**
org.apache.commons.logging.**
org.w3c.**
org.xml.**
org.slf4j.**
LICENSE.txt
ASL2.0
false
${project.name}
{code}
This is relocating strings like:
{code}"com.sun.security.auth.UnixPrincipal"{code} to
{code}"org/apache/hadoop/hbase/shaded/com.sun.security.auth.module.UnixLoginModule"{code}
> shade plugin is transforming also strings that are not supposed to be
> transformed
> -
>
> Key: MSHADE-156
> URL: https://issues.apache.org/jira/browse/MSHADE-156
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Neeme Praks
>
> I'm shading several third party libraries into a single JAR. In the context
> of this issue, there are two important libraries:
> 1. com.nothome:javaxdelta:2.0.1 - this library is in "at.spardat.xma.xdelta"
> package.
> 2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
> ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to
> convert stack trace elements into strings:
> {code}
> public String getSTEAsString() {
> if (steAsString == null) {
> steAsString = "at " + ste.toString();
> }
> return steAsString;
> }
> {code}
> I use "org.myorgname.appname.shaded" package for shading.
> During shading, the constant "at " is replaced with
> "org.myorgname.appname.shaded.at" -- shade plugin thinks that the "at" in the
[jira] [Updated] (MLINKCHECK-23) Linkcheck reports 302 Found on link that is redirected to itself.
[ https://issues.apache.org/jira/browse/MLINKCHECK-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Selkin updated MLINKCHECK-23: Summary: Linkcheck reports 302 Found on link that is redirected to itself. (was: Linkcheck reports 302 Found on direct link.) > Linkcheck reports 302 Found on link that is redirected to itself. > - > > Key: MLINKCHECK-23 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-23 > Project: Maven Linkcheck Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: OS: Linux Mint, IntelliJ IDEA, checkstyle >Reporter: Andrei Selkin > > We use maven-linkcheck-plugin v. 1.2 to check links on checkstyle's website: > http://checkstyle.sourceforge.net/ with the following config: > > org.apache.maven.plugins > maven-linkcheck-plugin > 1.2 > > GET > 3000 > false > true > > dependencies.html > cobertura/** > dsm/** > xref/** > xref-test/** > pmd.html > findbugs.html > surefire-report.html > > taglist.html > > > > > http://iweb.dl.sourceforge.net/project/checkstyle/checkstyle/*-SNAPSHOT/checkstyle-*-SNAPSHOT-all.jar > reports/google-style/guava > reports/javadoc/openjdk8 > https://travis-ci.org/ > > https://travis-ci.org/checkstyle/checkstyle > > https://coveralls.io/r/checkstyle/checkstyle > http://search.maven.org/* > http://junit.org > > http://sonar-plugins.codehaus.org/maven-report > > **/com/puppycrawl/** > > > http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?* > > > 401 > > > > maven-linkcheck-plugin v. 1.2 reports 302 Found: > http://kclee.com/clemens/java/javancss/ > But according to redirect tracers the link is redirect directly to > http://kclee.com/clemens/java/javancss/ > Full report: http://mezk.github.io/linkcheck/linkcheck.html > Checkstyle's pom.xml: > https://github.com/checkstyle/checkstyle/blob/master/pom.xml > Redirect tracers: > http://www.wheregoes.com/retracer.php > http://www.internetofficer.com/seo-tool/redirect-check/ > http://redirectdetective.com/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MLINKCHECK-23) Linkcheck reports 302 Found on direct link.
Andrei Selkin created MLINKCHECK-23: --- Summary: Linkcheck reports 302 Found on direct link. Key: MLINKCHECK-23 URL: https://issues.apache.org/jira/browse/MLINKCHECK-23 Project: Maven Linkcheck Plugin Issue Type: Bug Affects Versions: 1.2 Environment: OS: Linux Mint, IntelliJ IDEA, checkstyle Reporter: Andrei Selkin We use maven-linkcheck-plugin v. 1.2 to check links on checkstyle's website: http://checkstyle.sourceforge.net/ with the following config: org.apache.maven.plugins maven-linkcheck-plugin 1.2 GET 3000 false true dependencies.html cobertura/** dsm/** xref/** xref-test/** pmd.html findbugs.html surefire-report.html taglist.html http://iweb.dl.sourceforge.net/project/checkstyle/checkstyle/*-SNAPSHOT/checkstyle-*-SNAPSHOT-all.jar reports/google-style/guava reports/javadoc/openjdk8 https://travis-ci.org/ https://travis-ci.org/checkstyle/checkstyle https://coveralls.io/r/checkstyle/checkstyle http://search.maven.org/* http://junit.org http://sonar-plugins.codehaus.org/maven-report **/com/puppycrawl/** http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?* 401 maven-linkcheck-plugin v. 1.2 reports 302 Found: http://kclee.com/clemens/java/javancss/ But according to redirect tracers the link is redirect directly to http://kclee.com/clemens/java/javancss/ Full report: http://mezk.github.io/linkcheck/linkcheck.html Checkstyle's pom.xml: https://github.com/checkstyle/checkstyle/blob/master/pom.xml Redirect tracers: http://www.wheregoes.com/retracer.php http://www.internetofficer.com/seo-tool/redirect-check/ http://redirectdetective.com/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MLINKCHECK-22) Linkcheck reports 307 Temporary Redirect on twitter.com
Andrei Selkin created MLINKCHECK-22: --- Summary: Linkcheck reports 307 Temporary Redirect on twitter.com Key: MLINKCHECK-22 URL: https://issues.apache.org/jira/browse/MLINKCHECK-22 Project: Maven Linkcheck Plugin Issue Type: Bug Affects Versions: 1.2 Environment: OS: Linux Mint, IntelliJ IDEA, checkstyle Reporter: Andrei Selkin We use maven-linkcheck-plugin v. 1.2 to check links on checkstyle's website: http://checkstyle.sourceforge.net/ with the following config: org.apache.maven.plugins maven-linkcheck-plugin 1.2 GET 3000 false true dependencies.html cobertura/** dsm/** xref/** xref-test/** pmd.html findbugs.html surefire-report.html taglist.html http://iweb.dl.sourceforge.net/project/checkstyle/checkstyle/*-SNAPSHOT/checkstyle-*-SNAPSHOT-all.jar reports/google-style/guava reports/javadoc/openjdk8 https://travis-ci.org/ https://travis-ci.org/checkstyle/checkstyle https://coveralls.io/r/checkstyle/checkstyle http://search.maven.org/* http://junit.org http://sonar-plugins.codehaus.org/maven-report **/com/puppycrawl/** http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?* 401 maven-linkcheck-plugin v. 1.2 reports that the following link is Temporary Redirect: https://twitter.com/checkstyle_java/ But according to redirect tracers the link is direct. Full report: http://mezk.github.io/linkcheck/linkcheck.html Checkstyle's pom.xml: https://github.com/checkstyle/checkstyle/blob/master/pom.xml Redirect tracers: http://www.wheregoes.com/retracer.php http://www.internetofficer.com/seo-tool/redirect-check/ http://redirectdetective.com/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DOXIASITETOOLS-104) DefaultSiteRenderer must check if the user provides inputEncoding and only if not then use the encoding of the file.
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680493#comment-14680493
]
Michael Osipov edited comment on DOXIASITETOOLS-104 at 8/10/15 6:18 PM:
You wrote that you fixed it in master from which I have assumed Git is used.
Linking to Subversion revisions is easy:
{noformat}
[r1695142|http://svn.apache.org/r1695142]
{noformat}
Output: [r1695142|http://svn.apache.org/r1695142]
was (Author: michael-o):
You wrote that you fixed it in master from which I have assumed Git is used.
Linking to Subversion revisions is easy:
{noformat}
[http://svn.apache.org/r1695142|r1695142]
[noformat}
Output: [http://svn.apache.org/r1695142|r1695142]
> DefaultSiteRenderer must check if the user provides inputEncoding and only if
> not then use the encoding of the file.
>
>
> Key: DOXIASITETOOLS-104
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
> Project: Maven Doxia Sitetools
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Petar Tahchiev
> Fix For: 1.7
>
>
> Currently the {{DefaultSiteRenderer}} uses this method {{newXmlReader}} to
> create the reader. This method, however, tries to detect the encoding of the
> xml document and read it using that encoding. The user might want to specify
> another encoding and force it to use that encoding. See
> https://issues.apache.org/jira/browse/DOXIA-524
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-104) DefaultSiteRenderer must check if the user provides inputEncoding and only if not then use the encoding of the file.
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680493#comment-14680493
]
Michael Osipov commented on DOXIASITETOOLS-104:
---
You wrote that you fixed it in master from which I have assumed Git is used.
Linking to Subversion revisions is easy:
{noformat}
[http://svn.apache.org/r1695142|r1695142]
[noformat}
Output: [http://svn.apache.org/r1695142|r1695142]
> DefaultSiteRenderer must check if the user provides inputEncoding and only if
> not then use the encoding of the file.
>
>
> Key: DOXIASITETOOLS-104
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
> Project: Maven Doxia Sitetools
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Petar Tahchiev
> Fix For: 1.7
>
>
> Currently the {{DefaultSiteRenderer}} uses this method {{newXmlReader}} to
> create the reader. This method, however, tries to detect the encoding of the
> xml document and read it using that encoding. The user might want to specify
> another encoding and force it to use that encoding. See
> https://issues.apache.org/jira/browse/DOXIA-524
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-104) DefaultSiteRenderer must check if the user provides inputEncoding and only if not then use the encoding of the file.
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680485#comment-14680485
]
Petar Tahchiev commented on DOXIASITETOOLS-104:
---
Doxia is still using svn. I'm now quite sure how to do it, but revision is
1695142
and the url is
https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/trunk/
> DefaultSiteRenderer must check if the user provides inputEncoding and only if
> not then use the encoding of the file.
>
>
> Key: DOXIASITETOOLS-104
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
> Project: Maven Doxia Sitetools
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Petar Tahchiev
> Fix For: 1.7
>
>
> Currently the {{DefaultSiteRenderer}} uses this method {{newXmlReader}} to
> create the reader. This method, however, tries to detect the encoding of the
> xml document and read it using that encoding. The user might want to specify
> another encoding and force it to use that encoding. See
> https://issues.apache.org/jira/browse/DOXIA-524
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-524) ISO-8859-15 encoding problem with markdown
[
https://issues.apache.org/jira/browse/DOXIA-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680477#comment-14680477
]
Michael Osipov commented on DOXIA-524:
--
I'll close this as duplicate as soon as Doxia Sitetools 1.7 are released.
> ISO-8859-15 encoding problem with markdown
> ---
>
> Key: DOXIA-524
> URL: https://issues.apache.org/jira/browse/DOXIA-524
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.3, 1.6
>Reporter: Jesús
> Attachments: SiteEncoding.tar.gz
>
>
> The markdown file encoding is ISO-8859-15 and the generated html is in
> ISO-8859-15 too but all the áéÃó etc characters are translated to �
> In the pom.xml we have:
> {code:xml}
>
>
> ISO-8859-15
> ISO-8859-15
>
> ...
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.3
>
>
> org.apache.maven.doxia
> doxia-module-markdown
> 1.6
>
>
>
> ISO-8859-15
> ISO-8859-15
> es
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-104) DefaultSiteRenderer must check if the user provides inputEncoding and only if not then use the encoding of the file.
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680475#comment-14680475
]
Michael Osipov commented on DOXIASITETOOLS-104:
---
Can you link to the Git commit?
> DefaultSiteRenderer must check if the user provides inputEncoding and only if
> not then use the encoding of the file.
>
>
> Key: DOXIASITETOOLS-104
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
> Project: Maven Doxia Sitetools
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Petar Tahchiev
> Fix For: 1.7
>
>
> Currently the {{DefaultSiteRenderer}} uses this method {{newXmlReader}} to
> create the reader. This method, however, tries to detect the encoding of the
> xml document and read it using that encoding. The user might want to specify
> another encoding and force it to use that encoding. See
> https://issues.apache.org/jira/browse/DOXIA-524
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MINSTALL-115) Setting installAtEnd causes no installs to occur when a multimodule project has multiple class realms
[
https://issues.apache.org/jira/browse/MINSTALL-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Pearson updated MINSTALL-115:
Attachment: InstallConfiguration.java
mojo.patch
The attached files are sufficient to fixed the issue for me, but the
{{InstallConfiguration}} class makes certain assumptions about the
configuration object which probably could be improved upon.
> Setting installAtEnd causes no installs to occur when a multimodule project
> has multiple class realms
> -
>
> Key: MINSTALL-115
> URL: https://issues.apache.org/jira/browse/MINSTALL-115
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 2.5.2
>Reporter: Philip Pearson
> Attachments: InstallConfiguration.java, mojo.patch
>
>
> When the {{installAtEnd}} configuration parameter is set to {{true}} on a
> multimodule project with multiple class realms then because a different class
> loaders creates instances of the {{InstallMojo}} class there will be muliple
> instances of {{readyProjectsCounter}} and {{installRequests}}.
> However, because the end is determined by {{projectsReady =
> readyProjectsCounter.incrementAndGet() == reactorProjects.size()}} it will
> never complete as {{readyProjectsCounter}} will never equal the size
> {{reactorProjects}} if even one project is executed in another class realm.
> {{maven-deploy-plugin}} partially solved this in MDEPLOY-193 by using
> {{project.equals(reactorProjects.get(reactorProjects.size() - 1))}} instead.
> However, the installation is a little more complex than the deploy as we need
> to read the used the {{createChecksum}} and {{updateReleaseInfo}}
> configuration parameters from each installed project - we can't store them
> ahead of time because of the issue with the class realms, so we need to read
> the plugin configurations before we can call
> {{installProject(instalRequest)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOXIASITETOOLS-104) DefaultSiteRenderer must check if the user provides inputEncoding and only if not then use the encoding of the file.
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petar Tahchiev resolved DOXIASITETOOLS-104.
---
Resolution: Fixed
Fix Version/s: 1.7
> DefaultSiteRenderer must check if the user provides inputEncoding and only if
> not then use the encoding of the file.
>
>
> Key: DOXIASITETOOLS-104
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
> Project: Maven Doxia Sitetools
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Petar Tahchiev
> Fix For: 1.7
>
>
> Currently the {{DefaultSiteRenderer}} uses this method {{newXmlReader}} to
> create the reader. This method, however, tries to detect the encoding of the
> xml document and read it using that encoding. The user might want to specify
> another encoding and force it to use that encoding. See
> https://issues.apache.org/jira/browse/DOXIA-524
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-524) ISO-8859-15 encoding problem with markdown
[
https://issues.apache.org/jira/browse/DOXIA-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680451#comment-14680451
]
Petar Tahchiev commented on DOXIA-524:
--
This is actually an issue in doxia-sitetools. Here's the link to the issue:
https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
I've fixed it in the master.
> ISO-8859-15 encoding problem with markdown
> ---
>
> Key: DOXIA-524
> URL: https://issues.apache.org/jira/browse/DOXIA-524
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.3, 1.6
>Reporter: Jesús
> Attachments: SiteEncoding.tar.gz
>
>
> The markdown file encoding is ISO-8859-15 and the generated html is in
> ISO-8859-15 too but all the áéÃó etc characters are translated to �
> In the pom.xml we have:
> {code:xml}
>
>
> ISO-8859-15
> ISO-8859-15
>
> ...
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.3
>
>
> org.apache.maven.doxia
> doxia-module-markdown
> 1.6
>
>
>
> ISO-8859-15
> ISO-8859-15
> es
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-104) DefaultSiteRenderer must check if the user provides inputEncoding and only if not then use the encoding of the file.
Petar Tahchiev created DOXIASITETOOLS-104:
-
Summary: DefaultSiteRenderer must check if the user provides
inputEncoding and only if not then use the encoding of the file.
Key: DOXIASITETOOLS-104
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-104
Project: Maven Doxia Sitetools
Issue Type: Bug
Affects Versions: 1.6
Reporter: Petar Tahchiev
Currently the {{DefaultSiteRenderer}} uses this method {{newXmlReader}} to
create the reader. This method, however, tries to detect the encoding of the
xml document and read it using that encoding. The user might want to specify
another encoding and force it to use that encoding. See
https://issues.apache.org/jira/browse/DOXIA-524
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MINSTALL-115) Setting installAtEnd causes no installs to occur when a multimodule project has multiple class realms
Philip Pearson created MINSTALL-115:
---
Summary: Setting installAtEnd causes no installs to occur when a
multimodule project has multiple class realms
Key: MINSTALL-115
URL: https://issues.apache.org/jira/browse/MINSTALL-115
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.5.2
Reporter: Philip Pearson
When the {{installAtEnd}} configuration parameter is set to {{true}} on a
multimodule project with multiple class realms then because a different class
loaders creates instances of the {{InstallMojo}} class there will be muliple
instances of {{readyProjectsCounter}} and {{installRequests}}.
However, because the end is determined by {{projectsReady =
readyProjectsCounter.incrementAndGet() == reactorProjects.size()}} it will
never complete as {{readyProjectsCounter}} will never equal the size
{{reactorProjects}} if even one project is executed in another class realm.
{{maven-deploy-plugin}} partially solved this in MDEPLOY-193 by using
{{project.equals(reactorProjects.get(reactorProjects.size() - 1))}} instead.
However, the installation is a little more complex than the deploy as we need
to read the used the {{createChecksum}} and {{updateReleaseInfo}} configuration
parameters from each installed project - we can't store them ahead of time
because of the issue with the class realms, so we need to read the plugin
configurations before we can call {{installProject(instalRequest)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MJAVADOC-433) Helpfile with spaces in name not supported in Java 8
John Aslinger created MJAVADOC-433: -- Summary: Helpfile with spaces in name not supported in Java 8 Key: MJAVADOC-433 URL: https://issues.apache.org/jira/browse/MJAVADOC-433 Project: Maven Javadoc Plugin Issue Type: Bug Reporter: John Aslinger Priority: Minor When a helpfile with spaces in the filename tries to get copied over, it results in a error: java.lang.IllegalArgumentException: Invalid relative name: This affects Java 8 but not Java 7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SCM-800) scm connection, developerConnection and url add artifactId at the end when they are inherited.
Rami Ojares created SCM-800: --- Summary: scm connection, developerConnection and url add artifactId at the end when they are inherited. Key: SCM-800 URL: https://issues.apache.org/jira/browse/SCM-800 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.9.4 Environment: All environments Reporter: Rami Ojares Fix For: 1.9.5 This issue is pretty much explained in the summary. scm fragment can not be inherited in most cases because the system adds child's artifactId always at the end of the project. Adding it automatically is of course nice for those few project's where the parent pom happens to be in the parent folder. But for everyone else it's a showstopper. This seems to affect also some other urls/paths and this issue has been reported in one way or another numerous times since 2006. It's about time to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MJAVADOC-432) Downgrade "Error fetching link: .../package-list"
Kaz Nishimura created MJAVADOC-432: -- Summary: Downgrade "Error fetching link: .../package-list" Key: MJAVADOC-432 URL: https://issues.apache.org/jira/browse/MJAVADOC-432 Project: Maven Javadoc Plugin Issue Type: Wish Affects Versions: 2.10.3 Environment: Microsoft Windows [Version 6.1.7601] Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 22:51:28+0900) Java version: 1.8.0_51, vendor: Oracle Corporation Reporter: Kaz Nishimura Priority: Minor If I set detectLinks to true, I get many "Error fetching link: .../package-list" messages when generating API documents. As many artifacts do not provide their apidocs according to the Maven convention, I wish the log level for such messages would be much lower (ignored anyway) so that it could be easier to find more serious errors, especially in continuous integration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
