[jira] [Commented] (SUREFIRE-1227) The Description argument RunListener#testRunStarted(Description) doesn't include test methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140251#comment-15140251
]
Victor Sidochenko commented on SUREFIRE-1227:
-
[~tibor17]
It is important for me. I`m using (in
[allure-cucumber-jvm-adaptor|https://github.com/allure-framework/allure-cucumber-jvm-adaptor])
description with all its childern in testRunStarted to find out parents for
descriptions passed from testStarted.
And one question. Junit (since 4.12) has uniqueId parameter as argument to
create description and cucumber-jvm uses it to find out needed objects.
In surefire-plugin 2.18.1 Description wich comes as parameter to testRunStarted
has different uniqueIds than in testStarted/testIfnored. This behaviour happens
only if RunListener passed from pom.xml as surefire-plugin configuration
parameter. If it set from junit test - all fine and uniqueIds are valid.
So if you will decide to return back child descriptions, could you look at this
problem? [Details|https://github.com/cucumber/cucumber-jvm/issues/959].
> The Description argument RunListener#testRunStarted(Description) doesn't
> include test methods
> -
>
> Key: SUREFIRE-1227
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1227
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Jiri Locker
> Attachments: maven-surefire-run-listener.zip
>
>
> In Surefire 2.19 the Description passed to testRunStarted() is a test run
> description and has 2 levels of children (test classes > test methods). The
> top level Description's testCount property is equal to the number of test
> methods in all test classes that are going to be run. When dumping the
> description tree it may look like this:
> {noformat}
> Description: ~ null (6)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (2)
> Description: ~ ~ ~
> testMethod1(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ ~
> testMethod2(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (4)
> Description: ~ ~ ~
> testMethodA(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodB(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodC(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodD(io.github.yurloc.example.runlistener.MySecondTest) (1)
> {noformat}
> However in Surefire 2.19.1 the leaf descriptions of test methods are missing:
> {noformat}
> Description: ~ null (2)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (1)
> {noformat}
> Because of this I am unable to access the total test count, which I use to
> calculate ETA of the test run finish. I seem that this change of behavior was
> introduced by fixing SUREFIRE-1187.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1227) The Description argument RunListener#testRunStarted(Description) doesn't include test methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140228#comment-15140228
]
Tibor Digana edited comment on SUREFIRE-1227 at 2/10/16 2:41 AM:
-
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children. That's the reason we did not use
JUnit to ask for children. On the other side we did pass only description
without having the children. In order to substitute JUnit it would never be
successful without using real runner. Some runners are not so transparent
(Parameterized, Cucumber) like pure non-parameterized JUnit runner and better
to prevent from null description however with missing children.
was (Author: tibor17):
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children. That's the reason we did not use
JUnit to ask for children. On the other side we did pass only description
without having the children. In order to substitute JUnit it would never be
successful without using real runner. Some runners are not so transparent
(Parameterized, Cucumber) like JUnit runners and better to prevent from null
description however missing children.
> The Description argument RunListener#testRunStarted(Description) doesn't
> include test methods
> -
>
> Key: SUREFIRE-1227
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1227
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Jiri Locker
> Attachments: maven-surefire-run-listener.zip
>
>
> In Surefire 2.19 the Description passed to testRunStarted() is a test run
> description and has 2 levels of children (test classes > test methods). The
> top level Description's testCount property is equal to the number of test
> methods in all test classes that are going to be run. When dumping the
> description tree it may look like this:
> {noformat}
> Description: ~ null (6)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (2)
> Description: ~ ~ ~
> testMethod1(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ ~
> testMethod2(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (4)
> Description: ~ ~ ~
> testMethodA(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodB(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodC(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodD(io.github.yurloc.example.runlistener.MySecondTest) (1)
> {noformat}
> However in Surefire 2.19.1 the leaf descriptions of test methods are missing:
> {noformat}
> Description: ~ null (2)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (1)
> {noformat}
> Because of this I am unable to access the total test count, which I use to
> calculate ETA of the test run finish. I seem that this change of behavior was
> introduced by fixing SUREFIRE-1187.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1227) The Description argument RunListener#testRunStarted(Description) doesn't include test methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140228#comment-15140228
]
Tibor Digana edited comment on SUREFIRE-1227 at 2/10/16 2:39 AM:
-
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children. That's the reason we did not use
JUnit to ask for children. On the other side we did pass only empty description
without discoverying the children. In order to substitute JUnit it would never
be successful without using real runner. Some runners are not so transparent
(Parameterized, Cucumber) like JUnit runners and better to prevent from null
description however missing children.
was (Author: tibor17):
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children.
That's the reason we did not use JUnit to ask for children. On the other side
we did pass only empty description without discoverying the children. In order
to substitute JUnit it would never be successful without using real runner.
Some runners are not so transparent (Cucumber) like JUnit runners and better to
prevent from null description however missing children.
> The Description argument RunListener#testRunStarted(Description) doesn't
> include test methods
> -
>
> Key: SUREFIRE-1227
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1227
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Jiri Locker
> Attachments: maven-surefire-run-listener.zip
>
>
> In Surefire 2.19 the Description passed to testRunStarted() is a test run
> description and has 2 levels of children (test classes > test methods). The
> top level Description's testCount property is equal to the number of test
> methods in all test classes that are going to be run. When dumping the
> description tree it may look like this:
> {noformat}
> Description: ~ null (6)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (2)
> Description: ~ ~ ~
> testMethod1(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ ~
> testMethod2(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (4)
> Description: ~ ~ ~
> testMethodA(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodB(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodC(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodD(io.github.yurloc.example.runlistener.MySecondTest) (1)
> {noformat}
> However in Surefire 2.19.1 the leaf descriptions of test methods are missing:
> {noformat}
> Description: ~ null (2)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (1)
> {noformat}
> Because of this I am unable to access the total test count, which I use to
> calculate ETA of the test run finish. I seem that this change of behavior was
> introduced by fixing SUREFIRE-1187.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1227) The Description argument RunListener#testRunStarted(Description) doesn't include test methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140228#comment-15140228
]
Tibor Digana edited comment on SUREFIRE-1227 at 2/10/16 2:40 AM:
-
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children. That's the reason we did not use
JUnit to ask for children. On the other side we did pass only description
without having the children. In order to substitute JUnit it would never be
successful without using real runner. Some runners are not so transparent
(Parameterized, Cucumber) like JUnit runners and better to prevent from null
description however missing children.
was (Author: tibor17):
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children. That's the reason we did not use
JUnit to ask for children. On the other side we did pass only empty description
without discoverying the children. In order to substitute JUnit it would never
be successful without using real runner. Some runners are not so transparent
(Parameterized, Cucumber) like JUnit runners and better to prevent from null
description however missing children.
> The Description argument RunListener#testRunStarted(Description) doesn't
> include test methods
> -
>
> Key: SUREFIRE-1227
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1227
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Jiri Locker
> Attachments: maven-surefire-run-listener.zip
>
>
> In Surefire 2.19 the Description passed to testRunStarted() is a test run
> description and has 2 levels of children (test classes > test methods). The
> top level Description's testCount property is equal to the number of test
> methods in all test classes that are going to be run. When dumping the
> description tree it may look like this:
> {noformat}
> Description: ~ null (6)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (2)
> Description: ~ ~ ~
> testMethod1(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ ~
> testMethod2(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (4)
> Description: ~ ~ ~
> testMethodA(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodB(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodC(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodD(io.github.yurloc.example.runlistener.MySecondTest) (1)
> {noformat}
> However in Surefire 2.19.1 the leaf descriptions of test methods are missing:
> {noformat}
> Description: ~ null (2)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (1)
> {noformat}
> Because of this I am unable to access the total test count, which I use to
> calculate ETA of the test run finish. I seem that this change of behavior was
> introduced by fixing SUREFIRE-1187.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5626) Avoid negative durations or handle them correctly
[
https://issues.apache.org/jira/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140232#comment-15140232
]
Christian Schulte commented on MNG-5626:
Ok. Are you planning to work on this?
> Avoid negative durations or handle them correctly
> -
>
> Key: MNG-5626
> URL: https://issues.apache.org/jira/browse/MNG-5626
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.1
>Reporter: Christian Jung
>Priority: Minor
>
> In issue MNG-5623 we reported an exception when printing the reactor summary
> if one of the times was negative.
> I saw in one case, that the overall maven build time, as measured from
> outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
> reactor summary was:
> {code}
> 13:55:25,184 INFO - Reactor Summary:
> 13:55:25,184 INFO -
> 13:55:25,184 INFO - module1 ...
> SUCCESS [ 5.911 s]
> 13:55:25,184 INFO - module2 ...
> SUCCESS [ 0.255 s]
> 13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
> SUCCESS [-27.-64 s]
> 13:55:25,185 INFO -
>
> 13:55:25,185 INFO - BUILD SUCCESS
> 13:55:25,185 INFO -
>
> 13:55:25,185 INFO - Total time: -20.-73 s
> 13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
> 13:55:25,572 INFO - Final Memory: 32M/439M
> 13:55:25,572 INFO -
>
> {code}
> The thing is quite hard to reproduce, the machines were virtual machines that
> have been running for quite a long time.
> Our administrators suspected that just at this point, the local clock was
> synchronized with some outer source.
> We should check if such negative durations can be avoided, and if not, they
> should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1227) The Description argument RunListener#testRunStarted(Description) doesn't include test methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140228#comment-15140228
]
Tibor Digana commented on SUREFIRE-1227:
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children.
That's the reason we did not use JUnit to ask for children. On the other side
we did passed only empty description without discoverying the children. In
order to substitute JUnit it would never be successful without using real
runner. Some runners are not so transparent (Cucumber) like JUnit runners and
better to prevent from null description however missing children.
> The Description argument RunListener#testRunStarted(Description) doesn't
> include test methods
> -
>
> Key: SUREFIRE-1227
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1227
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Jiri Locker
> Attachments: maven-surefire-run-listener.zip
>
>
> In Surefire 2.19 the Description passed to testRunStarted() is a test run
> description and has 2 levels of children (test classes > test methods). The
> top level Description's testCount property is equal to the number of test
> methods in all test classes that are going to be run. When dumping the
> description tree it may look like this:
> {noformat}
> Description: ~ null (6)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (2)
> Description: ~ ~ ~
> testMethod1(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ ~
> testMethod2(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (4)
> Description: ~ ~ ~
> testMethodA(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodB(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodC(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodD(io.github.yurloc.example.runlistener.MySecondTest) (1)
> {noformat}
> However in Surefire 2.19.1 the leaf descriptions of test methods are missing:
> {noformat}
> Description: ~ null (2)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (1)
> {noformat}
> Because of this I am unable to access the total test count, which I use to
> calculate ETA of the test run finish. I seem that this change of behavior was
> introduced by fixing SUREFIRE-1187.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1227) The Description argument RunListener#testRunStarted(Description) doesn't include test methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140228#comment-15140228
]
Tibor Digana edited comment on SUREFIRE-1227 at 2/10/16 2:32 AM:
-
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children.
That's the reason we did not use JUnit to ask for children. On the other side
we did pass only empty description without discoverying the children. In order
to substitute JUnit it would never be successful without using real runner.
Some runners are not so transparent (Cucumber) like JUnit runners and better to
prevent from null description however missing children.
was (Author: tibor17):
[~jloc...@redhat.com]
Is this fix very important for you?
We had to do this because otherwise you would reach NPE since of null in the
method argument. Other users argued that Arquillian runner was started twice,
it's because of discoverying the children.
That's the reason we did not use JUnit to ask for children. On the other side
we did passed only empty description without discoverying the children. In
order to substitute JUnit it would never be successful without using real
runner. Some runners are not so transparent (Cucumber) like JUnit runners and
better to prevent from null description however missing children.
> The Description argument RunListener#testRunStarted(Description) doesn't
> include test methods
> -
>
> Key: SUREFIRE-1227
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1227
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Jiri Locker
> Attachments: maven-surefire-run-listener.zip
>
>
> In Surefire 2.19 the Description passed to testRunStarted() is a test run
> description and has 2 levels of children (test classes > test methods). The
> top level Description's testCount property is equal to the number of test
> methods in all test classes that are going to be run. When dumping the
> description tree it may look like this:
> {noformat}
> Description: ~ null (6)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (2)
> Description: ~ ~ ~
> testMethod1(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ ~
> testMethod2(io.github.yurloc.example.runlistener.MyFirstTest) (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (4)
> Description: ~ ~ ~
> testMethodA(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodB(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodC(io.github.yurloc.example.runlistener.MySecondTest) (1)
> Description: ~ ~ ~
> testMethodD(io.github.yurloc.example.runlistener.MySecondTest) (1)
> {noformat}
> However in Surefire 2.19.1 the leaf descriptions of test methods are missing:
> {noformat}
> Description: ~ null (2)
> Description: ~ ~ io.github.yurloc.example.runlistener.MyFirstTest (1)
> Description: ~ ~ io.github.yurloc.example.runlistener.MySecondTest (1)
> {noformat}
> Because of this I am unable to access the total test count, which I use to
> calculate ETA of the test run finish. I seem that this change of behavior was
> introduced by fixing SUREFIRE-1187.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1225) Can't run a single parameterized test
[
https://issues.apache.org/jira/browse/SUREFIRE-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140198#comment-15140198
]
Tibor Digana commented on SUREFIRE-1225:
Surefire did exactly as you said. Sometimes the developers rely on wrong
behavior of previous version of Surefire. The pattern internally does not make
any assumptions and does not need to add wildcard after #testWithParameters.
That's maybe what the user should do and then Surefire algorithms are more
strict in finding the matching method names.
The problem is that the method name is not the one you can see in sources. To
understand this the user needs to have a little knowhow of JUnit internals
because the test method is always {{described}} with different name if using
{{Parameterized}}. The reason is simple in JUnit so that every test must have a
unique {{Description}} and because parameterized tests could break this rule if
using always the same method name, the JUnit runner added brackets behind your
test.
Please read our documentation. You have two option, use wildcard or brackets
after method name in the pattern.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#Multiple_Formats_in_One
> Can't run a single parameterized test
> -
>
> Key: SUREFIRE-1225
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1225
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.19.1
>Reporter: Dmitry Baev
>
> The sample test to reproduce the problem:
> {code:java|title=com/github/baev/MyTest.java}
> @RunWith(Parameterized.class)
> public class MyTest {
> @Parameterized.Parameters
> public static Collection data() {
> return Arrays.asList(
> new Object[]{},
> new Object[]{}
> );
> }
> @Test
> public void testWithParameters() throws Exception {
> }
> }
> {code}
> and then run
> {{clean test -Dtest=com.github.baev.MyTest#testWithParameters}}
> The output is
> {{Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project surefire-base-test-bug: No tests were executed!}}
> Is it expected?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1226) Surefire trims all stack trace elements except those in the test that failed
[
https://issues.apache.org/jira/browse/SUREFIRE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140169#comment-15140169
]
Tibor Digana commented on SUREFIRE-1226:
[~jloc...@redhat.com]
This was introduced with a fix in 2.19. The parameter {{trimStackTrace}} was
always set to {{true}}. We only covered the description behind this parameter
and thus we removed lines which do not list the location of the test.
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#trimStackTrace
If you set the parameter to {{false}} you will have your expected result. I
think the fix was ok from my PoV and we can close this issue.
> Surefire trims all stack trace elements except those in the test that failed
>
>
> Key: SUREFIRE-1226
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1226
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19
>Reporter: Jiri Locker
>Priority: Minor
> Attachments: mvn_stacktrace.tar.gz
>
>
> This looks like a re-occurrence of SUREFIRE-992 but now the stack trace is
> even more trimmed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-153) Deprecate direct template usage in favor of skin only
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140154#comment-15140154 ] Hudson commented on DOXIASITETOOLS-153: --- SUCCESS: Integrated in doxia-all #250 (See [https://builds.apache.org/job/doxia-all/250/]) [DOXIASITETOOLS-153] Deprecate direct template usage in favor of skin only (michaelo: [http://svn.apache.org/viewvc/?view=rev&rev=1729502]) * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/Renderer.java > Deprecate direct template usage in favor of skin only > - > > Key: DOXIASITETOOLS-153 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-153 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Site renderer >Affects Versions: 1.6 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 1.7 > > > The usage of sole Velocity templates disables resources copying and other > processes. Using skins is recommended. Let's deprecate this and support skins > only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-134) Remove special handling of date format in DefaultSiteRenderer
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIASITETOOLS-134:
--
Component/s: Site renderer
> Remove special handling of date format in DefaultSiteRenderer
> -
>
> Key: DOXIASITETOOLS-134
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-134
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 1.7
>
>
> {{dateFormat}} is double-checked from validity and existance in decoration
> model and set with a fallback when everything fails. We should solely rely on
> the decoration model because it has a fixed value. This would save code and
> duplicate fixed values. Every deviation from it is undefined behavior.
> Redudant code for example:
> {code:java}
> DateFormat dateFormat = DateFormat.getDateInstance( DateFormat.DEFAULT,
> locale );
> PublishDate publishDate =
> siteRenderingContext.getDecoration().getPublishDate();
> if ( publishDate != null && StringUtils.isNotBlank( publishDate.getFormat() )
> )
> {
> dateFormat = new SimpleDateFormat( publishDate.getFormat(), locale );
> }
> context.put( "dateFormat", dateFormat );
> {code}
> or in {{site.vm}}:
> {code}
> #if ( $decorationPublishDate && $decorationPublishDate.format )
> #set ( $format = $decorationPublishDate.format )
> #else
> #set ( $format = "-MM-dd" )
> #end
> ##
> $dateFormat.applyPattern( $format )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-153) Deprecate direct template usage in favor of skin only
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-153. - Resolution: Fixed Fixed with [r1729502|http://svn.apache.org/r1729502]. > Deprecate direct template usage in favor of skin only > - > > Key: DOXIASITETOOLS-153 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-153 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Site renderer >Affects Versions: 1.6 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 1.7 > > > The usage of sole Velocity templates disables resources copying and other > processes. Using skins is recommended. Let's deprecate this and support skins > only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-154) Add encoding to skin descriptor to define the encoding of site.vm
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139974#comment-15139974 ] Michael Osipov commented on DOXIASITETOOLS-154: --- True! > Add encoding to skin descriptor to define the encoding of site.vm > - > > Key: DOXIASITETOOLS-154 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer, Skin model >Affects Versions: 1.7 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > currently, Velocity parses site.vm template with its default encoding: a skin > should be able to define its template encoding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-153) Deprecate direct template usage in favor of skin only
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIASITETOOLS-153: -- Fix Version/s: 1.7 > Deprecate direct template usage in favor of skin only > - > > Key: DOXIASITETOOLS-153 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-153 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Site renderer >Affects Versions: 1.6 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 1.7 > > > The usage of sole Velocity templates disables resources copying and other > processes. Using skins is recommended. Let's deprecate this and support skins > only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-154) Add encoding to skin descriptor to define the encoding of site.vm
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139945#comment-15139945 ] Hervé Boutemy commented on DOXIASITETOOLS-154: -- IIRC, it was about newlines we don't have many issues left, it's now easy to find DOXIASITETOOLS-88 :) > Add encoding to skin descriptor to define the encoding of site.vm > - > > Key: DOXIASITETOOLS-154 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer, Skin model >Affects Versions: 1.7 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > currently, Velocity parses site.vm template with its default encoding: a skin > should be able to define its template encoding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-154) Add encoding to skin descriptor to define the encoding of site.vm
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139934#comment-15139934 ] Michael Osipov commented on DOXIASITETOOLS-154: --- I remember we had this discussion already but do not remember the ticket... > Add encoding to skin descriptor to define the encoding of site.vm > - > > Key: DOXIASITETOOLS-154 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer, Skin model >Affects Versions: 1.7 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > currently, Velocity parses site.vm template with its default encoding: a skin > should be able to define its template encoding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5968) Default plugin version updates.
[ https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139932#comment-15139932 ] Hudson commented on MNG-5968: - SUCCESS: Integrated in maven-3.x #1214 (See [https://builds.apache.org/job/maven-3.x/1214/]) [MNG-5968] Default plugin version updates. (schulte: rev c37ea427337df28bb260a92ee016a0d464567bb7) * maven-core/src/main/resources/META-INF/plexus/default-bindings.xml > Default plugin version updates. > --- > > Key: MNG-5968 > URL: https://issues.apache.org/jira/browse/MNG-5968 > Project: Maven > Issue Type: Improvement >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-154) Add encoding to skin descriptor to define the encoding of site.vm
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139926#comment-15139926 ] Hervé Boutemy commented on DOXIASITETOOLS-154: -- yes, why not this has to be used when copying text resources, but not binary resources: this will be more complex to code perhaps another Jira issue to use this encoding for resources > Add encoding to skin descriptor to define the encoding of site.vm > - > > Key: DOXIASITETOOLS-154 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer, Skin model >Affects Versions: 1.7 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > currently, Velocity parses site.vm template with its default encoding: a skin > should be able to define its template encoding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DOXIASITETOOLS-153) Deprecate direct template usage in favor of skin only
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned DOXIASITETOOLS-153: - Assignee: Michael Osipov > Deprecate direct template usage in favor of skin only > - > > Key: DOXIASITETOOLS-153 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-153 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Site renderer >Affects Versions: 1.6 >Reporter: Michael Osipov >Assignee: Michael Osipov > > The usage of sole Velocity templates disables resources copying and other > processes. Using skins is recommended. Let's deprecate this and support skins > only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-149) Create a skin descriptor to contain metadata about the skin
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed DOXIASITETOOLS-149.
-
Resolution: Fixed
Version upated in [r1729489|http://svn.apache.org/r1729489].
> Create a skin descriptor to contain metadata about the skin
> ---
>
> Key: DOXIASITETOOLS-149
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-149
> Project: Maven Doxia Sitetools
> Issue Type: New Feature
> Components: Site renderer, Skin model
>Affects Versions: 1.6
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
>
> currently, a skin is a jar containing at least {{META-INF/maven/site.vm}},
> which is the Velocity template file
> adding a skin descriptor (as XML with Modello, to be consistent with Maven
> style) would permit meta-data definition.
> The first case I see is Doxia Site Tools prerequisites, to have a skin make
> clear that it requires a newer version of Doxia Site Tools (which is a
> dependency of maven-site-plugin = what end-users see): this would permit
> newer Doxia Site Tools versions to provide new features for skins (like
> DOXIASITETOOLS-150) and skins using these features without fearing failing
> because being used in older maven-site-plugin versions
> this would also create a new "skin-model" module that would give us a natural
> place to document practices around skins
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-149) Create a skin descriptor to contain metadata about the skin
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139909#comment-15139909
]
Hudson commented on DOXIASITETOOLS-149:
---
SUCCESS: Integrated in doxia-all #249 (See
[https://builds.apache.org/job/doxia-all/249/])
[DOXIASITETOOLS-149] first version is 1.7.0 (hboutemy:
[http://svn.apache.org/viewvc/?view=rev&rev=1729489])
* ./doxia-sitetools/doxia-skin-model/pom.xml
> Create a skin descriptor to contain metadata about the skin
> ---
>
> Key: DOXIASITETOOLS-149
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-149
> Project: Maven Doxia Sitetools
> Issue Type: New Feature
> Components: Site renderer, Skin model
>Affects Versions: 1.6
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
>
> currently, a skin is a jar containing at least {{META-INF/maven/site.vm}},
> which is the Velocity template file
> adding a skin descriptor (as XML with Modello, to be consistent with Maven
> style) would permit meta-data definition.
> The first case I see is Doxia Site Tools prerequisites, to have a skin make
> clear that it requires a newer version of Doxia Site Tools (which is a
> dependency of maven-site-plugin = what end-users see): this would permit
> newer Doxia Site Tools versions to provide new features for skins (like
> DOXIASITETOOLS-150) and skins using these features without fearing failing
> because being used in older maven-site-plugin versions
> this would also create a new "skin-model" module that would give us a natural
> place to document practices around skins
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-154) Add encoding to skin descriptor to define the encoding of site.vm
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139907#comment-15139907
]
Michael Osipov commented on DOXIASITETOOLS-154:
---
I would even extend the title, we could even apply the encoding to all text
files which we would read in with a reader, not only {{site.vm}}. WDYT?
> Add encoding to skin descriptor to define the encoding of site.vm
> -
>
> Key: DOXIASITETOOLS-154
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154
> Project: Maven Doxia Sitetools
> Issue Type: New Feature
> Components: Site renderer, Skin model
>Affects Versions: 1.7
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
>
> currently, Velocity parses site.vm template with its default encoding: a skin
> should be able to define its template encoding
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-154) Add encoding to skin descriptor to define the encoding of site.vm
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIASITETOOLS-154: -- Summary: Add encoding to skin descriptor to define the encoding of site.vm (was: add encoding to skin descriptor to define the encoding of site.vm) > Add encoding to skin descriptor to define the encoding of site.vm > - > > Key: DOXIASITETOOLS-154 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer, Skin model >Affects Versions: 1.7 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > currently, Velocity parses site.vm template with its default encoding: a skin > should be able to define its template encoding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-148) Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139884#comment-15139884
]
Michael Osipov commented on DOXIASITETOOLS-148:
---
I just don't want this to be forgotten for years in JIRA...
> Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
>
>
> Key: DOXIASITETOOLS-148
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-148
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> The field {{publishDate}} has been introduced DOXIATESITETOOLS-63 but cannot
> be set anywhere. Either provide a sane setting option including proper
> documentation or drop it completely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5626) Avoid negative durations or handle them correctly
[
https://issues.apache.org/jira/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139879#comment-15139879
]
Michael Osipov commented on MNG-5626:
-
No one's talking about a replacement for a timestamp but merely not to
calculate elapsed time based on {{System.currentTimeMillis()}} but only on
{{System.nanoTime()}}.
> Avoid negative durations or handle them correctly
> -
>
> Key: MNG-5626
> URL: https://issues.apache.org/jira/browse/MNG-5626
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.1
>Reporter: Christian Jung
>Priority: Minor
>
> In issue MNG-5623 we reported an exception when printing the reactor summary
> if one of the times was negative.
> I saw in one case, that the overall maven build time, as measured from
> outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
> reactor summary was:
> {code}
> 13:55:25,184 INFO - Reactor Summary:
> 13:55:25,184 INFO -
> 13:55:25,184 INFO - module1 ...
> SUCCESS [ 5.911 s]
> 13:55:25,184 INFO - module2 ...
> SUCCESS [ 0.255 s]
> 13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
> SUCCESS [-27.-64 s]
> 13:55:25,185 INFO -
>
> 13:55:25,185 INFO - BUILD SUCCESS
> 13:55:25,185 INFO -
>
> 13:55:25,185 INFO - Total time: -20.-73 s
> 13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
> 13:55:25,572 INFO - Final Memory: 32M/439M
> 13:55:25,572 INFO -
>
> {code}
> The thing is quite hard to reproduce, the machines were virtual machines that
> have been running for quite a long time.
> Our administrators suspected that just at this point, the local clock was
> synchronized with some outer source.
> We should check if such negative durations can be avoided, and if not, they
> should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSITE-765) upgrade Doxia from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-765: Description: Release Notes - Maven Doxia - Version 1.7 Bug * [DOXIA-482] - add an API to avoid translating APT source comments into output comments * [DOXIA-485] - Outdated links in xdoc format description * [DOXIA-508] - Format characters are interpreted in monospaced text * [DOXIA-524] - ISO-8859-15 encoding problem with markdown * [DOXIA-537] - NullPointerException parsing table cell with single space Improvement * [DOXIA-203] - Add support for level 6 sections and generalize Sink API for sections * [DOXIA-492] - Add support for doxia macros in markdown documents. * [DOXIA-505] - Upgrade to Commons Configuration 1.10 * [DOXIA-527] - Allow multiple extensions for given format * [DOXIA-529] - Add macro support to XHTML New Feature * [DOXIA-224] - Add source name in parser * [DOXIA-532] - Update handling of comments for Server Side Includes (ie comments starting with #) * [DOXIA-535] - Support .markdown file extension (in addition to current .md) Task * [DOXIA-511] - remove deprecated o.a.m.doxia.module.site package * [DOXIA-526] - remove xerces:xercesImpl dependency * [DOXIA-531] - improve MacroRequest API with parser and sourceContent parameters requirements Wish * [DOXIA-506] - move classes from doxia-core in sink package (same as doxia-sink-api) to dedicated sink.impl package was: Release Notes - Maven Doxia - Version 1.7 Bug * [DOXIA-482] - add an API to avoid translating APT source comments into output comments * [DOXIA-485] - Outdated links in xdoc format description * [DOXIA-508] - Format characters are interpreted in monospaced text * [DOXIA-524] - ISO-8859-15 encoding problem with markdown * [DOXIA-537] - NullPointerException parsing table cell with single space Improvement * [DOXIA-203] - Add support for level 6 sections and generalize Sink API for sections * [DOXIA-492] - Add support for doxia macros in markdown documents. * [DOXIA-505] - Upgrade to Commons Configuration 1.10 * [DOXIA-527] - Allow multiple extensions for given format * [DOXIA-529] - Add macro support to XHTML New Feature * [DOXIA-224] - Add source name in parser * [DOXIA-532] - Update handling of comments for Server Side Includes (ie comments starting with #) * [DOXIA-535] - Support .markdown file extension (in addition to current .md) > upgrade Doxia from 1.6 to 1.7 > - > > Key: MSITE-765 > URL: https://issues.apache.org/jira/browse/MSITE-765 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Release Notes - Maven Doxia - Version 1.7 > Bug > * [DOXIA-482] - add an API to avoid translating APT source comments into > output comments > * [DOXIA-485] - Outdated links in xdoc format description > * [DOXIA-508] - Format characters are interpreted in monospaced text > * [DOXIA-524] - ISO-8859-15 encoding problem with markdown > * [DOXIA-537] - NullPointerException parsing table cell with single space > Improvement > * [DOXIA-203] - Add support for level 6 sections and generalize Sink API > for sections > * [DOXIA-492] - Add support for doxia macros in markdown documents. > * [DOXIA-505] - Upgrade to Commons Configuration 1.10 > * [DOXIA-527] - Allow multiple extensions for given format > * [DOXIA-529] - Add macro support to XHTML > New Feature > * [DOXIA-224] - Add source name in parser > * [DOXIA-532] - Update handling of comments for Server Side Includes (ie > comments starting with #) > * [DOXIA-535] - Support .markdown file extension (in addition to current > .md) > Task > * [DOXIA-511] - remove deprecated o.a.m.doxia.module.site package > * [DOXIA-526] - remove xerces:xercesImpl dependency > * [DOXIA-531] - improve MacroRequest API with parser and sourceContent > parameters requirements > Wish > * [DOXIA-506] - move classes from doxia-core in sink package (same as > doxia-sink-api) to dedicated sink.impl package -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-765) upgrade Doxia from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSITE-765. --- Resolution: Fixed > upgrade Doxia from 1.6 to 1.7 > - > > Key: MSITE-765 > URL: https://issues.apache.org/jira/browse/MSITE-765 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Release Notes - Maven Doxia - Version 1.7 > Bug > * [DOXIA-482] - add an API to avoid translating APT source comments into > output comments > * [DOXIA-485] - Outdated links in xdoc format description > * [DOXIA-508] - Format characters are interpreted in monospaced text > * [DOXIA-524] - ISO-8859-15 encoding problem with markdown > * [DOXIA-537] - NullPointerException parsing table cell with single space > Improvement > * [DOXIA-203] - Add support for level 6 sections and generalize Sink API > for sections > * [DOXIA-492] - Add support for doxia macros in markdown documents. > * [DOXIA-505] - Upgrade to Commons Configuration 1.10 > * [DOXIA-527] - Allow multiple extensions for given format > * [DOXIA-529] - Add macro support to XHTML > New Feature > * [DOXIA-224] - Add source name in parser > * [DOXIA-532] - Update handling of comments for Server Side Includes (ie > comments starting with #) > * [DOXIA-535] - Support .markdown file extension (in addition to current > .md) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-765) upgrade Doxia from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139847#comment-15139847 ] Hudson commented on MSITE-765: -- UNSTABLE: Integrated in maven-plugins #5077 (See [https://builds.apache.org/job/maven-plugins/5077/]) [MSITE-765] upgraded Doxia from 1.6 to 1.7 (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1729456]) * maven-site-plugin/pom.xml > upgrade Doxia from 1.6 to 1.7 > - > > Key: MSITE-765 > URL: https://issues.apache.org/jira/browse/MSITE-765 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Release Notes - Maven Doxia - Version 1.7 > Bug > * [DOXIA-482] - add an API to avoid translating APT source comments into > output comments > * [DOXIA-485] - Outdated links in xdoc format description > * [DOXIA-508] - Format characters are interpreted in monospaced text > * [DOXIA-524] - ISO-8859-15 encoding problem with markdown > * [DOXIA-537] - NullPointerException parsing table cell with single space > Improvement > * [DOXIA-203] - Add support for level 6 sections and generalize Sink API > for sections > * [DOXIA-492] - Add support for doxia macros in markdown documents. > * [DOXIA-505] - Upgrade to Commons Configuration 1.10 > * [DOXIA-527] - Allow multiple extensions for given format > * [DOXIA-529] - Add macro support to XHTML > New Feature > * [DOXIA-224] - Add source name in parser > * [DOXIA-532] - Update handling of comments for Server Side Includes (ie > comments starting with #) > * [DOXIA-535] - Support .markdown file extension (in addition to current > .md) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-148) Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139752#comment-15139752
]
Robert Scholte commented on DOXIASITETOOLS-148:
---
correct, as long as there are only 24 hours in a day and there are other
projects which have higher prio for me :P
> Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
>
>
> Key: DOXIASITETOOLS-148
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-148
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> The field {{publishDate}} has been introduced DOXIATESITETOOLS-63 but cannot
> be set anywhere. Either provide a sane setting option including proper
> documentation or drop it completely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSITE-765) upgrade Doxia from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-765: Description: Release Notes - Maven Doxia - Version 1.7 Bug * [DOXIA-482] - add an API to avoid translating APT source comments into output comments * [DOXIA-485] - Outdated links in xdoc format description * [DOXIA-508] - Format characters are interpreted in monospaced text * [DOXIA-524] - ISO-8859-15 encoding problem with markdown * [DOXIA-537] - NullPointerException parsing table cell with single space Improvement * [DOXIA-203] - Add support for level 6 sections and generalize Sink API for sections * [DOXIA-492] - Add support for doxia macros in markdown documents. * [DOXIA-505] - Upgrade to Commons Configuration 1.10 * [DOXIA-527] - Allow multiple extensions for given format * [DOXIA-529] - Add macro support to XHTML New Feature * [DOXIA-224] - Add source name in parser * [DOXIA-532] - Update handling of comments for Server Side Includes (ie comments starting with #) * [DOXIA-535] - Support .markdown file extension (in addition to current .md) was: a lot of fixed issues and cleanup and new features: todo copy release notes once released > upgrade Doxia from 1.6 to 1.7 > - > > Key: MSITE-765 > URL: https://issues.apache.org/jira/browse/MSITE-765 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Release Notes - Maven Doxia - Version 1.7 > Bug > * [DOXIA-482] - add an API to avoid translating APT source comments into > output comments > * [DOXIA-485] - Outdated links in xdoc format description > * [DOXIA-508] - Format characters are interpreted in monospaced text > * [DOXIA-524] - ISO-8859-15 encoding problem with markdown > * [DOXIA-537] - NullPointerException parsing table cell with single space > Improvement > * [DOXIA-203] - Add support for level 6 sections and generalize Sink API > for sections > * [DOXIA-492] - Add support for doxia macros in markdown documents. > * [DOXIA-505] - Upgrade to Commons Configuration 1.10 > * [DOXIA-527] - Allow multiple extensions for given format > * [DOXIA-529] - Add macro support to XHTML > New Feature > * [DOXIA-224] - Add source name in parser > * [DOXIA-532] - Update handling of comments for Server Side Includes (ie > comments starting with #) > * [DOXIA-535] - Support .markdown file extension (in addition to current > .md) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSITE-755) upgrade Doxia Sitetools from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-755: Summary: upgrade Doxia Sitetools from 1.6 to 1.7 (was: upgrade Doxia and Doxia Sitetools from 1.6 to 1.7) > upgrade Doxia Sitetools from 1.6 to 1.7 > --- > > Key: MSITE-755 > URL: https://issues.apache.org/jira/browse/MSITE-755 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > a lot of fixed issues and cleanup > and new features: todo copy release notes once released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MSITE-765) upgrade Doxia from 1.6 to 1.7
Hervé Boutemy created MSITE-765: --- Summary: upgrade Doxia from 1.6 to 1.7 Key: MSITE-765 URL: https://issues.apache.org/jira/browse/MSITE-765 Project: Maven Site Plugin Issue Type: Improvement Components: doxia integration Affects Versions: 3.4 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 3.5 a lot of fixed issues and cleanup and new features: todo copy release notes once released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIA-540) Update/remove ancient information on Doxia site
[ https://issues.apache.org/jira/browse/DOXIA-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139663#comment-15139663 ] Hervé Boutemy commented on DOXIA-540: - no, no site Jira issue: no problem to keep this issue in DOXIA key > Update/remove ancient information on Doxia site > --- > > Key: DOXIA-540 > URL: https://issues.apache.org/jira/browse/DOXIA-540 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Affects Versions: 1.7 >Reporter: Michael Osipov > > Tasks to perform: > * Remove [Developer Docs|http://maven.apache.org/doxia/] for ancient versions. > * Remove Doxia IDE intergration is there is none working > * Remove [Upgrading|http://maven.apache.org/doxia/upgrading.html], it is > overhauled. > * Check [FAQ|http://maven.apache.org/doxia/faq.html] for validity. > * Merge [Apt > Enhancements|http://maven.apache.org/doxia/references/doxia-apt.html] into > [main site|http://maven.apache.org/doxia/references/apt-format.html]. > * Check [Issues|http://maven.apache.org/doxia/issues/index.html] for > validity. > * Update [External Resources|http://maven.apache.org/doxia/resources.html]. > * Remove ancient information from [Sink > API|http://maven.apache.org/doxia/doxia/doxia-sink-api/index.html]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-154) add encoding to skin descriptor to define the encoding of site.vm
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-154. Resolution: Fixed > add encoding to skin descriptor to define the encoding of site.vm > - > > Key: DOXIASITETOOLS-154 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-154 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer, Skin model >Affects Versions: 1.7 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > currently, Velocity parses site.vm template with its default encoding: a skin > should be able to define its template encoding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5626) Avoid negative durations or handle them correctly
[
https://issues.apache.org/jira/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139379#comment-15139379
]
Christian Schulte commented on MNG-5626:
{{System.currentTimeMillis()}} is affected by everything changing the system
clock. If e.g. a NTP client adjusts the system clock, negative durations can
occur. The javadoc of class {{java.util.time.Clock}} contains further
information (leap seconds, etc.). {{System.nanoTime()}} can only be used to
calculate durations. It's more like a VM uptime counter in nanoseconds. There
is no alternative to using {{System.currentTimeMillis()}} or
{{java.util.time.Clock.systemUTC()}} whenever a real timestamp is needed.
> Avoid negative durations or handle them correctly
> -
>
> Key: MNG-5626
> URL: https://issues.apache.org/jira/browse/MNG-5626
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.1
>Reporter: Christian Jung
>Priority: Minor
>
> In issue MNG-5623 we reported an exception when printing the reactor summary
> if one of the times was negative.
> I saw in one case, that the overall maven build time, as measured from
> outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
> reactor summary was:
> {code}
> 13:55:25,184 INFO - Reactor Summary:
> 13:55:25,184 INFO -
> 13:55:25,184 INFO - module1 ...
> SUCCESS [ 5.911 s]
> 13:55:25,184 INFO - module2 ...
> SUCCESS [ 0.255 s]
> 13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .
> SUCCESS [-27.-64 s]
> 13:55:25,185 INFO -
>
> 13:55:25,185 INFO - BUILD SUCCESS
> 13:55:25,185 INFO -
>
> 13:55:25,185 INFO - Total time: -20.-73 s
> 13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
> 13:55:25,572 INFO - Final Memory: 32M/439M
> 13:55:25,572 INFO -
>
> {code}
> The thing is quite hard to reproduce, the machines were virtual machines that
> have been running for quite a long time.
> Our administrators suspected that just at this point, the local clock was
> synchronized with some outer source.
> We should check if such negative durations can be avoided, and if not, they
> should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5934) String handling issues identified by PMD
[ https://issues.apache.org/jira/browse/MNG-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139314#comment-15139314 ] ASF GitHub Bot commented on MNG-5934: - Github user ChristianSchulte commented on the pull request: https://github.com/apache/maven/pull/72#issuecomment-181984267 This has been committed. See MNG-5934. Please close this pull request manually. > String handling issues identified by PMD > > > Key: MNG-5934 > URL: https://issues.apache.org/jira/browse/MNG-5934 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.9 >Reporter: Alex Henrie >Assignee: Christian Schulte >Priority: Minor > Labels: easyfix, newbie, patch, performance > Fix For: 3.4.0 > > Attachments: > 0001-Prefer-StringBuilder.append-char-to-StringBuilder.ap.patch, > 0002-Prefer-String.indexOf-char-to-String.indexOf-String.patch, > 0003-Combine-string-literals-instead-of-calling-String.ap.patch, > 0004-Construct-StringBuffers-with-enough-space-to-begin-w.patch > > > The code linting tool [PMD|http://pmd.sourceforge.net/pmd-5.2.0/] identified > numerous places where Maven's string handling is inefficient. I've prepared a > set of patches that should help speed things up. > The command I used was `pmd -d . -R java-strings` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139305#comment-15139305
]
ASF GitHub Bot commented on MNG-5940:
-
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/61#issuecomment-181983567
This has been committed. See MNG-5940. Please close this pull request
manually.
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5863: -- Assignee: Christian Schulte > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka >Assignee: Christian Schulte > Fix For: 3.4.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-5863. -- Resolution: Fixed Fix Version/s: 3.4.0 > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka >Assignee: Christian Schulte > Fix For: 3.4.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MNG-5863: > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka >Assignee: Christian Schulte > Fix For: 3.4.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MENFORCER-247) Add a "require file checksum" rule
[ https://issues.apache.org/jira/browse/MENFORCER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyubomyr Shaydariv updated MENFORCER-247: - Description: Hi. Sometimes there is a need to have a rule to check a file against a predefined checksum. Let's say, a result of a generated file in the build output directory is expected to result in a required checksum, or some source/test files must result in predefined checksums. I've came across such a rule on GitHub https://github.com/esamson/checksum-enforcer-rule and I think it would be nice to have this one as a standard rule. What I've done already: * Adapted the original source to the source code base in http://svn.apache.org/repos/asf/maven/enforcer/trunk (1.4.2-SNAPSHOT) * Added Apache Commons Codec 1.6 dependency thus adding support for MD5, SHA-1, SHA-256, SHA-384, SHA-512 * Added some tests * Added an example for all hashing functions to the generated site. What I'm not sure about: * Would you accept this feature as one that's worth be a part of standard rules. * If so, I'm not sure if https://github.com/apache/maven-enforcer accepts pull requests as I've noticed probably automatically generated `git-svn-id` field in `git log` output. So probably the patch might be committed to the Subversion repository first. Here is the patch diff on GitHub: https://github.com/lyubomyr-shaydariv/maven-enforcer/commit/86ed97423b5c64625f700c3afe555c02d6c619df was: Hi. Sometimes there is a need to have a rule to check a file against a predefined checksum. Let's say, a result of a generated file in the build output directory is expected to result in a required checksum, or some source/test files must result in predefined checksums. I've came across such a rule on GitHub https://github.com/esamson/checksum-enforcer-rule and I think it would be nice to have this one as a standard rule. What I've done already: * Adapted the original source to the source code base in http://svn.apache.org/repos/asf/maven/enforcer/trunk * Added Apache Commons Codec 1.6 dependency thus adding support for MD5, SHA-1, SHA-256, SHA-384, SHA-512 * Added some tests * Added an example for all hashing functions to the generated site. What I'm not sure about: * Would you accept this feature as one that's worth be a part of standard rules. * If so, I'm not sure if https://github.com/apache/maven-enforcer accepts pull requests as I've noticed probably automatically generated `git-svn-id` field in `git log` output. So probably the patch might be committed to the Subversion repository first. Here is the patch diff on GitHub: https://github.com/lyubomyr-shaydariv/maven-enforcer/commit/86ed97423b5c64625f700c3afe555c02d6c619df > Add a "require file checksum" rule > -- > > Key: MENFORCER-247 > URL: https://issues.apache.org/jira/browse/MENFORCER-247 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Lyubomyr Shaydariv > > Hi. > Sometimes there is a need to have a rule to check a file against a predefined > checksum. Let's say, a result of a generated file in the build output > directory is expected to result in a required checksum, or some source/test > files must result in predefined checksums. I've came across such a rule on > GitHub https://github.com/esamson/checksum-enforcer-rule and I think it would > be nice to have this one as a standard rule. > What I've done already: > * Adapted the original source to the source code base in > http://svn.apache.org/repos/asf/maven/enforcer/trunk (1.4.2-SNAPSHOT) > * Added Apache Commons Codec 1.6 dependency thus adding support for MD5, > SHA-1, SHA-256, SHA-384, SHA-512 > * Added some tests > * Added an example for all hashing functions to the generated site. > What I'm not sure about: > * Would you accept this feature as one that's worth be a part of standard > rules. > * If so, I'm not sure if https://github.com/apache/maven-enforcer accepts > pull requests as I've noticed probably automatically generated `git-svn-id` > field in `git log` output. So probably the patch might be committed to the > Subversion repository first. > Here is the patch diff on GitHub: > https://github.com/lyubomyr-shaydariv/maven-enforcer/commit/86ed97423b5c64625f700c3afe555c02d6c619df -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MENFORCER-247) Add a "require file checksum" rule
[ https://issues.apache.org/jira/browse/MENFORCER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyubomyr Shaydariv updated MENFORCER-247: - Affects Version/s: (was: 1.4.2) > Add a "require file checksum" rule > -- > > Key: MENFORCER-247 > URL: https://issues.apache.org/jira/browse/MENFORCER-247 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Lyubomyr Shaydariv > > Hi. > Sometimes there is a need to have a rule to check a file against a predefined > checksum. Let's say, a result of a generated file in the build output > directory is expected to result in a required checksum, or some source/test > files must result in predefined checksums. I've came across such a rule on > GitHub https://github.com/esamson/checksum-enforcer-rule and I think it would > be nice to have this one as a standard rule. > What I've done already: > * Adapted the original source to the source code base in > http://svn.apache.org/repos/asf/maven/enforcer/trunk > * Added Apache Commons Codec 1.6 dependency thus adding support for MD5, > SHA-1, SHA-256, SHA-384, SHA-512 > * Added some tests > * Added an example for all hashing functions to the generated site. > What I'm not sure about: > * Would you accept this feature as one that's worth be a part of standard > rules. > * If so, I'm not sure if https://github.com/apache/maven-enforcer accepts > pull requests as I've noticed probably automatically generated `git-svn-id` > field in `git log` output. So probably the patch might be committed to the > Subversion repository first. > Here is the patch diff on GitHub: > https://github.com/lyubomyr-shaydariv/maven-enforcer/commit/86ed97423b5c64625f700c3afe555c02d6c619df -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MENFORCER-247) Add a "require file checksum" rule
Lyubomyr Shaydariv created MENFORCER-247: Summary: Add a "require file checksum" rule Key: MENFORCER-247 URL: https://issues.apache.org/jira/browse/MENFORCER-247 Project: Maven Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.4.2 Reporter: Lyubomyr Shaydariv Hi. Sometimes there is a need to have a rule to check a file against a predefined checksum. Let's say, a result of a generated file in the build output directory is expected to result in a required checksum, or some source/test files must result in predefined checksums. I've came across such a rule on GitHub https://github.com/esamson/checksum-enforcer-rule and I think it would be nice to have this one as a standard rule. What I've done already: * Adapted the original source to the source code base in http://svn.apache.org/repos/asf/maven/enforcer/trunk * Added Apache Commons Codec 1.6 dependency thus adding support for MD5, SHA-1, SHA-256, SHA-384, SHA-512 * Added some tests * Added an example for all hashing functions to the generated site. What I'm not sure about: * Would you accept this feature as one that's worth be a part of standard rules. * If so, I'm not sure if https://github.com/apache/maven-enforcer accepts pull requests as I've noticed probably automatically generated `git-svn-id` field in `git log` output. So probably the patch might be committed to the Subversion repository first. Here is the patch diff on GitHub: https://github.com/lyubomyr-shaydariv/maven-enforcer/commit/86ed97423b5c64625f700c3afe555c02d6c619df -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIA-540) Update/remove ancient information on Doxia site
[ https://issues.apache.org/jira/browse/DOXIA-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138613#comment-15138613 ] Michael Osipov commented on DOXIA-540: -- You are right. The Doxia site does not have any project in JIRA or is there any? I'd like to track this issue anyway. > Update/remove ancient information on Doxia site > --- > > Key: DOXIA-540 > URL: https://issues.apache.org/jira/browse/DOXIA-540 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Affects Versions: 1.7 >Reporter: Michael Osipov > > Tasks to perform: > * Remove [Developer Docs|http://maven.apache.org/doxia/] for ancient versions. > * Remove Doxia IDE intergration is there is none working > * Remove [Upgrading|http://maven.apache.org/doxia/upgrading.html], it is > overhauled. > * Check [FAQ|http://maven.apache.org/doxia/faq.html] for validity. > * Merge [Apt > Enhancements|http://maven.apache.org/doxia/references/doxia-apt.html] into > [main site|http://maven.apache.org/doxia/references/apt-format.html]. > * Check [Issues|http://maven.apache.org/doxia/issues/index.html] for > validity. > * Update [External Resources|http://maven.apache.org/doxia/resources.html]. > * Remove ancient information from [Sink > API|http://maven.apache.org/doxia/doxia/doxia-sink-api/index.html]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-106) Set language for customizable resources
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138604#comment-15138604
]
Michael Osipov commented on DOXIASITETOOLS-106:
---
That is possible as long as the module/resource has localized files. You have
{{$locale.language}} which you can use. Provide a patch for the localizable
spots, ideally with an IT, and I will apply it.
> Set language for customizable resources
> ---
>
> Key: DOXIASITETOOLS-106
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-106
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Eric Barboni
>
> This idea came from issue MSKINS-118. Because any locale you have the gif
> file for google cse will allways be the english one and it may be nice to
> have the possibilty to use the locale for customizing resources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
