[jira] (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ https://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339023#comment-339023 ] Brett Porter commented on MPCHECKSTYLE-20: -- Sorry Diwaker, I think you've found the wrong JIRA project - this is for the Maven 1.x plugin for Checkstyle, and is not maintained by the Checkstyle community. In fact, as Maven 1.x was put into end-of-life some time ago, these specific issues are no longer being pursued. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: https://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: Maven 1.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- 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-3258) the command "mvn -help" should describe the usage of the maven help plugin
[ https://jira.codehaus.org/browse/MNG-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-3258. --- Resolution: Won't Fix Fix Version/s: (was: Issues to be reviewed for 3.x) Assignee: Robert Scholte > the command "mvn -help" should describe the usage of the maven help plugin > -- > > Key: MNG-3258 > URL: https://jira.codehaus.org/browse/MNG-3258 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7 >Reporter: Eirik Maus >Assignee: Robert Scholte > Attachments: MNG-3258.patch > > > The help system in maven (and any other program as well) is typically what > you use if you can't remember the syntax for a given command. The syntax for > the help plugin is, however no simpler than any other command, and I always > find myself ending up with searching google for info on how to use the help > system to find out how to use, for instance, the dependency plugin. > I have suggested a new goal "mvn help:help" in the help plugin to use for > getting info on how to use the help system. The same info should be printed > when a user types "mvn -help". -- 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] (MDEP-435) improve mvn dependency:tree - add optional xml output of the results
[ https://jira.codehaus.org/browse/MDEP-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-5262 to MDEP-435: -- Complexity: (was: Intermediate) Component/s: (was: Command Line) tree Affects Version/s: (was: 3.0.4) Key: MDEP-435 (was: MNG-5262) Project: Maven Dependency Plugin (was: Maven 2 & 3) > improve mvn dependency:tree - add optional xml output of the results > > > Key: MDEP-435 > URL: https://jira.codehaus.org/browse/MDEP-435 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree > Environment: all >Reporter: Kow Unk > > The output of mvn dependency:tree would be more useful to me if it was in a > format that is machine readable. I would like to create some tooling to be > able to easily determine what is causing a particular jar to be included. > for example: > >mymvntool -why org.springframework:org.springframework.beans:3.0.5 > org.springframework.beans-3.0.5 is being *dragged* in by: > my.otherproject.core:1.1 > %end of search > another use: > >mymvntool -makeexclusionfor > >org.springframework:org.springframework.beans:3.0.5 > > >org.springframework >org.springframework.beans > > > or even: > >mymvntool -makeexclusionfor org.springframework:*:3.0.5 > this would pickup all the included jars in the project and build exclusions > for them. > It may have been dumb to pick spring as the exclusion resource, but this is > just an example. having xml output would be valuable to me and probably > others too. > -K -- 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] (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ https://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339014#comment-339014 ] Diwaker Gupta commented on MPCHECKSTYLE-20: --- I'm still running into this issue with the Checkstyle plugin on IntelliJ IDEA 13. Somewhat surprised that such an early bug that seems to impact so many people is still open after this many years :( Happy to provide any debugging information that the Checkstyle dev community needs to make progress on this. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: https://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: Maven 1.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- 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-1055) Parallel JUnit does not run all test methods with parallel=classesAndMethods perCoreThreadCount=false useUnlimitedThreads=true and threadCountMethods specified
[
https://jira.codehaus.org/browse/SUREFIRE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339004#comment-339004
]
Chris Hansen edited comment on SUREFIRE-1055 at 1/22/14 11:08 AM:
--
Some of the options are not available on 2.15 and below, but I've tried some
different configuration combinations and have not been to reproduce this issue
with 2.15. Also, I've tried different configuration combinations with 2.16 and
I've only seen this issue when parallel=classesAndMethods or parallel=all with
the rest of the above configuration.
was (Author: chris.hansen):
Some of the options are not available on 2.15 and below, but I've tried
some different configuration combinations and have not been to reproduce this
issue with 2.15. Also, I've tried different configuration combinations with
2.16 and this is the only one where I've seen this issue.
> Parallel JUnit does not run all test methods with parallel=classesAndMethods
> perCoreThreadCount=false useUnlimitedThreads=true and threadCountMethods
> specified
> ---
>
> Key: SUREFIRE-1055
> URL: https://jira.codehaus.org/browse/SUREFIRE-1055
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Chris Hansen
> Attachments: surefire-output.txt
>
>
> Some test methods are skipped at random with the below configuration. When
> test methods are skipped in this way, only one method in the class runs.
> Running tests repeatedly with no code change often yields a different number
> of tests with each run (e.g. see the attached surefire-output.txt). Tests
> that take longer to run are less likely to be affected. This affects version
> 2.16 of Surefire and Failsafe equally.
> Here is a simple test project which reproduces the issue:
> https://github.com/hansenc/SUREFIRE-1055
> It has a few simple test classes with a naming convention for how many test
> methods are in each class (e.g. Methods4Test has 4 test methods).
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.16
>
> classesAndMethods
> false
> true
> 3
>
>
> {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] (SUREFIRE-1055) Parallel JUnit does not run all test methods with parallel=classesAndMethods perCoreThreadCount=false useUnlimitedThreads=true and threadCountMethods specified
[
https://jira.codehaus.org/browse/SUREFIRE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339004#comment-339004
]
Chris Hansen commented on SUREFIRE-1055:
Some of the options are not available on 2.15 and below, but I've tried some
different configuration combinations and have not been to reproduce this issue
with 2.15. Also, I've tried different configuration combinations with 2.16 and
this is the only one where I've seen this issue.
> Parallel JUnit does not run all test methods with parallel=classesAndMethods
> perCoreThreadCount=false useUnlimitedThreads=true and threadCountMethods
> specified
> ---
>
> Key: SUREFIRE-1055
> URL: https://jira.codehaus.org/browse/SUREFIRE-1055
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Chris Hansen
> Attachments: surefire-output.txt
>
>
> Some test methods are skipped at random with the below configuration. When
> test methods are skipped in this way, only one method in the class runs.
> Running tests repeatedly with no code change often yields a different number
> of tests with each run (e.g. see the attached surefire-output.txt). Tests
> that take longer to run are less likely to be affected. This affects version
> 2.16 of Surefire and Failsafe equally.
> Here is a simple test project which reproduces the issue:
> https://github.com/hansenc/SUREFIRE-1055
> It has a few simple test classes with a naming convention for how many test
> methods are in each class (e.g. Methods4Test has 4 test methods).
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.16
>
> classesAndMethods
> false
> true
> 3
>
>
> {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] (MCHANGES-327) JIRA session is not properly established using jiraUser and jiraPassword
[ https://jira.codehaus.org/browse/MCHANGES-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diego Rivera updated MCHANGES-327: -- Summary: JIRA session is not properly established using jiraUser and jiraPassword (was: JIRA session is not properly established using jiraUsername and jiraPassword) > JIRA session is not properly established using jiraUser and jiraPassword > > > Key: MCHANGES-327 > URL: https://jira.codehaus.org/browse/MCHANGES-327 > Project: Maven Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.9 >Reporter: Diego Rivera > > When using jiraUser and jiraPassword for authentication (in lieu of webUser > and webPassword), the session cookie is not preserved in order to maintain > the session authentication information for subsequent REST requests. > This means that although authentication succeeds, subsequent REST requests > don't benefit from the long-running session that was established. > The JSESSIONID cookie value needs to be captured from the original auth > request and preserved throughout all other REST invocations. > Using webUser and webPassword works, though, so at least that workaround is > there. -- 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] (MCHANGES-327) JIRA session is not properly established using jiraUsername and jiraPassword
Diego Rivera created MCHANGES-327: - Summary: JIRA session is not properly established using jiraUsername and jiraPassword Key: MCHANGES-327 URL: https://jira.codehaus.org/browse/MCHANGES-327 Project: Maven Changes Plugin Issue Type: Bug Components: jira Affects Versions: 2.9 Reporter: Diego Rivera When using jiraUser and jiraPassword for authentication (in lieu of webUser and webPassword), the session cookie is not preserved in order to maintain the session authentication information for subsequent REST requests. This means that although authentication succeeds, subsequent REST requests don't benefit from the long-running session that was established. The JSESSIONID cookie value needs to be captured from the original auth request and preserved throughout all other REST invocations. Using webUser and webPassword works, though, so at least that workaround is there. -- 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] (MINDEXER-77) Upgrade to Lucene 4.1
Emmanuel Hugonnet created MINDEXER-77: - Summary: Upgrade to Lucene 4.1 Key: MINDEXER-77 URL: https://jira.codehaus.org/browse/MINDEXER-77 Project: Maven Indexer Issue Type: Improvement Reporter: Emmanuel Hugonnet Lucene has made a great effort in being quicker and smaller in the 4.x versions. Moving to this new version would make maven indexer better -- 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] (MSITE-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338978#comment-338978 ] Stefan Cordes commented on MSITE-640: - With Maven 3.1.1 the import dependencies are still not resolved always. (depending on local repository content ?) Please use same dependency-resolution as other plugins do (like "compile"). > Maven searches only central repository for imported dependencies > > > Key: MSITE-640 > URL: https://jira.codehaus.org/browse/MSITE-640 > Project: Maven Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0 > Environment: Windows 7 >Reporter: Markus Tippmann > Attachments: stacktrace.txt > > > We are using dependencyManagement with "import" scope like described here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies > Problem occurs only at site generation, not at build time, where it works > perfectly. > The site plugin tries to find the imported artifacts, but searches only the > central repository and ignores the repositories in settings.xml > configuration. Mirror settings work, if "central" is mirrored, but > dependencies need to be resolved from two repositories, so one mirror does > not help here. > I try to attach the relevant parts of the stacktrace. -- 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] (MCHECKSTYLE-206) Update to post-5.0 checkstyle when the plugin is available
[ https://jira.codehaus.org/browse/MCHECKSTYLE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MCOBERTURA-143 to MCHECKSTYLE-206: Affects Version/s: (was: 2.5) (was: 2.4) 2.4 2.5 Key: MCHECKSTYLE-206 (was: MCOBERTURA-143) Project: Maven Checkstyle Plugin (was: Mojo's Cobertura Maven Plugin) > Update to post-5.0 checkstyle when the plugin is available > -- > > Key: MCHECKSTYLE-206 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-206 > Project: Maven Checkstyle Plugin > Issue Type: Task >Affects Versions: 2.5, 2.4 >Reporter: Benson Margulies > > Once the maven-checkstyle-plugin releases a version with a newer checkstyle > that 5.0, use it and fix the rules to stop exploding on @goal. -- 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
