[jira] (MRESOURCES-145) Copying resources with no modication date silently is ignored
[
https://jira.codehaus.org/browse/MRESOURCES-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321936#comment-321936
]
Robert Scholte commented on MRESOURCES-145:
---
According to the JavaDoc
{quote}
*long java.io.File.lastModified()*
Returns the time that the file denoted by this abstract pathname was last
modified.
*Returns:*
A long value representing the time the file was last modified, measured in
milliseconds since the epoch (00:00:00 GMT, January 1, 1970), or 0L if the file
does not exist or if an I/O error occurs
{quote}
That would mean it's quite impossible to have {{0L}}, but I'm pretty sure I've
seen it, although not recently.
> Copying resources with no modication date silently is ignored
> -
>
> Key: MRESOURCES-145
> URL: https://jira.codehaus.org/browse/MRESOURCES-145
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.5
>Reporter: Bartolo
>
> If a file has no last modified date (File.lastModified() == 0), then the
> plugin just ignore it. This line in the file FileUtils.java of
> plexus-utils(2.0.5) is wrong:
> {{if ( to.lastModified() < from.lastModified() || overwrite )}}
> It will be evaluated to {{false}} always if {{overwrite}} flag is not set.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-166) Plugin fails when switching from 2.7.1 to 3.0.1
Brett VanderVeen created MPMD-166:
-
Summary: Plugin fails when switching from 2.7.1 to 3.0.1
Key: MPMD-166
URL: https://jira.codehaus.org/browse/MPMD-166
Project: Maven 2.x PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0
Reporter: Brett VanderVeen
Priority: Minor
Attachments: console.log, pom.xml
When running {{mvn clean deploy findbugs:findbugs}} on our modular Maven
project, we receive an *BUILD ERROR*: {{[PMD] No report found for mojo pmd}}
I have attached the console log and the pom file where the plugin is included
(parent pom for the project).
All that is changed is the version, from {{2.7.1}} to {{3.0.1}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency
[
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321933#comment-321933
]
Andreas Gudian commented on SUREFIRE-968:
-
> Netbeans does for example to populate the JUnit window output.
Meeh, thought so. I guess changing the output to something like the following
would _break_ quite a number of third party and user-created tooling:
{code}
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Finished org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest. Tests run: 1,
Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Finished org.jvnet.hudson.main.AppTest. Tests run: 2, Failures: 0, Errors: 0,
Skipped: 0, Time elapsed: 0.539 sec
Finished org.jvnet.hudson.test.MemoryAssertTest. Tests run: 1, Failures: 0,
Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
{code}
But how about this one?
{code}
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Finished org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Finished org.jvnet.hudson.main.AppTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.539 sec
Finished org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
{code}
I would guess that this would not break that many output parsers out there.
What do you think?
@Kristian: all the "live" output routing is already synced perfectly, you're
right. This is just about that output created in {{ConsoleReporter}} on
{{testSetStarting}} and {{testSetCompleted}}.
> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Priority: Minor
>
> When running multiple test suites in parallel, Surefire prints summaries of
> ongoing test counts, but it is not at all clear which results are being
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> â¦
> {code}
> It is impossible to tell which results correspond to which test, since there
> is no way to know which test will finish first. At best you can guess based
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency
[
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321933#comment-321933
]
Andreas Gudian edited comment on SUREFIRE-968 at 3/13/13 2:56 PM:
--
> Netbeans does for example to populate the JUnit window output.
Meeh, thought so. I guess changing the output to something like the following
would _break_ quite a number of third party and user-created tooling (plus,
it's harder to read):
{code}
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Finished org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest. Tests run: 1,
Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Finished org.jvnet.hudson.main.AppTest. Tests run: 2, Failures: 0, Errors: 0,
Skipped: 0, Time elapsed: 0.539 sec
Finished org.jvnet.hudson.test.MemoryAssertTest. Tests run: 1, Failures: 0,
Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
{code}
But how about this one?
{code}
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Finished org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Finished org.jvnet.hudson.main.AppTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.539 sec
Finished org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
{code}
I would guess that this would not break that many output parsers out there.
What do you think?
@Kristian: all the "live" output routing is already synced perfectly, you're
right. This is just about that output created in {{ConsoleReporter}} on
{{testSetStarting}} and {{testSetCompleted}}.
was (Author: agudian):
> Netbeans does for example to populate the JUnit window output.
Meeh, thought so. I guess changing the output to something like the following
would _break_ quite a number of third party and user-created tooling:
{code}
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Finished org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest. Tests run: 1,
Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Finished org.jvnet.hudson.main.AppTest. Tests run: 2, Failures: 0, Errors: 0,
Skipped: 0, Time elapsed: 0.539 sec
Finished org.jvnet.hudson.test.MemoryAssertTest. Tests run: 1, Failures: 0,
Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
{code}
But how about this one?
{code}
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Finished org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Finished org.jvnet.hudson.main.AppTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.539 sec
Finished org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
{code}
I would guess that this would not break that many output parsers out there.
What do you think?
@Kristian: all the "live" output routing is already synced perfectly, you're
right. This is just about that output created in {{ConsoleReporter}} on
{{testSetStarting}} and {{testSetCompleted}}.
> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Priority: Minor
>
> When running multiple test suites in parallel, Surefire prints summaries of
> ongoing test counts, but it is not at all clear which results are being
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run:
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
[ https://jira.codehaus.org/browse/MNG-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch closed MNG-5453. - Resolution: Fixed Fix Version/s: 3.1.0 Patch applied in https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=2c2bf6e6e5b06c35a935ca69c5dcb54b381baf46 > Update Maven 3 build to use Eclipse/Sisu > > > Key: MNG-5453 > URL: https://jira.codehaus.org/browse/MNG-5453 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Stuart McCulloch > Fix For: 3.1.0 > > > Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy > configurators bundled as part of the original Sisu build. These were the only > classes that couldn't be moved to Eclipse as I wasn't 100% sure about their > IP history. > Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators > written from scratch that build on Sisu's bean reflection/converter code. > These new configurators were written (and tested) indirectly by looking at > the behaviour of the old configurators while running various ITs, so it's > possible that some inconsistencies remain. > So while the build passes all ITs locally, it would be worthwhile getting > wider testing to make sure that I haven't accidentally regressed anything > with the new configurator code :) > PS. the Eclipse/Sisu artifacts don't shade their internal dependencies > (unlike the original Sisu bundles) so you'll see additional jars in lib, such > as asm and guava. Also note that the guava dependency version is managed to > be 11.0.2, which is the last known Java5 compatible release. > [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency
[
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321926#comment-321926
]
Kristian Rosenvold commented on SUREFIRE-968:
-
This should actually be fairly easy to fix, since its all about synchronizing
the playback of the captured output data. Im a bit surprised this actually isnt
the case already, but I believe you guys ;)
> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Priority: Minor
>
> When running multiple test suites in parallel, Surefire prints summaries of
> ongoing test counts, but it is not at all clear which results are being
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> â¦
> {code}
> It is impossible to tell which results correspond to which test, since there
> is no way to know which test will finish first. At best you can guess based
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency
[
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321925#comment-321925
]
Milos Kleint commented on SUREFIRE-968:
---
> @Kristian: do you know of any major third party tools that parse that output
> (on stdout or in the txt file)?
Netbeans does for example to populate the JUnit window output.
> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Priority: Minor
>
> When running multiple test suites in parallel, Surefire prints summaries of
> ongoing test counts, but it is not at all clear which results are being
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> â¦
> {code}
> It is impossible to tell which results correspond to which test, since there
> is no way to know which test will finish first. At best you can guess based
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5352) Upgrade sisu to v2.3.1
[ https://jira.codehaus.org/browse/MNG-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed MNG-5352. -- Resolution: Duplicate Closing as superceded by MNG-5453. > Upgrade sisu to v2.3.1 > -- > > Key: MNG-5352 > URL: https://jira.codehaus.org/browse/MNG-5352 > Project: Maven 2 & 3 > Issue Type: Task > Components: Dependencies > Environment: n/a >Reporter: Anders Hammar > > To prepare for a future switch TO Eclipse Sisu, I think we should upgrade to > the released v2.3.1 of Sonatype Sisu. According to info from Stuart McCulloch > to the dev list: > "This is based on the tagged Eclipse/Sisu 0.0.0.M0 source, automatically > fetched and repackaged back to the old namespace. > The goal of this release was to validate the initial contribution [to > Eclipse], and provide a route to get (future) bugfixes to old Sisu clients." > Stuart has run the Maven core ITs against this version and verified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency
[
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321923#comment-321923
]
Andreas Gudian commented on SUREFIRE-968:
-
You're right, that's a bit annoying.
@Kristian: do you know of any major third party tools that parse that output
(on stdout or in the txt file)?
> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Priority: Minor
>
> When running multiple test suites in parallel, Surefire prints summaries of
> ongoing test counts, but it is not at all clear which results are being
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> â¦
> {code}
> It is impossible to tell which results correspond to which test, since there
> is no way to know which test will finish first. At best you can guess based
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5331) JavaFX should be added to compilation classpath
[ https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321914#comment-321914 ] Milos Kleint commented on MNG-5331: --- I believe the problem mentioned by Konstantin is that the javafx.jar expects native libs at some hardcoded relative path (as in the JDK/JRE) and without it will fail at runtime AFAIK. > JavaFX should be added to compilation classpath > --- > > Key: MNG-5331 > URL: https://jira.codehaus.org/browse/MNG-5331 > Project: Maven 2 & 3 > Issue Type: Wish >Reporter: Konstantin Solomatov > > Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include > them into classpath automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5331) JavaFX should be added to compilation classpath
[
https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321913#comment-321913
]
Jaroslav Tulach commented on MNG-5331:
--
Btw. the system dependency does not need absolute path. It can be relative to
JAVA_HOME:
com.oracle
javafx
2.2
system
${java.home}/lib/jfxrt.jar
> JavaFX should be added to compilation classpath
> ---
>
> Key: MNG-5331
> URL: https://jira.codehaus.org/browse/MNG-5331
> Project: Maven 2 & 3
> Issue Type: Wish
>Reporter: Konstantin Solomatov
>
> Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include
> them into classpath automatically.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321910#comment-321910
]
Stuart McCulloch edited comment on MNG-5445 at 3/13/13 8:27 AM:
Patch applied by Olivier Lamy in
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=c9eecc8f0c220da665a448d5f3579f533b03119f
Verified, thanks!
was (Author: mcculls):
Verified, thanks!
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch closed MNG-5445.
-
Resolution: Fixed
Verified, thanks!
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-484) pegdown dependency is 3 revisions out of date
[
https://jira.codehaus.org/browse/DOXIA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321909#comment-321909
]
Malachi de AElfweald commented on DOXIA-484:
I spent a little time between meetings looking at this yesterday. There wasn't
much code change required (copying one method from a prior tag, removing a
parameter from another call, etc). It compiled OK, but the tests didn't pass.
I'll try to look into it some more if I get a chance.
> pegdown dependency is 3 revisions out of date
> -
>
> Key: DOXIA-484
> URL: https://jira.codehaus.org/browse/DOXIA-484
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /usr/local/maven
> Java version: 1.6.0_41, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.5.0-25-generic", arch: "amd64", family: "unix"
>Reporter: Malachi de AElfweald
>Priority: Minor
>
> From the CHANGELOG
> {noformat}
> Version 1.2.1 (2011-11-27)
> --
> - Upgraded to parboiled 1.1.4
> - Added support for caption on tables (thx to Geoffrey Picron)
> Version 1.2.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.1.3
> - Implemented parsing timeout, closes #42
> - Fixed IndexOutOfBoundsException in ToHtmlSerializer, closes #39
> - Changed parser to not swallow backslash before non-special characters,
> fixes #35
> - Added test for fenced code blocks containing an empty line, closes #61
> - Migrated all tests from TestNG to specs2
> - Switched build tool from Apache Buildr to SBT
> Version 1.1.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.0.2
> - Introduced LinkRenderer layer for easy customization of HTML link rendering
> - Added support for [[Wiki-style]] links, thx to Brett Porter
> - Fixed #27 (Missing emphasis when paragraph has multiple lines)
> - Fixed #28 (Parser not fully extensible)
> - Fixed #32, #33 (HTML tags with attribute names containing underscores are
> not recognized as tags, thx to Edward Samson)
> - Fixed #34 (Pathologically slow parsing when strong and italics emphasis are
> applied together)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
[ https://jira.codehaus.org/browse/MNG-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321908#comment-321908 ] Stuart McCulloch edited comment on MNG-5453 at 3/13/13 8:19 AM: Correct, marked this issue as superceding MNG-5352 (I don't have enough karma to close that issue). was (Author: mcculls): Correct, marked this issue as superceding MNG-5352 > Update Maven 3 build to use Eclipse/Sisu > > > Key: MNG-5453 > URL: https://jira.codehaus.org/browse/MNG-5453 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Stuart McCulloch > > Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy > configurators bundled as part of the original Sisu build. These were the only > classes that couldn't be moved to Eclipse as I wasn't 100% sure about their > IP history. > Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators > written from scratch that build on Sisu's bean reflection/converter code. > These new configurators were written (and tested) indirectly by looking at > the behaviour of the old configurators while running various ITs, so it's > possible that some inconsistencies remain. > So while the build passes all ITs locally, it would be worthwhile getting > wider testing to make sure that I haven't accidentally regressed anything > with the new configurator code :) > PS. the Eclipse/Sisu artifacts don't shade their internal dependencies > (unlike the original Sisu bundles) so you'll see additional jars in lib, such > as asm and guava. Also note that the guava dependency version is managed to > be 11.0.2, which is the last known Java5 compatible release. > [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-279) Empty maven.home should be treated like if it was unset
[ https://jira.codehaus.org/browse/MSHARED-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikolaj Izdebski updated MSHARED-279: - Attachment: maven-invoker-MSHARED-279.patch > Empty maven.home should be treated like if it was unset > --- > > Key: MSHARED-279 > URL: https://jira.codehaus.org/browse/MSHARED-279 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-invoker >Affects Versions: maven-invoker-2.1.1, maven-invoker-2.1.2 >Reporter: Mikolaj Izdebski > Attachments: maven-invoker-MSHARED-279.patch > > > In my opinion if maven.home system property is defined to an empty string > then it should be treated as if it was undefined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-279) Empty maven.home should be treated like if it was unset
Mikolaj Izdebski created MSHARED-279: Summary: Empty maven.home should be treated like if it was unset Key: MSHARED-279 URL: https://jira.codehaus.org/browse/MSHARED-279 Project: Maven Shared Components Issue Type: Improvement Components: maven-invoker Affects Versions: maven-invoker-2.1.1, maven-invoker-2.1.2 Reporter: Mikolaj Izdebski Attachments: maven-invoker-MSHARED-279.patch In my opinion if maven.home system property is defined to an empty string then it should be treated as if it was undefined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-278) NullPointerException in MavenCommandLineBuilder
[ https://jira.codehaus.org/browse/MSHARED-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikolaj Izdebski updated MSHARED-278: - Attachment: maven-invoker-MSHARED-278.patch > NullPointerException in MavenCommandLineBuilder > --- > > Key: MSHARED-278 > URL: https://jira.codehaus.org/browse/MSHARED-278 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-invoker >Affects Versions: maven-invoker-2.1.1, maven-invoker-2.1.2 >Reporter: Mikolaj Izdebski > Attachments: maven-invoker-MSHARED-278.patch > > > maven invoker assumes that mavenHome has parent directory. If this assumprion > is false (for example maven.home is root directory "/") then > NullPointerException is thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-278) NullPointerException in MavenCommandLineBuilder
Mikolaj Izdebski created MSHARED-278: Summary: NullPointerException in MavenCommandLineBuilder Key: MSHARED-278 URL: https://jira.codehaus.org/browse/MSHARED-278 Project: Maven Shared Components Issue Type: Bug Components: maven-invoker Affects Versions: maven-invoker-2.1.1, maven-invoker-2.1.2 Reporter: Mikolaj Izdebski maven invoker assumes that mavenHome has parent directory. If this assumprion is false (for example maven.home is root directory "/") then NullPointerException is thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-829) ${project.version} is not replaced during release
[
https://jira.codehaus.org/browse/MRELEASE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321889#comment-321889
]
Lukasz Dywicki commented on MRELEASE-829:
-
Workaround is to use exact version (1.0-SNAPSHOT) instead project.version
expression. Guilty is
[AbstractRewritePomsPhase.java#L534|https://github.com/apache/maven-release/blob/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#L534]?
> ${project.version} is not replaced during release
> -
>
> Key: MRELEASE-829
> URL: https://jira.codehaus.org/browse/MRELEASE-829
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven 3.0.5
>Reporter: Lukasz Dywicki
>
> I have small project with organization parent and checkstyle resources
> packaged as JAR and built as parent sub-module.
> The checkstyle module is added as dependency to maven-checkstyle-plugin
> defined in parent:
> {{code:java}}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
> code-house/checkstyle.xml
> false
> false
>
>
>
> org.code-house
> checkstyle
> ${project.version}
> true
>
>
>
> {{code}}
> After release ${project.version} is not being replaced and released pom still
> contains ${project.version}. This causes usage of version from 3rd party
> child modules which should inherit settings from parent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-163) PMD issues are reported multiple times
[
https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321887#comment-321887
]
Florent PAILLARD commented on MPMD-163:
---
Hello Oliver,
Thanks for having released the 3.0.1 quickly. It's easier to maven-release with
no -SNAPSHOT version of plugins within our POM!
> PMD issues are reported multiple times
> --
>
> Key: MPMD-163
> URL: https://jira.codehaus.org/browse/MPMD-163
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0
> Environment: Apache Maven 3.0.4
> Sun jdk1.6.0_04 on Debian Lenny
> Oracle jdk 1.7.0_13 on Mac OS X (10.8.2)
>Reporter: Mirko Friedenhagen
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 3.0.1
>
> Attachments: MPMD-163-against-tag-3.0.patch, my-app.zip
>
>
> After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects
> the number of pmd violations exploded. Some are valid (new rules), however I
> have a project where the same violation will show up more than 70 times!
> See below for an example of this dramatic outcome:
> {code}
> [mifr@host SomeService]$ grep '^ 3682 44655 1239557
> [mifr@host SomeService]$ grep '^ 921120 30832
> {code}
> The number of source files in this project in total is 96, so a wild guess
> would be, that the plugin readds already existing violations (the first
> (unique) violation occurs once, the second 4 times and so on). I will try t
> take a look at the source code or to get a working testcase.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-26) Jar Signer does not support protected authentication path
[ https://jira.codehaus.org/browse/MJARSIGNER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321885#comment-321885 ] Michael Gruebsch commented on MJARSIGNER-26: The issue is classified as bug because the jarsigner plugin as of version 1.2 is unable to cope with protected authentication paths. > Jar Signer does not support protected authentication path > - > > Key: MJARSIGNER-26 > URL: https://jira.codehaus.org/browse/MJARSIGNER-26 > Project: Maven 2.x Jar Signer Plugin > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Michael Gruebsch > Attachments: maven-jarsigner-1.0.patch, > maven-jarsigner-plugin-1.2.patch > > > The jarsigner tool has an option "-protected" (see > http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html#Options, > documentation for option -storetype): a PCKS#11 token may have a protected > authentication path (such as a dedicated PIN-pad or a biometric reader). In > such case the -protected option must be specified and no password options can > be specified. > The current version does not support this option. Please find patches for > maven-jarsigner-1.0 and maven-jarsigner-plugin (Version 1.3-SNAPSHOT) > attached. > Testcases are left out because a pin reader, a PCKS#11 smart card and human > interaction would be necessary to test this scenario. However, the patched > version works fine in my environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-483) (SwfMacro) org.apache.maven.plugins:maven-site-plugin:3.2:site: org.apache.maven.doxia.module.apt.AptParser cannot be cast to java.lang.String
[ https://jira.codehaus.org/browse/DOXIA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321884#comment-321884 ] Manuel Blechschmidt commented on DOXIA-483: --- http://mail-archives.apache.org/mod_mbox/maven-dev/201303.mbox/ajax/%3C884FBB0A-DC03-4E91-A2E5-9E5562E7CCE9%40gmx.de%3E > (SwfMacro) org.apache.maven.plugins:maven-site-plugin:3.2:site: > org.apache.maven.doxia.module.apt.AptParser cannot be cast to java.lang.String > -- > > Key: DOXIA-483 > URL: https://jira.codehaus.org/browse/DOXIA-483 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: /usr/share/maven > Java version: 1.6.0_41, vendor: Apple Inc. > Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.5", arch: "x86_64", family: "mac" >Reporter: Manuel Blechschmidt > Attachments: DOXIA-SWF-BUG.patch, DOXIA-SWF-BUG.tgz, Screen Shot > 2013-02-22 at 17.56.12.png > > > # Download the attached tgz file > # Open a console > # Enter "tar xzf DOXIA-SWF-BUG.tgz" > # "cd DOXIA-SWF-BUG" > # run "mvn -X site" > Expected: > * System should generate a cool maven site with a cool embedded movie > Actual: > * Doxia crashes with the following Exception > Caused by: java.lang.ClassCastException: > org.apache.maven.doxia.module.apt.AptParser cannot be cast to java.lang.String > at org.apache.maven.doxia.macro.SwfMacro.execute(SwfMacro.java:57) > at > org.apache.maven.doxia.parser.AbstractParser.executeMacro(AbstractParser.java:120) > at > org.apache.maven.doxia.module.apt.AptParser$MacroBlock.traverse(AptParser.java:2919) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:861) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:807) > at > org.apache.maven.doxia.module.apt.AptParser.traverseBody(AptParser.java:758) > at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:228) > at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:63) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:401) > at > org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... 20 more > Some of the plugins that I am using are putting a parser variable into one of > the maps. This parser variable should be ignored by the SwfMacro but isn't. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-829) ${project.version} is not replaced during release
Lukasz Dywicki created MRELEASE-829:
---
Summary: ${project.version} is not replaced during release
Key: MRELEASE-829
URL: https://jira.codehaus.org/browse/MRELEASE-829
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Maven 3.0.5
Reporter: Lukasz Dywicki
I have small project with organization parent and checkstyle resources packaged
as JAR and built as parent sub-module.
The checkstyle module is added as dependency to maven-checkstyle-plugin defined
in parent:
{{code:java}}
org.apache.maven.plugins
maven-checkstyle-plugin
code-house/checkstyle.xml
false
false
org.code-house
checkstyle
${project.version}
true
{{code}}
After release ${project.version} is not being replaced and released pom still
contains ${project.version}. This causes usage of version from 3rd party child
modules which should inherit settings from parent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-483) (SwfMacro) org.apache.maven.plugins:maven-site-plugin:3.2:site: org.apache.maven.doxia.module.apt.AptParser cannot be cast to java.lang.String
[ https://jira.codehaus.org/browse/DOXIA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321883#comment-321883 ] Manuel Blechschmidt commented on DOXIA-483: --- Tried to start discussion on maven-dev list to get this included into doxia-core: http://mail-archives.apache.org/mod_mbox/maven-dev/201303.mbox/browser > (SwfMacro) org.apache.maven.plugins:maven-site-plugin:3.2:site: > org.apache.maven.doxia.module.apt.AptParser cannot be cast to java.lang.String > -- > > Key: DOXIA-483 > URL: https://jira.codehaus.org/browse/DOXIA-483 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: /usr/share/maven > Java version: 1.6.0_41, vendor: Apple Inc. > Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.5", arch: "x86_64", family: "mac" >Reporter: Manuel Blechschmidt > Attachments: DOXIA-SWF-BUG.patch, DOXIA-SWF-BUG.tgz, Screen Shot > 2013-02-22 at 17.56.12.png > > > # Download the attached tgz file > # Open a console > # Enter "tar xzf DOXIA-SWF-BUG.tgz" > # "cd DOXIA-SWF-BUG" > # run "mvn -X site" > Expected: > * System should generate a cool maven site with a cool embedded movie > Actual: > * Doxia crashes with the following Exception > Caused by: java.lang.ClassCastException: > org.apache.maven.doxia.module.apt.AptParser cannot be cast to java.lang.String > at org.apache.maven.doxia.macro.SwfMacro.execute(SwfMacro.java:57) > at > org.apache.maven.doxia.parser.AbstractParser.executeMacro(AbstractParser.java:120) > at > org.apache.maven.doxia.module.apt.AptParser$MacroBlock.traverse(AptParser.java:2919) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:861) > at > org.apache.maven.doxia.module.apt.AptParser.traverseSection(AptParser.java:807) > at > org.apache.maven.doxia.module.apt.AptParser.traverseBody(AptParser.java:758) > at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:228) > at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:63) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:401) > at > org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... 20 more > Some of the plugins that I am using are putting a parser variable into one of > the maps. This parser variable should be ignored by the SwfMacro but isn't. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
[ https://jira.codehaus.org/browse/MNG-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321879#comment-321879 ] Anders Hammar commented on MNG-5453: Would this then supercede MNG-5352? > Update Maven 3 build to use Eclipse/Sisu > > > Key: MNG-5453 > URL: https://jira.codehaus.org/browse/MNG-5453 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Stuart McCulloch > > Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy > configurators bundled as part of the original Sisu build. These were the only > classes that couldn't be moved to Eclipse as I wasn't 100% sure about their > IP history. > Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators > written from scratch that build on Sisu's bean reflection/converter code. > These new configurators were written (and tested) indirectly by looking at > the behaviour of the old configurators while running various ITs, so it's > possible that some inconsistencies remain. > So while the build passes all ITs locally, it would be worthwhile getting > wider testing to make sure that I haven't accidentally regressed anything > with the new configurator code :) > PS. the Eclipse/Sisu artifacts don't shade their internal dependencies > (unlike the original Sisu bundles) so you'll see additional jars in lib, such > as asm and guava. Also note that the guava dependency version is managed to > be 11.0.2, which is the last known Java5 compatible release. > [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-484) pegdown dependency is 3 revisions out of date
[
https://jira.codehaus.org/browse/DOXIA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321878#comment-321878
]
Kristian Rosenvold commented on DOXIA-484:
--
I had a look at this some time ago and the upgrade is not just a simple matter
of upgrading the dependency. If someone takes the time to fix this issue I will
definitely review such a patch
> pegdown dependency is 3 revisions out of date
> -
>
> Key: DOXIA-484
> URL: https://jira.codehaus.org/browse/DOXIA-484
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /usr/local/maven
> Java version: 1.6.0_41, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.5.0-25-generic", arch: "amd64", family: "unix"
>Reporter: Malachi de AElfweald
>Priority: Minor
>
> From the CHANGELOG
> {noformat}
> Version 1.2.1 (2011-11-27)
> --
> - Upgraded to parboiled 1.1.4
> - Added support for caption on tables (thx to Geoffrey Picron)
> Version 1.2.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.1.3
> - Implemented parsing timeout, closes #42
> - Fixed IndexOutOfBoundsException in ToHtmlSerializer, closes #39
> - Changed parser to not swallow backslash before non-special characters,
> fixes #35
> - Added test for fenced code blocks containing an empty line, closes #61
> - Migrated all tests from TestNG to specs2
> - Switched build tool from Apache Buildr to SBT
> Version 1.1.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.0.2
> - Introduced LinkRenderer layer for easy customization of HTML link rendering
> - Added support for [[Wiki-style]] links, thx to Brett Porter
> - Fixed #27 (Missing emphasis when paragraph has multiple lines)
> - Fixed #28 (Parser not fully extensible)
> - Fixed #32, #33 (HTML tags with attribute names containing underscores are
> not recognized as tags, thx to Edward Samson)
> - Fixed #34 (Pathologically slow parsing when strong and italics emphasis are
> applied together)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-101) Add support to generate xrefs for groovy sources
Davide Cavestro created JXR-101: --- Summary: Add support to generate xrefs for groovy sources Key: JXR-101 URL: https://jira.codehaus.org/browse/JXR-101 Project: Maven JXR Issue Type: New Feature Components: jxr Affects Versions: 2.3 Reporter: Davide Cavestro Having crossreference for groovy sources would be great. Groovy is widely used, and partially compatible with java syntax. Maybe some fixes to the Java source parser (i.e. JXR-100) could let us produce good xrefs even for groovy sources (provided that parsing them is enabled). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
