[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
[
https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov closed MINDEXER-89.
--
Resolution: Fixed
> Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to
> avoid "Address already in use"
> --
>
> Key: MINDEXER-89
> URL: https://jira.codehaus.org/browse/MINDEXER-89
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing
> on a system which is already using port 8080. It's quite common for this port
> to already be open on a developer's machine (or server), if they're running
> Tomcat or Jenkins.
> {code}
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> {code}
> Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-86) Remove "legacy" transport format
[ https://jira.codehaus.org/browse/MINDEXER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-86: --- Assignee: Tamás Cservenák > Remove "legacy" transport format > > > Key: MINDEXER-86 > URL: https://jira.codehaus.org/browse/MINDEXER-86 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 6.0 > > > Index format "legacy", that is basically zipped up Lucene index should not be > supported anymore. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-79) Make project Java7+
[ https://jira.codehaus.org/browse/MINDEXER-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-79: --- Assignee: Tamás Cservenák > Make project Java7+ > --- > > Key: MINDEXER-79 > URL: https://jira.codehaus.org/browse/MINDEXER-79 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 6.0 > > > Due to Lucene requirements. > http://lucene.apache.org/core/4_8_1/SYSTEM_REQUIREMENTS.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-85) POM model reading fails too often
[ https://jira.codehaus.org/browse/MINDEXER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-85: --- Assignee: Tamás Cservenák > POM model reading fails too often > - > > Key: MINDEXER-85 > URL: https://jira.codehaus.org/browse/MINDEXER-85 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 6.0 > > > Seems it's due to "bare bone" Model reading by using directly Xpp3Dom builder > instead of Maven's model reader, as some XML entities that are usually > present in developer names and such causes POM to not be read. > qdox 1.6.0 from test resource is such an example POM. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-84) IllegalArgumentException: docID must be >= 0 and < maxDoc=6954 (got docID=6954)
[
https://jira.codehaus.org/browse/MINDEXER-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINDEXER-84:
---
Assignee: Tamás Cservenák
> IllegalArgumentException: docID must be >= 0 and < maxDoc=6954 (got
> docID=6954)
> ---
>
> Key: MINDEXER-84
> URL: https://jira.codehaus.org/browse/MINDEXER-84
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 6.0
>
>
> Issue reported as
> https://issues.sonatype.org/browse/NEXUS-5619
> {noformat}
> java.lang.IllegalArgumentException: docID must be >= 0 and < maxDoc=6954 (got
> docID=6954)
> at org.apache.lucene.index.IndexReader.document(IndexReader.java:1136)
> at
> org.apache.maven.index.updater.IndexDataWriter.writeDocuments(IndexDataWriter.java:173)
> at
> org.apache.maven.index.updater.IndexDataWriter.write(IndexDataWriter.java:93)
> at
> org.apache.maven.index.packer.DefaultIndexPacker.writeIndexData(DefaultIndexPacker.java:436)
> at
> org.apache.maven.index.packer.DefaultIndexPacker.packIndex(DefaultIndexPacker.java:137)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.publishRepositoryIndex(DefaultIndexerManager.java:1479)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.access$1000(DefaultIndexerManager.java:186)
> at
> org.sonatype.nexus.index.DefaultIndexerManager$10.run(DefaultIndexerManager.java:1438)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.shared(DefaultIndexerManager.java:2389)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.publishRepositoryIndex(DefaultIndexerManager.java:1432)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.publishAllIndex(DefaultIndexerManager.java:1369)
> at
> org.sonatype.nexus.tasks.PublishIndexesTask.doRun(PublishIndexesTask.java:59)
> at
> org.sonatype.nexus.scheduling.AbstractNexusTask.call(AbstractNexusTask.java:166)
> at
> org.sonatype.scheduling.DefaultScheduledTask.call(DefaultScheduledTask.java:459)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-41) Allow to index several artifacts with no classifier
[
https://jira.codehaus.org/browse/MINDEXER-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINDEXER-41:
---
Assignee: Tamás Cservenák
> Allow to index several artifacts with no classifier
> ---
>
> Key: MINDEXER-41
> URL: https://jira.codehaus.org/browse/MINDEXER-41
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Julien HENRY
>Assignee: Tamás Cservenák
> Fix For: 6.0
>
>
> See details in this thread:
> http://maven.40175.n5.nabble.com/Search-with-several-artifacts-same-GAV-different-type-extension-td4902408.html
> The key used by indexer is GAVC (GAV + classifier where classifier can be
> null).
> With current design the indexer will only index one artifact with no
> classifier (= main artifact) + optionally additional secondary artifacts with
> classifier.
> This is an issue for custom packaging types that publish several artifacts
> with different extensions but no classifier.
> For example:
> {code}
> groupId
>/artifactId
> /version
> /artifactId-version.pom
> /artifactId-version.jar
> /artifactId-version.tld
> /artifactId-version.config
> {code}
> It would be good to include the extension in the index key => GAVCE. This way
> a search will return jar, tld and config artifacts.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-87) Remove legacy marked code
[ https://jira.codehaus.org/browse/MINDEXER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352113#comment-352113 ] Tamás Cservenák commented on MINDEXER-87: - Some work started, will continue once I have time https://github.com/cstamas/maven-indexer/tree/MINDEXER-87-deprecated-removal-deps-cleanup > Remove legacy marked code > - > > Key: MINDEXER-87 > URL: https://jira.codehaus.org/browse/MINDEXER-87 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák > Fix For: 6.0 > > > Remove legacy code and also some of the unneded cruft (yes, we do plan to > break API a bit). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-728) Markdown headings (atx-style) not rendered correctly with Velocity Macro
Ingmar Steiner created MSITE-728: Summary: Markdown headings (atx-style) not rendered correctly with Velocity Macro Key: MSITE-728 URL: https://jira.codehaus.org/browse/MSITE-728 Project: Maven Site Plugin Issue Type: Bug Components: doxia integration Affects Versions: 3.4 Environment: $ mvn -version Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Maven home: /usr/local/Cellar/maven/3.2.3/libexec Java version: 1.7.0_60, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac" Reporter: Ingmar Steiner Priority: Minor Markdown files with atx-style headings are rendered correctly by `mvn site`, but if they have a `.vm` suffix (i.e., to trigger property expansion), then some of the headings are missing in the HTML output. I've created a minimal non-working example test project at https://github.com/psibre/mnwe-md-vm-headings. This includes the generated site output as a `gh-pages` branch, hosting it at http://psibre.github.io/mnwe-md-vm-headings/. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one
[ https://jira.codehaus.org/browse/MINDEXER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-83: --- Fix Version/s: 6.0 > Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new > ones) so that it is possible to add artifact files one by one > -- > > Key: MINDEXER-83 > URL: https://jira.codehaus.org/browse/MINDEXER-83 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov > Fix For: 6.0 > > > The currently existing method only accepts a list of files. This assumes you > already have a list of the files. However, this is inconvenient for use if > you have the artifact files coming one by one (for example when deploying an > artifact over over HTTP). > This method should be re-worked and it would be great if some new methods > could be introduced for when adding files which belong to a particular > artifact. > It would also be great if there could be methods that accept (File file, > Artifact artifact, ..) when adding and updating an artifact to the index. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-220) Debug shows unnecessary stacktrace with java.net.MalformedURLException: no protocol: LICENSE.txt
[
https://jira.codehaus.org/browse/MCHECKSTYLE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCHECKSTYLE-220:
---
Labels: plexus-resources (was: )
> Debug shows unnecessary stacktrace with java.net.MalformedURLException: no
> protocol: LICENSE.txt
>
>
> Key: MCHECKSTYLE-220
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-220
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Robert Scholte
>Priority: Minor
> Labels: plexus-resources
>
> When a build fails, developers normally change the logging of Maven to debug
> and search for exceptions. When using checkstyle, they might see this:
> {noformat}
> [DEBUG] URLResourceLoader: Exception when looking for 'LICENSE.txt' at ''
> java.net.MalformedURLException: no protocol: LICENSE.txt
> at java.net.URL.(URL.java:585)
> at java.net.URL.(URL.java:482)
> at java.net.URL.(URL.java:431)
> at
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:71)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:436)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:276)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:175)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:476)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [DEBUG] URLResourceLoader: Exception when looking for 'LICENSE.txt
> java.net.MalformedURLException: no protocol: LICENSE.txt
> at java.net.URL.(URL.java:585)
> at java.net.URL.(URL.java:482)
> at java.net.URL.(URL.java:431)
> at
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:123)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:436)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:276)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:175)
> at
[jira] (MCHECKSTYLE-109) Credentials ignored when provided in configLocation URL
[ https://jira.codehaus.org/browse/MCHECKSTYLE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MCHECKSTYLE-109: --- Labels: plexus-resources (was: ) > Credentials ignored when provided in configLocation URL > --- > > Key: MCHECKSTYLE-109 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-109 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: maven 2.1.0 >Reporter: Stevo Slavic > Labels: plexus-resources > > If configLocation URL contains username and password, e.g. > https://username:password/acme.org/checkstyle_checks.xml, those should be > used when obtaining checkstyle configuration xml. Currently, plugin fails to > obtain resource from such URL. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-138) Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe
[ https://jira.codehaus.org/browse/MCHECKSTYLE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MCHECKSTYLE-138: --- Labels: checkstyle-core (was: ) > Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe > --- > > Key: MCHECKSTYLE-138 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-138 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.12.1 >Reporter: Kristian Rosenvold > Labels: checkstyle-core > > The checkstyle plugin can be marked as threadSafe if checkstyle itself can be > verified to be thread safe. > "Someone" should ask the checkstyle community if this is the case. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-61) Upgrade Locator URL logic to use maven-wagon.
[ https://jira.codehaus.org/browse/MCHECKSTYLE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MCHECKSTYLE-61: -- Labels: plexus-resources (was: ) > Upgrade Locator URL logic to use maven-wagon. > - > > Key: MCHECKSTYLE-61 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-61 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Reporter: Joakim Erdfelt > Labels: plexus-resources > > Upgrade the URL location logic in the Locator to utilize the maven-wagon api. > Current logic utilizes the java URL object. > Using maven-wagon, will allow for many more potential sources, as well as > greater authorization and proxy abilities already built into maven. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-42) checkstyle does not take into account proxy settings from settings.xml
[
https://jira.codehaus.org/browse/MCHECKSTYLE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCHECKSTYLE-42:
--
Labels: plexus-resources (was: )
> checkstyle does not take into account proxy settings from settings.xml
> --
>
> Key: MCHECKSTYLE-42
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-42
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Frederic
> Labels: plexus-resources
> Attachments: fix-proxy-usage.patch
>
>
> I've been hesitating wether to report it as bug or as improvement, but at the
> moment I'd rate it as a bug.
> It took me quite some time to figure out why this was going wrong.
> In my {{settings.xml}} I've defined our company proxysettings. These settings
> are used by Maven when connecting to the remote repository.
> However when using the checkstyle plugin as part of the site generation I can
> not obtain our {{checkstyle.xml}} which is available via http.
> I found a solution by adding the following parameters on the command line
> when continuum launches maven:
> {{-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=80}}
> Wouldn't it be possible for the maven checkstyle plugin to use the settings
> defined in {{settings.xml}}, so I've only to define those once?
> FYI the error generated:
> {noformat}
> [INFO] Generate "Dependencies" report.
> [INFO] Generate "Issue Tracking" report.
> [INFO] Generate "Project License" report.
> [INFO] Generate "Mailing Lists" report.
> [INFO] Generate "Source Repository" report.
> [INFO] Generate "Project Team" report.
> [INFO] Generate "Maven Surefire Report" report.
> [INFO] Generate "Checkstyle" report.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during report generation
> Embedded error: Unable to find configuration file location.
> http://spirou.mycompany.be/javadev/install/checkstyle/mycompany-checkstyle-1.5.xml
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during report
> generation
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during
> report generation
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:389)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> ... 16 more
> Caused by: org.apache.maven.reporting.MavenReportException: Unable to find
> configuration file location.
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.getConfigFile(CheckstyleReport.java:879)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:466)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:802)
> at org.a
[jira] (MCHECKSTYLE-91) Different checkstyle rules for main and test source
[ https://jira.codehaus.org/browse/MCHECKSTYLE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352124#comment-352124 ] Robert Scholte commented on MCHECKSTYLE-91: --- I'd prefer 1 report per configuration, so this should be solved with two execution-blocks. However, now there's no way to exclude the main (re)sources. > Different checkstyle rules for main and test source > --- > > Key: MCHECKSTYLE-91 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-91 > Project: Maven Checkstyle Plugin > Issue Type: New Feature >Reporter: Ricky Hazelwood > Attachments: MCHECKSTYLE-91-2009-01-02-20-30-00.diff > > > It would be nice if the plugin can accept different configuration for test > source and produce separate reports for main and test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-22) Ability to specify more than 1 check configuration file and file sets for each of these configurations
[ https://jira.codehaus.org/browse/MCHECKSTYLE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCHECKSTYLE-22. - Resolution: Won't Fix Assignee: Robert Scholte Let's stay with the "one configFile per report". If you want to use more configurations, use multiple execution-blocks. It's solid and straight forward. We could generate an aggregated-report, but that would require conflict resolution. Anyhow, that would be another request. > Ability to specify more than 1 check configuration file and file sets for > each of these configurations > -- > > Key: MCHECKSTYLE-22 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-22 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Reporter: Fabrice Bellingard >Assignee: Robert Scholte > > I'm using Eclipse Checkstyle Plug-in, and there's a functionnality I enjoy a > lot: the ability to specify as many check configuration files as I want for a > projet, and to tell which file sets those configurations should be run on. > And as I use this functionnality extensively, I'd love to have it also in the > Maven Checkstyle Plug-in :o) > To get a look at what the Eclipse plugin does: > http://eclipse-cs.sourceforge.net/advanced_file_sets.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1080) Use parallel and fork together run some tests multiple times
[ https://jira.codehaus.org/browse/SUREFIRE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352129#comment-352129 ] Andreas Gudian commented on SUREFIRE-1080: -- parallel=classes and forkCount>1 with reuseForks=true is not supposed to work. The forked processes are fed with one new class to execute as soon as they finished their previous class (note: that's only the case for forkCount>1 and reuseForks=true). With the forked process only having one class at hand at a given time, it is not supposed to spawn threads to execute classes in parallel. @Tibor: I hope that helps you figuring out what happens here... :) > Use parallel and fork together run some tests multiple times > > > Key: SUREFIRE-1080 > URL: https://jira.codehaus.org/browse/SUREFIRE-1080 > Project: Maven Surefire > Issue Type: Bug > Environment: Apache Maven 3.2.2-SNAPSHOT > Surefire 2.18-SNAPSHOT > JUnit 4.11 >Reporter: Qingzhou Luo > Attachments: test.tgz > > > There are 9 tests in total in the attached project, and mvn test will show 9 > tests run. When I use the command " mvn test -Dparallel=classes > -DforkCount=2 -DuseUnlimitedThreads=true", it shows 13 tests run (and > sometimes 16), and some tests are run more than once. > If I remove forkCount, or parallel, everything will be fine. But it is > problematic when combining together. > Apache Maven 3.2.2-SNAPSHOT > Surefire 2.18-SNAPSHOT > JUnit 4.11 > Thanks! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1080) Use parallel and fork together run some tests multiple times
[ https://jira.codehaus.org/browse/SUREFIRE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352132#comment-352132 ] Tibor Digana commented on SUREFIRE-1080: Hi Andreas, I was debugging this configuration and I got 4 classes in the lazy-loop in JUnitCoreWrapper. Th parallel computer was reused in every iteration, which is I think my fault. The PC is caching Runners so I should create new PC instance in every next iteration. We may talk about the details on the email more. > Use parallel and fork together run some tests multiple times > > > Key: SUREFIRE-1080 > URL: https://jira.codehaus.org/browse/SUREFIRE-1080 > Project: Maven Surefire > Issue Type: Bug > Environment: Apache Maven 3.2.2-SNAPSHOT > Surefire 2.18-SNAPSHOT > JUnit 4.11 >Reporter: Qingzhou Luo > Attachments: test.tgz > > > There are 9 tests in total in the attached project, and mvn test will show 9 > tests run. When I use the command " mvn test -Dparallel=classes > -DforkCount=2 -DuseUnlimitedThreads=true", it shows 13 tests run (and > sometimes 16), and some tests are run more than once. > If I remove forkCount, or parallel, everything will be fine. But it is > problematic when combining together. > Apache Maven 3.2.2-SNAPSHOT > Surefire 2.18-SNAPSHOT > JUnit 4.11 > Thanks! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1043) Please add possibility to specify tests groups order for sequential run and tests groups content for parallel run.
[ https://jira.codehaus.org/browse/SUREFIRE-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352049#comment-352049 ] Tibor Digana edited comment on SUREFIRE-1043 at 9/1/14 6:29 PM: I guess the new feature SUREFIRE-1093 (surefire-2.18) would help you because it isolates @NotThreadSafe JUnit tests from parallel tests. This means the inclusion section may specify something like this: **/*Suite.java and you may have two test classes: SequentialTest class annotated with @NotThreadSafe, and ParallelTest. Annotation NotThreadSafe is JCIP artifact. If you specify run-order and groups in the same section, then the configuration applies to both suites. was (Author: tibor17): I guess the new feature SUREFIRE-1093 (surefire-2.18) would help you because it isolates @NotThreadSafe JUnit tests from parallel tests. It works only with listed tests. This means the inclusion section may specify something like this: **/*Suite.java and you may have two main suites: SequentialSuite class annotated with @NotThreadSafe, and ParallelSuite. Annotation NotThreadSafe is JCIP artifact. If you specify run-order and groups in the same section, then the configuration applies to both suites. > Please add possibility to specify tests groups order for sequential run and > tests groups content for parallel run. > -- > > Key: SUREFIRE-1043 > URL: https://jira.codehaus.org/browse/SUREFIRE-1043 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Tomasz Halama > > What we need is as following: > For sequential run: > We would like to have some means to specify run order of whole groups of > tests, during one invocation of plugin. Content of the group should be > determined by ant style expressions. Inside each such group, tests should be > run in order, specified by 'runOrder' parameter. > Example: > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST > com/something/SomeTest,com/something/SomeTest2 > **/*IT,**/IT* > com/something/SomeTest3 > > alphabetical > > > In above example run order of tests should be as following: > 1. all tests, which have "ST" suffix, should be run in alphabetical order > 2. com/something/SomeTest and com/something/SomeTest2 should be run in > alphabetical order > 3. all tests, which have "IT" suffix or prefix, should be run in alphabetical > order > 4. com/something/SomeTest3 should be run > Instead of adding some new parameter (like above 'groupsOrder' section), I > think 'includes' can be used for this purpose (each entry would determine a > group), with some additional boolean value, i.e. 'groupsByIncludes' > (indicating, that each 'include' entry should be considered as a separate > group): > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST.java > > com/something/SomeTest.java,com/something/SomeTest2.java > **/*IT.java,**/IT*.java > com/something/SomeTest3.java > > alphabetical > true > > > In our case we cannot simply divide one invocation of plugin into several > ones (which would solve this problem), because setuping tests context takes > too much time. > This feature will also give possibility to run tests by some specific order > (when each 'group'/'include' would consist of only one entry). Possibility to > set specific order could be very handy, when i.e. you detected, that some of > your tests are not independent and you want to reproduce the problem. > For parallel run: > We would like to have some means to specify tests groups for parallel run. By > this I mean: tests in each group will be run in parallel, but the groups > itself will be run sequentially (so only tests from the same group can be > executed at the same time) > There should be also some annotation, which can be used to marked tests, > which cannot be run in parallel at all. > If 'includes' contains such tests - they should be run sequentially at the > end. > To achieve all of this, new (i.e. groupsOrder) or 'includes' parameter can be > used here, in the same way as for sequential run, except 'parallel' attribute > should be set to new value: i.e. parallelGroup. > I think, that logging information, when each test (each test method) starts > and stops, would be also a good idea (we would know exact tests, which are > run at the same time). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1043) Please add possibility to specify tests groups order for sequential run and tests groups content for parallel run.
[ https://jira.codehaus.org/browse/SUREFIRE-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352049#comment-352049 ] Tibor Digana edited comment on SUREFIRE-1043 at 9/1/14 6:40 PM: I guess the new feature SUREFIRE-1093 (surefire-2.18) would help you because it isolates @NotThreadSafe JUnit tests from parallel tests. This means the inclusion section may specify something like this: **/*Suite.java and you may have two test classes: SequentialTest class annotated with @NotThreadSafe, and ParallelTest. Annotation NotThreadSafe is JCIP artifact. was (Author: tibor17): I guess the new feature SUREFIRE-1093 (surefire-2.18) would help you because it isolates @NotThreadSafe JUnit tests from parallel tests. This means the inclusion section may specify something like this: **/*Suite.java and you may have two test classes: SequentialTest class annotated with @NotThreadSafe, and ParallelTest. Annotation NotThreadSafe is JCIP artifact. If you specify run-order and groups in the same section, then the configuration applies to both suites. > Please add possibility to specify tests groups order for sequential run and > tests groups content for parallel run. > -- > > Key: SUREFIRE-1043 > URL: https://jira.codehaus.org/browse/SUREFIRE-1043 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Tomasz Halama > > What we need is as following: > For sequential run: > We would like to have some means to specify run order of whole groups of > tests, during one invocation of plugin. Content of the group should be > determined by ant style expressions. Inside each such group, tests should be > run in order, specified by 'runOrder' parameter. > Example: > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST > com/something/SomeTest,com/something/SomeTest2 > **/*IT,**/IT* > com/something/SomeTest3 > > alphabetical > > > In above example run order of tests should be as following: > 1. all tests, which have "ST" suffix, should be run in alphabetical order > 2. com/something/SomeTest and com/something/SomeTest2 should be run in > alphabetical order > 3. all tests, which have "IT" suffix or prefix, should be run in alphabetical > order > 4. com/something/SomeTest3 should be run > Instead of adding some new parameter (like above 'groupsOrder' section), I > think 'includes' can be used for this purpose (each entry would determine a > group), with some additional boolean value, i.e. 'groupsByIncludes' > (indicating, that each 'include' entry should be considered as a separate > group): > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST.java > > com/something/SomeTest.java,com/something/SomeTest2.java > **/*IT.java,**/IT*.java > com/something/SomeTest3.java > > alphabetical > true > > > In our case we cannot simply divide one invocation of plugin into several > ones (which would solve this problem), because setuping tests context takes > too much time. > This feature will also give possibility to run tests by some specific order > (when each 'group'/'include' would consist of only one entry). Possibility to > set specific order could be very handy, when i.e. you detected, that some of > your tests are not independent and you want to reproduce the problem. > For parallel run: > We would like to have some means to specify tests groups for parallel run. By > this I mean: tests in each group will be run in parallel, but the groups > itself will be run sequentially (so only tests from the same group can be > executed at the same time) > There should be also some annotation, which can be used to marked tests, > which cannot be run in parallel at all. > If 'includes' contains such tests - they should be run sequentially at the > end. > To achieve all of this, new (i.e. groupsOrder) or 'includes' parameter can be > used here, in the same way as for sequential run, except 'parallel' attribute > should be set to new value: i.e. parallelGroup. > I think, that logging information, when each test (each test method) starts > and stops, would be also a good idea (we would know exact tests, which are > run at the same time). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1043) Please add possibility to specify tests groups order for sequential run and tests groups content for parallel run.
[ https://jira.codehaus.org/browse/SUREFIRE-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1043: --- Comment: was deleted (was: May we mark this issue as duplicated?) > Please add possibility to specify tests groups order for sequential run and > tests groups content for parallel run. > -- > > Key: SUREFIRE-1043 > URL: https://jira.codehaus.org/browse/SUREFIRE-1043 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Tomasz Halama > > What we need is as following: > For sequential run: > We would like to have some means to specify run order of whole groups of > tests, during one invocation of plugin. Content of the group should be > determined by ant style expressions. Inside each such group, tests should be > run in order, specified by 'runOrder' parameter. > Example: > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST > com/something/SomeTest,com/something/SomeTest2 > **/*IT,**/IT* > com/something/SomeTest3 > > alphabetical > > > In above example run order of tests should be as following: > 1. all tests, which have "ST" suffix, should be run in alphabetical order > 2. com/something/SomeTest and com/something/SomeTest2 should be run in > alphabetical order > 3. all tests, which have "IT" suffix or prefix, should be run in alphabetical > order > 4. com/something/SomeTest3 should be run > Instead of adding some new parameter (like above 'groupsOrder' section), I > think 'includes' can be used for this purpose (each entry would determine a > group), with some additional boolean value, i.e. 'groupsByIncludes' > (indicating, that each 'include' entry should be considered as a separate > group): > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST.java > > com/something/SomeTest.java,com/something/SomeTest2.java > **/*IT.java,**/IT*.java > com/something/SomeTest3.java > > alphabetical > true > > > In our case we cannot simply divide one invocation of plugin into several > ones (which would solve this problem), because setuping tests context takes > too much time. > This feature will also give possibility to run tests by some specific order > (when each 'group'/'include' would consist of only one entry). Possibility to > set specific order could be very handy, when i.e. you detected, that some of > your tests are not independent and you want to reproduce the problem. > For parallel run: > We would like to have some means to specify tests groups for parallel run. By > this I mean: tests in each group will be run in parallel, but the groups > itself will be run sequentially (so only tests from the same group can be > executed at the same time) > There should be also some annotation, which can be used to marked tests, > which cannot be run in parallel at all. > If 'includes' contains such tests - they should be run sequentially at the > end. > To achieve all of this, new (i.e. groupsOrder) or 'includes' parameter can be > used here, in the same way as for sequential run, except 'parallel' attribute > should be set to new value: i.e. parallelGroup. > I think, that logging information, when each test (each test method) starts > and stops, would be also a good idea (we would know exact tests, which are > run at the same time). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1043) Please add possibility to specify tests groups order for sequential run and tests groups content for parallel run.
[ https://jira.codehaus.org/browse/SUREFIRE-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352133#comment-352133 ] Tibor Digana commented on SUREFIRE-1043: @Tomasz Halama The group of tests sounds to me like Maven section in plugin configuration. Each plugin execution may have same phase but different configuration. Executions run in a sequence. Parallel executions are possible if you assign tests in a suite. Thus every Suite may have own tests and they order is guaranted. If you trigger surefire plugin with parallel methods, such of hierarchy of suites and classes will guarantee ordering of classes, and the methods of particular test class will be executed in parallel. You can execute suites and methods in parallel in plugin configuration if you set parallel=suitesAndMethods. This means the groups of test classes (=Suites) are run in parallel, the tests classes in sequence and methods in parallel. Would this help? > Please add possibility to specify tests groups order for sequential run and > tests groups content for parallel run. > -- > > Key: SUREFIRE-1043 > URL: https://jira.codehaus.org/browse/SUREFIRE-1043 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Tomasz Halama > > What we need is as following: > For sequential run: > We would like to have some means to specify run order of whole groups of > tests, during one invocation of plugin. Content of the group should be > determined by ant style expressions. Inside each such group, tests should be > run in order, specified by 'runOrder' parameter. > Example: > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST > com/something/SomeTest,com/something/SomeTest2 > **/*IT,**/IT* > com/something/SomeTest3 > > alphabetical > > > In above example run order of tests should be as following: > 1. all tests, which have "ST" suffix, should be run in alphabetical order > 2. com/something/SomeTest and com/something/SomeTest2 should be run in > alphabetical order > 3. all tests, which have "IT" suffix or prefix, should be run in alphabetical > order > 4. com/something/SomeTest3 should be run > Instead of adding some new parameter (like above 'groupsOrder' section), I > think 'includes' can be used for this purpose (each entry would determine a > group), with some additional boolean value, i.e. 'groupsByIncludes' > (indicating, that each 'include' entry should be considered as a separate > group): > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST.java > > com/something/SomeTest.java,com/something/SomeTest2.java > **/*IT.java,**/IT*.java > com/something/SomeTest3.java > > alphabetical > true > > > In our case we cannot simply divide one invocation of plugin into several > ones (which would solve this problem), because setuping tests context takes > too much time. > This feature will also give possibility to run tests by some specific order > (when each 'group'/'include' would consist of only one entry). Possibility to > set specific order could be very handy, when i.e. you detected, that some of > your tests are not independent and you want to reproduce the problem. > For parallel run: > We would like to have some means to specify tests groups for parallel run. By > this I mean: tests in each group will be run in parallel, but the groups > itself will be run sequentially (so only tests from the same group can be > executed at the same time) > There should be also some annotation, which can be used to marked tests, > which cannot be run in parallel at all. > If 'includes' contains such tests - they should be run sequentially at the > end. > To achieve all of this, new (i.e. groupsOrder) or 'includes' parameter can be > used here, in the same way as for sequential run, except 'parallel' attribute > should be set to new value: i.e. parallelGroup. > I think, that logging information, when each test (each test method) starts > and stops, would be also a good idea (we would know exact tests, which are > run at the same time). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1043) Please add possibility to specify tests groups order for sequential run and tests groups content for parallel run.
[ https://jira.codehaus.org/browse/SUREFIRE-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352133#comment-352133 ] Tibor Digana edited comment on SUREFIRE-1043 at 9/1/14 6:55 PM: @Tomasz Halama The group of tests sounds to me like Maven section in plugin configuration. Each plugin execution may have same phase but different configuration. Executions run in a sequence. Parallel executions are possible if you assign tests in a suite. Thus every Suite may have own tests and their order is guaranted. If you trigger surefire plugin with parallel methods, such of hierarchy of suites and classes will guarantee ordering of classes, and the methods of particular test class will be executed in parallel. You can execute suites and methods in parallel in plugin configuration if you set parallel=suitesAndMethods. This means the groups of test classes (=Suites) are run in parallel, the tests classes in sequence and methods in parallel. Would this help? was (Author: tibor17): @Tomasz Halama The group of tests sounds to me like Maven section in plugin configuration. Each plugin execution may have same phase but different configuration. Executions run in a sequence. Parallel executions are possible if you assign tests in a suite. Thus every Suite may have own tests and they order is guaranted. If you trigger surefire plugin with parallel methods, such of hierarchy of suites and classes will guarantee ordering of classes, and the methods of particular test class will be executed in parallel. You can execute suites and methods in parallel in plugin configuration if you set parallel=suitesAndMethods. This means the groups of test classes (=Suites) are run in parallel, the tests classes in sequence and methods in parallel. Would this help? > Please add possibility to specify tests groups order for sequential run and > tests groups content for parallel run. > -- > > Key: SUREFIRE-1043 > URL: https://jira.codehaus.org/browse/SUREFIRE-1043 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Tomasz Halama > > What we need is as following: > For sequential run: > We would like to have some means to specify run order of whole groups of > tests, during one invocation of plugin. Content of the group should be > determined by ant style expressions. Inside each such group, tests should be > run in order, specified by 'runOrder' parameter. > Example: > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST > com/something/SomeTest,com/something/SomeTest2 > **/*IT,**/IT* > com/something/SomeTest3 > > alphabetical > > > In above example run order of tests should be as following: > 1. all tests, which have "ST" suffix, should be run in alphabetical order > 2. com/something/SomeTest and com/something/SomeTest2 should be run in > alphabetical order > 3. all tests, which have "IT" suffix or prefix, should be run in alphabetical > order > 4. com/something/SomeTest3 should be run > Instead of adding some new parameter (like above 'groupsOrder' section), I > think 'includes' can be used for this purpose (each entry would determine a > group), with some additional boolean value, i.e. 'groupsByIncludes' > (indicating, that each 'include' entry should be considered as a separate > group): > > org.apache.maven.plugins > maven-failsafe-plugin > > > **/*ST.java > > com/something/SomeTest.java,com/something/SomeTest2.java > **/*IT.java,**/IT*.java > com/something/SomeTest3.java > > alphabetical > true > > > In our case we cannot simply divide one invocation of plugin into several > ones (which would solve this problem), because setuping tests context takes > too much time. > This feature will also give possibility to run tests by some specific order > (when each 'group'/'include' would consist of only one entry). Possibility to > set specific order could be very handy, when i.e. you detected, that some of > your tests are not independent and you want to reproduce the problem. > For parallel run: > We would like to have some means to specify tests groups for parallel run. By > this I mean: tests in each group will be run in parallel, but the groups > itself will be run sequentially (so only tests from the same group can be > executed at the same time) > There should be also some annotation, which can be used to marked tests, > which cannot be run in parallel at all. > If 'includes' contains such tests - they should be run sequentially at the > end. > To achieve all of this, new (i.e. groupsOrder) or 'includes' parameter can be > used here, in the same way as for sequent
[jira] (SCM-706) prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact)
[ https://jira.codehaus.org/browse/SCM-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352134#comment-352134 ] Arthur Housinger commented on SCM-706: -- It appears that this is still reproducing in 2.5, and the patch doesn't seem to apply to the code for 2.5. Is there any ETA for either the patch being updated (assuming I'm correct in that it needs updating) or this ticket being resolved? > prepare-with-pom deletes release-pom.xml then tries to git add it (presumably > so the next commit records the fact) > -- > > Key: SCM-706 > URL: https://jira.codehaus.org/browse/SCM-706 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8.1 >Reporter: Darryl L. Miles >Assignee: Mark Struberg > Attachments: > 0001-MRELEASE-809-Use-git-correctly-when-removing-and-add.patch > > > When running: git release:prepare-with-pom > After the tag is created and pushed, it then runs the sequence: > git rm release-pom.xml > git add -- pom.xml release-pom.xml > But the "git add" fails because the "git rm" did the action of removing the > actual file and adding the file removal fact to the cached index ready for > the next commit to pickup. > The solution is to remove the "release-pom.xml" argument from the "git add" > it is unnecessary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-706) prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact)
[ https://jira.codehaus.org/browse/SCM-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352134#comment-352134 ] Arthur Housinger edited comment on SCM-706 at 9/1/14 8:19 PM: -- It appears that this is still reproducing in 2.5, and the patch doesn't seem to apply to the code for 2.5. Is there any ETA for either the patch being updated (assuming I'm correct in that it needs updating) or this ticket being resolved? Or does it make more sense for people to move away from prepare-with-pom if they are on git? was (Author: mistermouse): It appears that this is still reproducing in 2.5, and the patch doesn't seem to apply to the code for 2.5. Is there any ETA for either the patch being updated (assuming I'm correct in that it needs updating) or this ticket being resolved? > prepare-with-pom deletes release-pom.xml then tries to git add it (presumably > so the next commit records the fact) > -- > > Key: SCM-706 > URL: https://jira.codehaus.org/browse/SCM-706 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8.1 >Reporter: Darryl L. Miles >Assignee: Mark Struberg > Attachments: > 0001-MRELEASE-809-Use-git-correctly-when-removing-and-add.patch > > > When running: git release:prepare-with-pom > After the tag is created and pushed, it then runs the sequence: > git rm release-pom.xml > git add -- pom.xml release-pom.xml > But the "git add" fails because the "git rm" did the action of removing the > actual file and adding the file removal fact to the cached index ready for > the next commit to pickup. > The solution is to remove the "release-pom.xml" argument from the "git add" > it is unnecessary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
