[jira] (SUREFIRE-934) Remove getLocatedClasses() and size() from TestsToRun
[
https://jira.codehaus.org/browse/SUREFIRE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315312#comment-315312
]
Andreas Gudian commented on SUREFIRE-934:
-
OK, I pulled from apache.org and created the patch based on that. So the
pull-request on github also contains the commit for SUREFIRE-933, but I guess
that's no problem for git. :)
-Pembedded worked quite fine, definetly faster (mvn 3.0.4). On the first run, I
had a failure in Surefire570MultipleReportDirectoriesIT - a second try was
successful. I'll give it some more spins with and without -Pembedded to see if
I can reproduce that.
> Remove getLocatedClasses() and size() from TestsToRun
> -
>
> Key: SUREFIRE-934
> URL: https://jira.codehaus.org/browse/SUREFIRE-934
> Project: Maven Surefire
> Issue Type: Task
> Components: process forking
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Priority: Minor
>
> In order to avoid any further confusion with
> {{TestsToRun.getLocatedClasses()}} and {{TestsToRun.size()}} (as in
> SUREFIRE-933), I propose to remove these methods completely.
> Basically, these methods are used in the TestNG provider at some limited
> places, and in {{DefaultRunOrderCalculator}} during the scan for tests (in
> the main surefire process).
> If you have any objections, please close this issue. Otherwise, I will just
> do it and send a pull request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-934) Remove getLocatedClasses() and size() from TestsToRun
[
https://jira.codehaus.org/browse/SUREFIRE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315313#comment-315313
]
Kristian Rosenvold commented on SUREFIRE-934:
-
This is the stuff git was built for ;)
In general, if you have a spurious IT failure, it is best to preserve the
contents of
surefire-integration-tests/target/Surefire570MultipleReportDirectoriesIT/
and see if it's possible to understand what happened, possibly by examining
the logs/content inside that directory.
Personally I am much more troubled by ConcurrentReporterManagerTest failing
every now and then, and that's a unit test (damn it). I am trying to find out
about that
> Remove getLocatedClasses() and size() from TestsToRun
> -
>
> Key: SUREFIRE-934
> URL: https://jira.codehaus.org/browse/SUREFIRE-934
> Project: Maven Surefire
> Issue Type: Task
> Components: process forking
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Priority: Minor
>
> In order to avoid any further confusion with
> {{TestsToRun.getLocatedClasses()}} and {{TestsToRun.size()}} (as in
> SUREFIRE-933), I propose to remove these methods completely.
> Basically, these methods are used in the TestNG provider at some limited
> places, and in {{DefaultRunOrderCalculator}} during the scan for tests (in
> the main surefire process).
> If you have any objections, please close this issue. Otherwise, I will just
> do it and send a pull request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5249) inherit scm in superPom
[
https://jira.codehaus.org/browse/MNG-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315315#comment-315315
]
Darryl L. Miles commented on MNG-5249:
--
This convention is not documented (or useful for non SVN / Apache Foundation
remote SCM system setups). I would expect this to be documented here
https://maven.apache.org/pom.html#SCM
It would be useful to remove the convention of appending the "/${parent.name}"
value onto the end of the elements for URLs such as
and .
Instead have Maven configure a system variable like ${maven.scm.path} which
would be "/parent-parent/parent" in the case where we have foobar:project
inherit from foobar:parent inherit from foobar:parent-parent which has
elements configured. This way when compatibility is broken in some future
release those users wishing to keep the old behaviour only need to add
${maven.scm.path} to the end of their URLs (in their equivalent
foobar:parent-parent pom.xml)
> inherit scm in superPom
> ---
>
> Key: MNG-5249
> URL: https://jira.codehaus.org/browse/MNG-5249
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: Issues to be reviewed for 3.x
> Environment: maven 3.0.3
>Reporter: Jose Manuel Prieto
>
> It's similar to http://jira.codehaus.org/browse/MNG-2006 but with GIT.
> Show too:
> http://mail-archives.apache.org/mod_mbox/maven-users/201202.mbox/%3CCAAUMjNbO_o4WhwTvGoZueVLsaM5XULczdrp%3D9eioMV2YH9gk1A%40mail.gmail.com%3E
> and reponses into maven user lists
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-331) SCM urls are broken for all modules, except the parent
[ https://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315316#comment-315316 ] Darryl L. Miles commented on MRELEASE-331: -- One possible workaround is to try adding a "#" to end of the text in the super POM that sets the URL elements. This causes the unwanted appended part to become a URL fragment. You maybe lucky enough that your SCM provider ignores URL fragments. > SCM urls are broken for all modules, except the parent > --- > > Key: MRELEASE-331 > URL: https://jira.codehaus.org/browse/MRELEASE-331 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 >Reporter: Vincent Siveton >Priority: Blocker > Labels: scrub-review-started > > This comes from the parent pom, which is missing a / at the end of the scm > urls. > See: > http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4508) No way to avoid adding artifactId to site urls
[
https://jira.codehaus.org/browse/MNG-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315317#comment-315317
]
Darryl L. Miles commented on MNG-4508:
--
Remove the inheritance rules but provide a maven configured variable
${maven.project.path} or something that will becomes "/parent-parent/parent" in
deepest level of a 3 level project. The super POM will be an empty string.
The mid-level will be "/parent-parent". Now users get the best of both worlds
without being chained to the convention.
> No way to avoid adding artifactId to site urls
> --
>
> Key: MNG-4508
> URL: https://jira.codehaus.org/browse/MNG-4508
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Richard van der Hoff
>Priority: Minor
> Fix For: 3.2
>
>
> Currently, whenever a child pom inherits from a parent (and doesn't override
> the relevant settings), both project.url and
> project.distributionManagement.site.url have the name of the child artifact
> appended.
> It would be nice to be able to have something like
> :code:
> scpexe://host/blah/${project.artifactId}/${project.version}
> :code:
> and have this inherited to all child poms in the obvious way.
> My usecase for this is that we have a single parent pom for all our projects,
> with useful settings such as distributionManagement, and I'd like to be able
> to deploy their sites to a single directory and have Apache generate me a
> directory listing for all the child projects. However, I curently have no way
> of releasing the parent project without obliterating the list of child
> projects.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5407) Change MavenITmng1830ShowVersionTest to account for SHA1 as version
[ https://jira.codehaus.org/browse/MNG-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315318#comment-315318 ] Anders Hammar commented on MNG-5407: Sorry, my bad not fixing this. You want me to have a look? > Change MavenITmng1830ShowVersionTest to account for SHA1 as version > --- > > Key: MNG-5407 > URL: https://jira.codehaus.org/browse/MNG-5407 > Project: Maven 2 & 3 > Issue Type: New Feature > Environment: >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.1.0 > > > Buid from Git we now have output like the following given mvn -v: > Apache Maven 3.1-SNAPSHOT (d6544c4814a91c15d67a05d60e18f91a72fc57a9; > 2012-12-08 14:09:52-0500) > So we need add a regex to look for that in the test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5407) Change MavenITmng1830ShowVersionTest to account for SHA1 as version
[ https://jira.codehaus.org/browse/MNG-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315319#comment-315319 ] Anders Hammar commented on MNG-5407: Seems you fixed this in https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=b73b73215021e93476f7c6800e696c1e74e6bd57 > Change MavenITmng1830ShowVersionTest to account for SHA1 as version > --- > > Key: MNG-5407 > URL: https://jira.codehaus.org/browse/MNG-5407 > Project: Maven 2 & 3 > Issue Type: New Feature > Environment: >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.1.0 > > > Buid from Git we now have output like the following given mvn -v: > Apache Maven 3.1-SNAPSHOT (d6544c4814a91c15d67a05d60e18f91a72fc57a9; > 2012-12-08 14:09:52-0500) > So we need add a regex to look for that in the test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315320#comment-315320 ] Alex Collins commented on MRESOURCES-171: - OK. So we've established that filtering changes the encoding. We've also established that this is inconsistent as it is a side-effect of filtering; unfiltered resources are unchanged. Finally, filtering understands "source encoding" as "target encoding" as this is the encoding it converts files into; if it understood it as source encoding, then it would not have to change the encoding. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://jira.codehaus.org/browse/MRESOURCES-171 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-272) OutOfMemoryError when coping large files
[ https://jira.codehaus.org/browse/WAGON-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315321#comment-315321 ] Martin Todorov commented on WAGON-272: -- A workaround for this is illustrated [here|http://stackoverflow.com/questions/13767525/my-artifact-seems-to-big-to-be-deployed-by-maven-what-can-i-do]. > OutOfMemoryError when coping large files > > > Key: WAGON-272 > URL: https://jira.codehaus.org/browse/WAGON-272 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-5 >Reporter: Rakesh Arora >Assignee: Brett Porter > > Getting OutOfMemory issue when coping/deploying large files. Check the stack > trace below. > We traced the issue to wagon-http-lightweight using > PosterOutputStream/ByteArrayOutputStream.write(). This method consumes lot of > memory when dealing with large files as reported here: > https://issues.alfresco.com/jira/browse/ETHREEOH-974 > In our case, we are trying to deploy a around 600M file and have set the > maximum heap space to 1024M (-Xmx1024m). We are still running out of memory. > We are using maven 2.0.8 but had the same issue when tried with 2.1.0 version. > ;-STACK TRACE- > [DEBUG] -- end configuration -- [INFO] [deploy:deploy-file] > Uploading: http:foo/1.0/foo-1.0.zip > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Java heap space > [INFO] > > [DEBUG] Trace > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2786) > at > java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) > at > sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) > at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338) > at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305) > at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267) > at > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:2 > 38) > at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143) > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(Lightw > eightHttpWagon.java:148) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(D > efaultWagonManager.java:237) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(Def > aultWagonManager.java:153) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def > aultArtifactDeployer.java:80) > at > org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo. > java:240) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone > Goal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:143) > at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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) > [INFO] > > [INFO] Total time: 1 minute 22 seconds > [INFO] Finished at: Fri Jun 26 15:10:36 EDT 200
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315322#comment-315322 ] Anders Hammar commented on MRESOURCES-171: -- I'm not sure I understand the problem. If you have configured your source encoding to UTF-8, you should only use UTF-8 char encoding in your resources. The default settings of the resources plugin will then use that encoding (UTF-8) as the target encoding, which is the correct behavior IMO. I think you have the wrong encoding in the source file and that's the problem. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://jira.codehaus.org/browse/MRESOURCES-171 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315324#comment-315324 ] Alex Collins commented on MRESOURCES-171: - Ah. I have choose a confusing example. My properties files are in ISO-8859-1 (as they cannot be anything else, e.g. http://stackoverflow.com/questions/4659929/how-to-use-utf-8-in-resource-properties-with-resourcebundle, side-note: spot the hacky solution suggested further down the page - yuk). If I converted them to UTF-8, they would be invalid. But this is perhaps a red herring. I'm not reporting that it's failing to make a special case for properties files. Firstly, I'm saying is if you set the source encoding then when they are filtered, they are converted ***from ISO-8859-1*** into UTF-8. But I've set the source encoding as UTF-8! It shouldn't do any conversion at all, regardless of the fact they're in the wrong encoding. It's directly contravening the configuration. They should be not be converted! I have told the plugin that they are already in UTF-8, it should go "OK the file is in UTF-8". Not "it looks odd, I'll do some silent and un-requested conversion for them". Additionally, the "source encoding" should only affect the treatment of source files, but it appears to affect the treatment of the "target files". If a properties file is going into a jar, it MUST be ISO-8599-1!!! But the plugin knowingly causes a faulty jar file. Perhaps Maven's lacking a project.build.targetEncoding property? If you need to convince yourself, try creating a properties file with a sequence of non-ASCII characters that is valid in both UTF-8 ISO-8859-1 (if this is possible, which it might not be). > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://jira.codehaus.org/browse/MRESOURCES-171 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5405) Execute goal does not passes from mojos.xml pluginMetadata
[ https://jira.codehaus.org/browse/MNG-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MNG-5405: Attachment: MNG-5405.patch Here is the simple patch for this bug. Hopefully, we can get it released soon... > Execute goal does not passes from mojos.xml pluginMetadata > -- > > Key: MNG-5405 > URL: https://jira.codehaus.org/browse/MNG-5405 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.4 >Reporter: Ben Tatham > Attachments: MNG-5405.patch > > > In pluginMetadata (.mojos.xml) that describes an ant-based plugin, > adding > > foo:bar > > Doesn't make its way in to the plugin.xml. > I tracked down the bug to a missing setter in: > maven-plugin-tools-model-3.2 > org.apache.maven.plugin.tools.model.PluginMetadataParser > line 131 > When copying the LifecycleExecution out of the Mojo into the MojoDescriptor, > it sets the execution lifecycle and phase, but skips the goal. > Trivial fix, not even worth a path, imho. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315332#comment-315332
]
Lukas Theussl commented on MSITE-669:
-
IIRC the module structure should be irrelevant for relative link resolution,
what counts is the distributionMngmnt.url. Did you specify correct url's in all
your sub-projects?
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jörelid
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315337#comment-315337 ] Eric Pabst commented on MNG-2802: - It's very frustrating that there is no apparent progress on this. It was reported years ago and is still hurting productivity significantly. > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2802) Concurrent-safe access to local Maven repository
[
https://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315341#comment-315341
]
Jason van Zyl commented on MNG-2802:
You can drop this implementation into your ${M2_HOME}/lib/ext:
http://search.maven.org/#artifactdetails%7Cio.tesla%7Ctesla-concurrent-localrepo%7C0.0.2%7Cjar
I will be integrating this with the Aether version once Maven core is updated
to Aether 0.9.0.M1
> Concurrent-safe access to local Maven repository
>
>
> Key: MNG-2802
> URL: https://jira.codehaus.org/browse/MNG-2802
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Stepan Roh
>Assignee: John Casey
> Fix For: Issues to be reviewed for 3.x
>
>
> It seems that access to local Maven repository is not concurrent-safe that is
> multiple Mavens running in parallel may damage contents of local Maven
> repository. It would be a nice improvement, because sharing of local
> repository will lower the need for contacting any other repository. I know
> that Maven proxy can be used, but that adds another layer which may
> unnecessarily stress the machine it runs on.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-934) Remove getLocatedClasses() and size() from TestsToRun
[
https://jira.codehaus.org/browse/SUREFIRE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-934.
---
Resolution: Fixed
Fix Version/s: 2.13
Assignee: Kristian Rosenvold
Fixed in f35f1efb55696b0202ff042d5d1058c5c5b3cc73, thanks for the patch!
> Remove getLocatedClasses() and size() from TestsToRun
> -
>
> Key: SUREFIRE-934
> URL: https://jira.codehaus.org/browse/SUREFIRE-934
> Project: Maven Surefire
> Issue Type: Task
> Components: process forking
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.13
>
>
> In order to avoid any further confusion with
> {{TestsToRun.getLocatedClasses()}} and {{TestsToRun.size()}} (as in
> SUREFIRE-933), I propose to remove these methods completely.
> Basically, these methods are used in the TestNG provider at some limited
> places, and in {{DefaultRunOrderCalculator}} during the scan for tests (in
> the main surefire process).
> If you have any objections, please close this issue. Otherwise, I will just
> do it and send a pull request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315365#comment-315365
]
Steven Swor commented on MNG-5091:
--
Any chance the patch with the {{--validation-level}} switch will make it into
3.0.x?
> Add option to fail build if WARNING's appear in POM
> ---
>
> Key: MNG-5091
> URL: https://jira.codehaus.org/browse/MNG-5091
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, POM
>Affects Versions: 3.0.3
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.x
>
> Attachments: MNG-5091-maven-embedder.patch
>
>
> It would be nice to have the option to let a build fail if something like
> this will appear:
> {code}
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version 1.6.1
> @ line 28, column 14
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {code}
> This shoud be done for WARNING's in case of missing versions for plugins etc.
> Currently it is possible to set the Validation leven in Jenkins/Hudson
> already but it is not possible on command line. So an option on command line
> like:
> {code}
> mvn --fail-warning ...
> {code}
> would be great. Or may be a good supplemental option to set the validation
> level like:
> {code}
> mvn --validation-level MINIMAL
> mvn --validation-level MAVEN20
> mvn --validation-level MAVEN30
> mvn --validation-level MAVEN31
> mvn --validation-level DEFAULT
> {code}
> or may be both. May this might be an enhancement for Maven 3.0.4 ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315371#comment-315371
]
Steven Swor commented on MNG-5091:
--
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which coerces it down to
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}
during the {{validate}} phase. Add the following to your
{{project.build.plugins}} section
{code}
org.codehaus.gmaven
gmaven-plugin
1.5
2.0
change-validation-level
validate
execute
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel > desiredValidationLevel) {
log.warn("Correcting validation level. Was {}. Now
{}", request.validationLevel, desiredValidationLevel)
request.validationLevel = desiredValidationLevel
}
org.codehaus.groovy
groovy-all
2.0.5
org.codehaus.gmaven.runtime
gmaven-runtime-2.0
1.5
org.codehaus.groovy
groovy-all
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
> Add option to fail build if WARNING's appear in POM
> ---
>
> Key: MNG-5091
> URL: https://jira.codehaus.org/browse/MNG-5091
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, POM
>Affects Versions: 3.0.3
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.x
>
> Attachments: MNG-5091-maven-embedder.patch
>
>
> It would be nice to have the option to let a build fail if something like
> this will appear:
> {code}
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version 1.6.1
> @ line 28, column 14
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {code}
> This shoud be done for WARNING's in case of missing versions for plugins etc.
> Currently it is possible to set the Validation leven in Jenkins/Hudson
> already but it is not possible on command line. So an option on command line
> like:
> {code}
> mvn --fail-warning ...
> {code}
> would be great. Or may be a good supplemental option to set the validation
> level like:
> {code}
> mvn --validation-level MINIMAL
> mvn --validation-level MAVEN20
> mvn --validation-level MAVEN30
> mvn --validation-level MAVEN31
> mvn --validation-level DEFAULT
> {code}
> or may be both. May this might be an enhancement for Maven 3.0.4 ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315371#comment-315371
]
Steven Swor edited comment on MNG-5091 at 12/10/12 5:51 PM:
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which checks the validation level
during the {{validate}} phase and fails the build if it's above
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}.
Add the following to your {{project.build.plugins}} section
{code}
org.codehaus.gmaven
gmaven-plugin
1.5
2.0
change-validation-level
validate
execute
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel > desiredValidationLevel) {
/*
* Comment out the following line and uncomment the two
below
* to coerce the validation level instead of failing
the build
*/
throw new RuntimeException("Validation level is too
high")
// log.warn("Correcting validation level. Was {}. Now
{}", request.validationLevel, desiredValidationLevel)
// request.validationLevel = desiredValidationLevel
}
org.codehaus.groovy
groovy-all
2.0.5
org.codehaus.gmaven.runtime
gmaven-runtime-2.0
1.5
org.codehaus.groovy
groovy-all
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
was (Author: sworisbreathing):
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which coerces it down to
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}
during the {{validate}} phase. Add the following to your
{{project.build.plugins}} section
{code}
org.codehaus.gmaven
gmaven-plugin
1.5
2.0
change-validation-level
validate
execute
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel > desiredValidationLevel) {
log.warn("Correcting validation level. Was {}. Now
{}", request.validationLevel, desiredValidationLevel)
request.validationLevel = desiredValidationLevel
}
org.codehaus.groovy
groovy-all
2.0.5
org.codehaus.gmaven.runtime
gmaven-runtime-2.0
1.5
org.codehaus.groovy
groovy-all
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
> Add option to fail build if WARNING's appear in POM
> ---
>
> Key: MNG-5091
> URL: https://jira.codehaus.org/browse/MNG-5091
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, POM
>Affects Versions: 3.0.3
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.x
>
> Attachments: MNG-5091-maven-embedder.patch
>
>
> It would be nice to have the option to let a build fail if something like
> this will appear:
> {code}
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version 1.6.1
> @ line 28, co
[jira] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315371#comment-315371
]
Steven Swor edited comment on MNG-5091 at 12/10/12 5:54 PM:
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which checks the validation level
during the {{validate}} phase and fails the build if it's above
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}.
Add the following to your {{project.build.plugins}} section
{code}
org.codehaus.gmaven
gmaven-plugin
1.5
2.0
change-validation-level
validate
execute
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel > desiredValidationLevel) {
/*
* Comment out the following line and uncomment the two
below
* to coerce the validation level instead of failing
the build
*/
throw new RuntimeException("Validation level is too
high")
// log.warn("Correcting validation level. Was {}. Now
{}", request.validationLevel, desiredValidationLevel)
// request.validationLevel = desiredValidationLevel
}
org.codehaus.groovy
groovy-all
2.0.5
org.codehaus.gmaven.runtime
gmaven-runtime-2.0
1.5
org.codehaus.groovy
groovy-all
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
The trick works because gmaven injects the {{MavenSession}} into the script,
which has access to the {{ProjectBuildingRequest}} via its
{{MavenExecutionRequest}}. I'd suggest having a look at the Maven core API
docs and maven build API docs. You might be able to get access to the warnings
somehow.
was (Author: sworisbreathing):
As a workaround, you can use the GMaven plugin to set the validation level
during the Maven build. Here's an example which checks the validation level
during the {{validate}} phase and fails the build if it's above
{{org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0}}.
Add the following to your {{project.build.plugins}} section
{code}
org.codehaus.gmaven
gmaven-plugin
1.5
2.0
change-validation-level
validate
execute
def desiredValidationLevel =
org.apache.maven.model.building.ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_2_0
def request = session.request.projectBuildingRequest
if (request.validationLevel > desiredValidationLevel) {
/*
* Comment out the following line and uncomment the two
below
* to coerce the validation level instead of failing
the build
*/
throw new RuntimeException("Validation level is too
high")
// log.warn("Correcting validation level. Was {}. Now
{}", request.validationLevel, desiredValidationLevel)
// request.validationLevel = desiredValidationLevel
}
org.codehaus.groovy
groovy-all
2.0.5
org.codehaus.gmaven.runtime
gmaven-runtime-2.0
1.5
org.codehaus.groovy
groovy-all
{code}
Note: I'm not sure if forcing GMaven to use Groovy 2 is required. I just
copied an existing usage of the plugin and tweaked it for this example.
> Add option to fail build if WARNING's appear in POM
> ---
>
> Key: MNG-5091
> URL: https://jira.codehaus.org/browse/MNG-5091
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, POM
>Affects V
[jira] (MRELEASE-767) releasing flat multi-module projects using git
[ https://jira.codehaus.org/browse/MRELEASE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315374#comment-315374 ] Kelly Davis commented on MRELEASE-767: -- Ran into this same issue today. The workaround I am currently using is to set pushChanges=false and then manually git push; git push --tags between the release:prepare and release:perform steps. > releasing flat multi-module projects using git > -- > > Key: MRELEASE-767 > URL: https://jira.codehaus.org/browse/MRELEASE-767 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.3.1 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Maven home: /usr/share/maven > Java version: 1.6.0_31, vendor: Apple Inc. > Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac" >Reporter: Jeremy Norris >Assignee: Mark Struberg > > When releasing a project as follows: > ./parent/pom.xml > ./module-a/pom.xml > ./module-b/pom.xml > From the parent directory, with an scm config in the parent pom.xml (only) as > follows: > > scm:git:ssh://github.com/repox.git > > scm:git:ssh://github.com/repox.git > master > https://github.com/view/repox.git > > In org/apache/maven/shared/release/util/ReleaseUtils.java:182 it does this > indiscriminately: > url = realignScmUrl( parentLevels, url ); > This will trim the repo url from 'ssh://github.com/repox.git' -> > 'ssh://github.com', which will cause a failure when pushing the tag. > This type of realignment is not appropriate when using a git scm type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-771) release:prepare tries to push tag with invalid Git URL
[
https://jira.codehaus.org/browse/MRELEASE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315376#comment-315376
]
Darryl L. Miles commented on MRELEASE-771:
--
Related MRELEASE-767 ? The original reporter did not convey the hierarchical
organization of the projects he has. I would guess the affected project is one
or two levels down in module hierarchy.
> release:prepare tries to push tag with invalid Git URL
> --
>
> Key: MRELEASE-771
> URL: https://jira.codehaus.org/browse/MRELEASE-771
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare, scm
>Affects Versions: 2.3.1
> Environment: Debian 6, run form shell
>Reporter: Tuukka Mustonen
>
> Suddenly, after no version change of maven-release-plugin, our
> {{release:prepare}} started to fail into:
> {noformat}
> [INFO] Unable to tag SCM
> Provider message:
> The git-push command failed.
> Command output:
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly
> {noformat}
> The reason appears to be that pushing of the tag uses invalid syntax for git
> command:
> {noformat}
> [INFO] Executing: /bin/sh -c cd "/jenkins/job1" && git push
> ssh://g...@github.mydomain.com myproduct-1.0.0
> {noformat}
> The problem here is that the target URL ({{ssh://g...@github.mydomain.com}})
> is lacking the actual repository identifier
> ({{/MyOrganization/myproduct.git}}) - the plugin is using just
> {{ssh://g...@github.mydomain.com}} while it should be using something like
> {{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
> I cannot come up with a reason why it started to do this so I cannot give
> instructions on to how to reproduce it either. For us, it occurs in one
> repository, while in another one using the same plugin version and
> configuration the problem doesn't occur.
> Apparently the behavior of using ssh-URL instead of {{origin}} as remote
> repository has been there for ages, added in SCM-498.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
