[jira] (MSITE-650) Problem with multiple executions of surefire within site plugin 3.0
[ https://jira.codehaus.org/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348441#comment-348441 ] Herve Boutemy edited comment on MSITE-650 at 6/20/14 2:26 AM: -- notice that all of this is caused by cobertura requiring a forked lifecycle, re-running the tests in this forked context if you disable cobertura for site reporting, you won't have any problem or there should be a report mojo that doesn't fork lifecycle but only reports on results taken from previous execution was (Author: hboutemy): notice that all of this is caused by cobertura requiring a forked lifecycle, re-running the tests in this forked context if you disable cobertura for site reporting, you won't have any problem > Problem with multiple executions of surefire within site plugin 3.0 > --- > > Key: MSITE-650 > URL: https://jira.codehaus.org/browse/MSITE-650 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Kristian Rosenvold > Fix For: backlog > > Attachments: fooproject.tar.gz, mvninstall_fooproject.txt, > mvnsite_3.4-SNAPSHOT.txt, mvnsite_fooproject.txt, > mvn_X_install_fooproject.txt, mvn_X_site_fooproject.txt > > > There is a test project attached to SUREFIRE-905 that has a total of 4 > executions of surefire, with different configuration for each. > When running "mvn clean install" inside this project, surefire gets executed > 4 times as expected. When running "mvn site" only the first execution gets > run, the last three get stopped by the configuration-checksum in surefire, > indicating they get executed with the *same* configuration as the default > execution. (Surefire creates a SHA1 hash of all the mojo parameters to avoid > re-running the same configuration, which is why I conclude the three > executions get the same configuration as the default config) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2258) Wrong execution order of plugins in same phase
[ https://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348463#comment-348463 ] Alessandro Dionisi commented on MNG-2258: - Yes I confirm that. It also happen for me in assembly-plugin. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: https://jira.codehaus.org/browse/MNG-2258 > Project: Maven > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benson Margulies >Priority: Blocker > Fix For: 3.0.3 > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIATOOLS-44) maven-site plugin leaks file descriptord
[ https://jira.codehaus.org/browse/DOXIATOOLS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIATOOLS-44. --- Resolution: Fixed Fix Version/s: doxia-integration-tools-1.6 Assignee: Herve Boutemy fixed in [r1604116|http://svn.apache.org/r1604116] thank you > maven-site plugin leaks file descriptord > > > Key: DOXIATOOLS-44 > URL: https://jira.codehaus.org/browse/DOXIATOOLS-44 > Project: Maven Doxia Tools > Issue Type: Bug > Components: Doxia Integration Tools >Affects Versions: doxia-integration-tools-1.6 >Reporter: James Nord >Assignee: Herve Boutemy >Priority: Critical > Fix For: doxia-integration-tools-1.6 > > Attachments: DOXIATOOLS-44_PATCH_V1.txt > > > the Maven site plugin leaks file descriptor - due to a bug in > doxia-integration-tools. > in getDecorationModel() the DefaultSiteTool creates a reader to load the > site.xml file, however it is never closed - causing a handle leak for each > module in a multimodule project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-716) update doxia-integration-tools to 1.6
Herve Boutemy created MSITE-716: --- Summary: update doxia-integration-tools to 1.6 Key: MSITE-716 URL: https://jira.codehaus.org/browse/MSITE-716 Project: Maven Site Plugin Issue Type: Bug Affects Versions: 3.3 Reporter: Herve Boutemy to fix file descriptors leakage: DOXIATOOLS-44 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-716) update doxia-integration-tools to 1.6
[ https://jira.codehaus.org/browse/MSITE-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSITE-716. --- Resolution: Fixed Fix Version/s: 3.4 Assignee: Herve Boutemy done in [r1604117|http://svn.apache.org/r1604117] > update doxia-integration-tools to 1.6 > - > > Key: MSITE-716 > URL: https://jira.codehaus.org/browse/MSITE-716 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 3.4 > > > to fix file descriptors leakage: DOXIATOOLS-44 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3522) Cannot define execution order explicitly
[
https://jira.codehaus.org/browse/MNG-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3522:
---
Component/s: FDPFC
> Cannot define execution order explicitly
>
>
> Key: MNG-3522
> URL: https://jira.codehaus.org/browse/MNG-3522
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC, Plugins and Lifecycle
>Affects Versions: 2.0.9
>Reporter: Thomas Diesler
> Fix For: Issues to be reviewed for 3.x
>
>
> In this example antrun:run is excuted after dependency:copy-dependencies by
> virtue of plugin order. Preferable would be an explicit order definition. For
> example, a plugin could export a 'phase-id' that another uses in its 'phase'
> element.
> {code:xml}
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy-dependencies
> package
>
> copy-dependencies
>
>
>
> ${project.build.directory}/thirdparty
> true
>
>
>
>
>
> maven-antrun-plugin
>
>
> package
>
> run
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3726) Extend POM model to support declaration of IRC channels
[
https://jira.codehaus.org/browse/MNG-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3726:
---
Component/s: FDPFC
> Extend POM model to support declaration of IRC channels
> ---
>
> Key: MNG-3726
> URL: https://jira.codehaus.org/browse/MNG-3726
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC, POM
>Affects Versions: 2.0.9
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> The POM is already capable of holding mailing list infos so I wonder whether
> it should support IRC, too. Not sure if this is really sensible or maybe too
> exotic or seldom.
> In more detail, the required POM snippet might look like this:
> {code:xml}
>
>
> Maven Talk
> #maven
> irc://irc.codehaus.org/
> http://irc.codehaus.org/
> http://dev.rectang.com/logs/codehaus/%23maven/
>
>
> {code}
> The Maven Project Info Reports Plugin should then be able to pick that up and
> integrate it nicely into the site, maybe like illustrated by the [Mojo
> Site|http://mojo.codehaus.org/irc.html].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-296) SBT Output not correct for dependencies
Karl-Heinz Marbaise created MPIR-296: Summary: SBT Output not correct for dependencies Key: MPIR-296 URL: https://jira.codehaus.org/browse/MPIR-296 Project: Maven Project Info Reports Plugin Issue Type: Improvement Components: dependencies Affects Versions: 2.7 Reporter: Karl-Heinz Marbaise Priority: Trivial Hi, I found little missleading dependency information for SBT generated by the Info Reports Plugin[1]. I think the line 183 of DependencyInformationReport.java[2] needs to be fixed by replacing with %%: renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += \"%s\" \"%s\" %% \"%s\"", groupId, artifactId, version ) ); renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += \"%s\" %% \"%s\" %% \"%s\"", groupId, artifactId, version ) ); Could someone update this? Please let me know if you need additional information. Kind regards, Jentsch -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-271) For repository assembly, include pom.xml project plugins, as an option
[
https://jira.codehaus.org/browse/MASSEMBLY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joël Royer updated MASSEMBLY-271:
-
Comment: was deleted
(was: I've got the same problem.
I want to build a repository archive that allows my customer to build the
projet without access to the central repository.
Plugins described in the pom are not packaged.
Maven 3.0.5 / Maven Assembly Plugin 2.4)
> For repository assembly, include pom.xml project plugins, as an option
> --
>
> Key: MASSEMBLY-271
> URL: https://jira.codehaus.org/browse/MASSEMBLY-271
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.2-beta-1
>Reporter: Elias Ross
>
> One use case for creating a repository archive, like so:
> {code:xml}
>
>
>
> repository
> true
>
>
>
> {code}
> Is to allow the project pom to be runnable at a customer or remote site,
> which does not have access to the central repository. Runnable, in the sense
> that targets such as "exec:java" or the like can be called.
> However, the repository archive does not include any plugins, especially
> custom ones, that may be required to use a remotely deployed pom.xml.
> I classified this as a "bug" since I feel without project plugins included,
> the repository is not complete, but may be considered more of a "feature
> request" instead.
> A work-around is indicate custom plugins using
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-296) SBT Output not correct for dependencies
[ https://jira.codehaus.org/browse/MPIR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MPIR-296: - Fix Version/s: 2.8 > SBT Output not correct for dependencies > --- > > Key: MPIR-296 > URL: https://jira.codehaus.org/browse/MPIR-296 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Affects Versions: 2.7 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Trivial > Fix For: 2.8 > > > Hi, > I found little missleading dependency information for SBT generated by the > Info Reports Plugin[1]. > I think the line 183 of DependencyInformationReport.java[2] needs to be fixed > by replacing with %%: > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" %% \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > Could someone update this? > Please let me know if you need additional information. > Kind regards, > Jentsch -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-296) SBT Output not correct for dependencies
[ https://jira.codehaus.org/browse/MPIR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise reassigned MPIR-296: Assignee: Karl-Heinz Marbaise > SBT Output not correct for dependencies > --- > > Key: MPIR-296 > URL: https://jira.codehaus.org/browse/MPIR-296 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Affects Versions: 2.7 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Trivial > Fix For: 2.8 > > > Hi, > I found little missleading dependency information for SBT generated by the > Info Reports Plugin[1]. > I think the line 183 of DependencyInformationReport.java[2] needs to be fixed > by replacing with %%: > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" %% \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > Could someone update this? > Please let me know if you need additional information. > Kind regards, > Jentsch -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-296) SBT Output not correct for dependencies
[ https://jira.codehaus.org/browse/MPIR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MPIR-296. Resolution: Fixed Fixed in [r1604171|http://svn.apache.org/r1604171] > SBT Output not correct for dependencies > --- > > Key: MPIR-296 > URL: https://jira.codehaus.org/browse/MPIR-296 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Affects Versions: 2.7 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Trivial > Fix For: 2.8 > > > Hi, > I found little missleading dependency information for SBT generated by the > Info Reports Plugin[1]. > I think the line 183 of DependencyInformationReport.java[2] needs to be fixed > by replacing with %%: > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" %% \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > Could someone update this? > Please let me know if you need additional information. > Kind regards, > Jentsch -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5473) Backwards compatibility issue in MavenProjectBuilder.build(...)
[ https://jira.codehaus.org/browse/MNG-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5473. -- Resolution: Won't Fix > Backwards compatibility issue in MavenProjectBuilder.build(...) > --- > > Key: MNG-5473 > URL: https://jira.codehaus.org/browse/MNG-5473 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.0.4 > Environment: Mac OS 10.8.3 with Apple JDK 1.6.0_45 >Reporter: Anders Hammar > Attachments: compat-issue.zip > > > I'm running into a NPE when using the compat lib of Maven 3. Attached is a > test project with unit test code that works with Maven 2.2.1 deps but fails > with Maven 3.0.4 deps. > To switch between Maven 2 and Maven 3, the deps in the pom needs to be > altered (see comments). If built as-si it will use Maven 3.0.4 deps and fail. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2199) Support version ranges in parent elements
[
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2199:
---
Fix Version/s: (was: Issues to be reviewed for 4.x)
3.2.2
> Support version ranges in parent elements
> -
>
> Key: MNG-2199
> URL: https://jira.codehaus.org/browse/MNG-2199
> Project: Maven
> Issue Type: Wish
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 2.0.3
>Reporter: Christian Schulte
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
> Attachments: MNG-2199-3.0.4.patch, MNG-2199-3.0.4.patch,
> MNG-2199-3.1.0-alpha-1.patch, MNG-2199.patch, MNG-2199.patch, MNG-2199.patch,
> MNG-2199.patch, MNG-2199.patch, MNG-2199.patch
>
>
> It would be great if Maven supports version ranges when specifying parent
> artifacts in a multi-module build. Currently this does not work.
> {code:xml}
> artifactId
> groupId
> [2.0, 2.0.1]
> {code}
> {noformat}[INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> 2.0.1]/artifactId-[2.0, 2.0.1].pom{noformat}
> Additionally it would be great if this
> {code:xml}
> artifactId
> groupId
> [2.0, ${pom.version}]
> {code}
> {noformat}[INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> ${pom.version}]/artifactId-[2.0, ${pom.version}].pom{noformat}
> would also work, if the version is specified in the same pom.xml which
> defines this parent definition.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5588) Scope import in pluginManagement
[
https://jira.codehaus.org/browse/MNG-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5588:
---
Component/s: FDPFC
> Scope import in pluginManagement
>
>
> Key: MNG-5588
> URL: https://jira.codehaus.org/browse/MNG-5588
> Project: Maven
> Issue Type: Wish
> Components: Dependencies, FDPFC
>Affects Versions: 3.1.1
>Reporter: Romain N
>
> I can do this in dependencyManagement to define dependencies versions:
> {code}
>
> test
> test
> 1
>import
>pom
>
> {code}
> It could be great to can do the same things in pluginManagements to define
> version plugin and default behavior.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1977: --- Component/s: FDPFC > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven > Issue Type: New Feature > Components: FDPFC, POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3397) [RFC] change the POM to use attributes
[ https://jira.codehaus.org/browse/MNG-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3397: --- Component/s: FDPFC > [RFC] change the POM to use attributes > -- > > Key: MNG-3397 > URL: https://jira.codehaus.org/browse/MNG-3397 > Project: Maven > Issue Type: Bug > Components: FDPFC, POM >Affects Versions: 2.0.8 >Reporter: Brett Porter > Fix For: Issues to be reviewed for 4.x > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5102: --- Component/s: FDPFC > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://jira.codehaus.org/browse/MNG-5102 > Project: Maven > Issue Type: Wish > Components: FDPFC, POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-50) POM element for coding standard/formatting descriptor
[ https://jira.codehaus.org/browse/MNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-50: - Component/s: FDPFC > POM element for coding standard/formatting descriptor > - > > Key: MNG-50 > URL: https://jira.codehaus.org/browse/MNG-50 > Project: Maven > Issue Type: New Feature > Components: FDPFC, POM >Reporter: Jason van Zyl >Priority: Minor > Fix For: Issues to be reviewed for 4.x > > > Add a field to the POM that describes the coding standard used by a project. > This value could then be used to create a link to a standard set of documents > describing the chose coding standard: sun, turbine, gnu or what have you. > This could possibly be combined with some other properties that might > generally control source formatting and verification type plugins like > checkstyle. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-296) SBT Output not correct for dependencies
[ https://jira.codehaus.org/browse/MPIR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348476#comment-348476 ] Karl-Heinz Marbaise edited comment on MPIR-296 at 6/20/14 9:14 AM: --- Fixed in [r1604171|http://svn.apache.org/r1604171] Thanks to D. Jentsch. was (Author: khmarbaise): Fixed in [r1604171|http://svn.apache.org/r1604171] > SBT Output not correct for dependencies > --- > > Key: MPIR-296 > URL: https://jira.codehaus.org/browse/MPIR-296 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Affects Versions: 2.7 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Trivial > Fix For: 2.8 > > > Hi, > I found little missleading dependency information for SBT generated by the > Info Reports Plugin[1]. > I think the line 183 of DependencyInformationReport.java[2] needs to be fixed > by replacing with %%: > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies += > \"%s\" %% \"%s\" %% \"%s\"", > groupId, artifactId, version ) ); > Could someone update this? > Please let me know if you need additional information. > Kind regards, > Jentsch -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRRESOURCES-65) Plugin not thread safe (java.util.ConcurrentModificationException)
[
https://jira.codehaus.org/browse/MRRESOURCES-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MRRESOURCES-65.
-
Resolution: Fixed
Assignee: Kristian Rosenvold (was: Daniel Kulp)
This issue has been fixed in maven core and will be available in some core
version >3.2.2
> Plugin not thread safe (java.util.ConcurrentModificationException)
> --
>
> Key: MRRESOURCES-65
> URL: https://jira.codehaus.org/browse/MRRESOURCES-65
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Olivier Lamy
>Assignee: Kristian Rosenvold
>Priority: Critical
>
> stack trace
> {code}
> Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 13 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
> at java.util.Hashtable.putAll(Hashtable.java:465)
> at
> org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.getProjects(ProcessRemoteResourcesMojo.java:663)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.configureVelocityContext(ProcessRemoteResourcesMojo.java:997)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:511)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRRESOURCES-65) Plugin not thread safe (java.util.ConcurrentModificationException)
[
https://jira.codehaus.org/browse/MRRESOURCES-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348483#comment-348483
]
Kristian Rosenvold edited comment on MRRESOURCES-65 at 6/20/14 10:23 AM:
-
This issue has been fixed in maven core
(4da87163f9da3cdd44e5a9ac5cc050225e2692aa) and will be available in some core
version >3.2.2
was (Author: krosenvold):
This issue has been fixed in maven core and will be available in some core
version >3.2.2
> Plugin not thread safe (java.util.ConcurrentModificationException)
> --
>
> Key: MRRESOURCES-65
> URL: https://jira.codehaus.org/browse/MRRESOURCES-65
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Olivier Lamy
>Assignee: Kristian Rosenvold
>Priority: Critical
>
> stack trace
> {code}
> Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 13 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
> at java.util.Hashtable.putAll(Hashtable.java:465)
> at
> org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.getProjects(ProcessRemoteResourcesMojo.java:663)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.configureVelocityContext(ProcessRemoteResourcesMojo.java:997)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:511)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-75) Squash indexer-artifact and indexer-core
[ https://jira.codehaus.org/browse/MINDEXER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348485#comment-348485 ] Martin Todorov commented on MINDEXER-75: What would be the name of the renamed module -- indexer-artifact, or indexer-core? > Squash indexer-artifact and indexer-core > > > Key: MINDEXER-75 > URL: https://jira.codehaus.org/browse/MINDEXER-75 > Project: Maven Indexer > Issue Type: Task >Reporter: Tamás Cservenák >Priority: Minor > > This separation is a legacy, while this component was part of Sonatype Nexus. > There is no reason to have the 10 classes separated now. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-32) Make ArtifactInfo extensible
[ https://jira.codehaus.org/browse/MINDEXER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348486#comment-348486 ] Martin Todorov commented on MINDEXER-32: For which fields would it make sense to introduce getters and setters? > Make ArtifactInfo extensible > > > Key: MINDEXER-32 > URL: https://jira.codehaus.org/browse/MINDEXER-32 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > > Make ArtifactInfo extensible. Currently this class "bleeds" from multiple > wounds: no setters and fixed fields. > This makes introduction of new fields (by core or by some extension > introducing new IndexCreator) nearly impossible, and is laborious. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-340) site inheritance controllable
Benson Margulies created MSHARED-340: Summary: site inheritance controllable Key: MSHARED-340 URL: https://jira.codehaus.org/browse/MSHARED-340 Project: Maven Shared Components Issue Type: New Feature Reporter: Benson Margulies Sometimes a project wishes to use a parent, but _not_ use anything to do the parent's site descriptor. In theory, this could be arranged by having a grandparent with only the non-site content, but it's a pain to refactor just for this. DOD: the top-level site element has an 'inherit' attribute. Extra credit: individual elements below it do, too. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-90) site inheritance controllable
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies moved MSHARED-340 to DOXIASITETOOLS-90: Attachment Licence (Apache) : Grant license to ASF for inclusion in ASF works (as per the http://www.apache.org/licenses/LICENSE-2.0";>Apache License §5) Key: DOXIASITETOOLS-90 (was: MSHARED-340) Project: Maven Doxia Sitetools (was: Maven Shared Components) > site inheritance controllable > - > > Key: DOXIASITETOOLS-90 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-90 > Project: Maven Doxia Sitetools > Issue Type: New Feature >Reporter: Benson Margulies > > Sometimes a project wishes to use a parent, but _not_ use anything to do the > parent's site descriptor. In theory, this could be arranged by having a > grandparent with only the non-site content, but it's a pain to refactor just > for this. > DOD: the top-level site element has an 'inherit' attribute. > Extra credit: individual elements below it do, too. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-90) site inheritance controllable
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348488#comment-348488 ] Benson Margulies commented on DOXIASITETOOLS-90: Work done in 1604218. DOXIASITETOOLS-90: site inheritance controllable * Added combine.self attribute to site descriptor, by analogy to plugin configuration. * exempted some batik from the enforcer; otherwise won't build. > site inheritance controllable > - > > Key: DOXIASITETOOLS-90 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-90 > Project: Maven Doxia Sitetools > Issue Type: New Feature >Reporter: Benson Margulies > Fix For: 1.6 > > > Sometimes a project wishes to use a parent, but _not_ use anything to do the > parent's site descriptor. In theory, this could be arranged by having a > grandparent with only the non-site content, but it's a pain to refactor just > for this. > DOD: the top-level site element has an 'inherit' attribute. > Extra credit: individual elements below it do, too. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-90) site inheritance controllable
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed DOXIASITETOOLS-90. -- Resolution: Fixed Fix Version/s: 1.6 Assignee: Benson Margulies > site inheritance controllable > - > > Key: DOXIASITETOOLS-90 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-90 > Project: Maven Doxia Sitetools > Issue Type: New Feature >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 1.6 > > > Sometimes a project wishes to use a parent, but _not_ use anything to do the > parent's site descriptor. In theory, this could be arranged by having a > grandparent with only the non-site content, but it's a pain to refactor just > for this. > DOD: the top-level site element has an 'inherit' attribute. > Extra credit: individual elements below it do, too. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-90) site inheritance controllable
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated DOXIASITETOOLS-90: Component/s: Decoration model > site inheritance controllable > - > > Key: DOXIASITETOOLS-90 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-90 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Decoration model >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 1.6 > > > Sometimes a project wishes to use a parent, but _not_ use anything to do the > parent's site descriptor. In theory, this could be arranged by having a > grandparent with only the non-site content, but it's a pain to refactor just > for this. > DOD: the top-level site element has an 'inherit' attribute. > Extra credit: individual elements below it do, too. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-754) Require Tag/Branch Command to return the entire source tree is impractical
[ https://jira.codehaus.org/browse/SCM-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-754: - Description: Currently the tag command when using with ScmFileSet that has no excludes/includes, it returns the entire file list of the source tree. and the TCK check for it It makes sense for ScmFileSet with a know list, but not practical when the list is empty. It can blew up memory and slow for a large source tree. We should allow this exception was: Currently the tag command when using with ScmFileSet that has no excludes/includes, it returns the entire file list of the source tree. and the TCK check for it It makes sense for ScmFileSet with a know list, but not practical when the list is empty. It can blew up memory and slow for a ever large source tree. We should allow this exception Summary: Require Tag/Branch Command to return the entire source tree is impractical (was: Require Tag Command to return the entire source tree is impractical) > Require Tag/Branch Command to return the entire source tree is impractical > -- > > Key: SCM-754 > URL: https://jira.codehaus.org/browse/SCM-754 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-api >Affects Versions: 1.9 >Reporter: Dan Tran > Fix For: 1.10 > > > Currently the tag command when using with ScmFileSet that has no > excludes/includes, it returns the entire file list of the source tree. and > the TCK check for it > It makes sense for ScmFileSet with a know list, but not practical when the > list is empty. It can blew up memory and slow for a large source tree. > We should allow this exception -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-755) Inject SecDispatcher into TCK base test case
[ https://jira.codehaus.org/browse/SCM-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-755. Resolution: Fixed Assignee: Dan Tran fixed at https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commit;h=a72a7cb46226266704994b5d9a57a0ab64259db8 > Inject SecDispatcher into TCK base test case > > > Key: SCM-755 > URL: https://jira.codehaus.org/browse/SCM-755 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-api >Affects Versions: 1.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.10 > > > so that, TCK from provider like Perforce can decrypt password store under and > external file -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-756) TCK should invoke EditCommand for required edit mode provider like Perforce
[ https://jira.codehaus.org/browse/SCM-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-756. Resolution: Fixed Assignee: Dan Tran fixed at https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commit;h=a72a7cb46226266704994b5d9a57a0ab64259db8 > TCK should invoke EditCommand for required edit mode provider like Perforce > --- > > Key: SCM-756 > URL: https://jira.codehaus.org/browse/SCM-756 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-api >Affects Versions: 1.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.10 > > > TCK should invoke EditCommand for required edit mode provider like Perforce > when attempt to change a file -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-754) Require Tag/Branch Command to return the entire source tree is impractical
[ https://jira.codehaus.org/browse/SCM-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-754. Resolution: Fixed Assignee: Dan Tran fixed at https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commit;h=a72a7cb46226266704994b5d9a57a0ab64259db8 > Require Tag/Branch Command to return the entire source tree is impractical > -- > > Key: SCM-754 > URL: https://jira.codehaus.org/browse/SCM-754 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-api >Affects Versions: 1.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.10 > > > Currently the tag command when using with ScmFileSet that has no > excludes/includes, it returns the entire file list of the source tree. and > the TCK check for it > It makes sense for ScmFileSet with a know list, but not practical when the > list is empty. It can blew up memory and slow for a large source tree. > We should allow this exception -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-757) bootstrap/checkout/export goals now requires -Dproject.basedir=. set at command line
Dan Tran created SCM-757: Summary: bootstrap/checkout/export goals now requires -Dproject.basedir=. set at command line Key: SCM-757 URL: https://jira.codehaus.org/browse/SCM-757 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.9 Reporter: Dan Tran This used to work before -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-757) bootstrap/checkout/export goals now requires -Dproject.basedir=. set at command line
[ https://jira.codehaus.org/browse/SCM-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-757: - Fix Version/s: 1.10 Assignee: Dan Tran > bootstrap/checkout/export goals now requires -Dproject.basedir=. set at > command line > > > Key: SCM-757 > URL: https://jira.codehaus.org/browse/SCM-757 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Affects Versions: 1.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.10 > > > This used to work before -- This message was sent by Atlassian JIRA (v6.1.6#6162)
