[jira] Commented: (SUREFIRE-449) In multi-module projects, all tests are run for each module in the module tree
[ http://jira.codehaus.org/browse/SUREFIRE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153225#action_153225 ] Luc Willems commented on SUREFIRE-449: -- Hello all , i'm currently using 2.4.2 version of the plugin but still seeing builds of ALL modules. i have a complex multi module project with 3 levels of if grandParent -> parent -> child relations. i'm using Continuum build server and use mvn clean site-deploy as goals to run. i'm not using the report-only options. > In multi-module projects, all tests are run for each module in the module tree > -- > > Key: SUREFIRE-449 > URL: http://jira.codehaus.org/browse/SUREFIRE-449 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.4 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Priority: Blocker > Fix For: 2.4.2 > > Attachments: mvnexec.zip > > > In a multi-module project, since version 2.4, all tests of all modules are > run once for each module. This is *very* bad with many modules & many tests. > Attached is a sample project which contains a parent module and two child > modules. Each of the child modules contains one JUnit test. mvn clean site > runs each test three times (once for the parent and once for each of the two > submodules). When changing the surefire-report-plugin to version 2.3, each > test is run only once, as it is supposed to -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-257) surefire-report reruns tests
[ http://jira.codehaus.org/browse/SUREFIRE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153233#action_153233 ] Luc Willems commented on SUREFIRE-257: -- is there a way to set the report-only options using the cli using -Dx.report-only=true ? this is would fix my automated builds of project sites . > surefire-report reruns tests > > > Key: SUREFIRE-257 > URL: http://jira.codehaus.org/browse/SUREFIRE-257 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin > Environment: maven 2.0 >Reporter: Dirk Sturzebecher > Fix For: 2.x > > Attachments: MSUREFIREREP-6-patch.txt > > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3817) Property inheritance when filtering with multiple profiles is gone
[
http://jira.codehaus.org/browse/MNG-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Buechler reopened MNG-3817:
--
Doh, forgot to test it with 2.0.9 ;) and . . . of course it it a BUG in 2.0.9.
Please comment.
> Property inheritance when filtering with multiple profiles is gone
> ---
>
> Key: MNG-3817
> URL: http://jira.codehaus.org/browse/MNG-3817
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.9
>Reporter: Martin Buechler
>Priority: Blocker
> Fix For: 2.0.9
>
> Attachments: MNG-3817.zip
>
>
> pom.xml:
>
>
> default.properties
>
>
>
>
> first
>
>
> first.properties
>
>
>
>
> second
>
>
> second.properties
>
>
> ...
> default.properties:
> prop=
> first.properties:
> prop=first_value
> second.properties:
> other_prop=${prop}
> since 2.0.9 the value of
> other_prop
> is not replaced and is written as ${prop}, instead of inherit the value
> 'first_value', when executing
>mvn -Pfirst,second process-resources
> This breaks existing configurations badly and I do not see a workaround
> whithout losing the ability to configure in more than one dimension, which
> makes mvn 2.0.9 quite unsuable for project requirements in real life.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3817) Property inheritance when filtering with multiple profiles is gone
[
http://jira.codehaus.org/browse/MNG-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153240#action_153240
]
mdmd edited comment on MNG-3817 at 11/6/08 7:09 AM:
---
Doh, forgot to test it with 2.0.9 and with non empty values, and . . . of
course it IS a major bug in 2.0.9.
was (Author: mdmd):
Doh, forgot to test it with 2.0.9 ;) and . . . of course it it a BUG in
2.0.9. Please comment.
> Property inheritance when filtering with multiple profiles is gone
> ---
>
> Key: MNG-3817
> URL: http://jira.codehaus.org/browse/MNG-3817
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.9
>Reporter: Martin Buechler
>Priority: Blocker
> Fix For: 2.0.9
>
> Attachments: MNG-3817.zip
>
>
> pom.xml:
>
>
> default.properties
>
>
>
>
> first
>
>
> first.properties
>
>
>
>
> second
>
>
> second.properties
>
>
> ...
> default.properties:
> prop=
> first.properties:
> prop=first_value
> second.properties:
> other_prop=${prop}
> since 2.0.9 the value of
> other_prop
> is not replaced and is written as ${prop}, instead of inherit the value
> 'first_value', when executing
>mvn -Pfirst,second process-resources
> This breaks existing configurations badly and I do not see a workaround
> whithout losing the ability to configure in more than one dimension, which
> makes mvn 2.0.9 quite unsuable for project requirements in real life.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-257) surefire-report reruns tests
[
http://jira.codehaus.org/browse/SUREFIRE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153274#action_153274
]
Benjamin Bentmann commented on SUREFIRE-257:
Luc, {{report-only}} is not an option/parameter but a plugin goal and these can
in general not be directly activated via a property from the CLI. You can
however add a [profile|http://maven.apache.org/pom.html#Activation] to your POM
that runs {{report-only}} and have this profile be activated via a system
property.
> surefire-report reruns tests
>
>
> Key: SUREFIRE-257
> URL: http://jira.codehaus.org/browse/SUREFIRE-257
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
> Environment: maven 2.0
>Reporter: Dirk Sturzebecher
> Fix For: 2.x
>
> Attachments: MSUREFIREREP-6-patch.txt
>
>
> surefire-report reruns the tests. In my case this is not just annoying, but
> leads to a failure, as the VM (probably) is reused and leftovers from the
> first tests are (definitly) still present.
> I run maven with: clean package site
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2257) Upload OpenXML4J 1.0-beta
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153284#action_153284 ] Brett Porter commented on MAVENUPLOAD-2257: --- this version seems to differ from the one that was released on sourceforge (200804) - should we be uploading that one instead, or can the project be encouraged to do a second beta release? > Upload OpenXML4J 1.0-beta > - > > Key: MAVENUPLOAD-2257 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2257 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Yegor Kozlov >Assignee: Brett Porter > > Please upload OpenXML4J -beta. We use this library in Apache POI to work with > Open XML files. > Thanks, > Yegor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-362) Site upload is not compatible with sourceforge.net changes
[ http://jira.codehaus.org/browse/MSITE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153322#action_153322 ] johan lindquist commented on MSITE-362: --- Seems you can get a shell - you just need to create it first. The below command creates a time-limited shell. ssh -t ,@shell.sourceforge.net create maven site:deploy succeeded after this (just make sure you change the , to match your details). One issue remains - even though I have copied my public key to the 'shell', it always asks me for a password. > Site upload is not compatible with sourceforge.net changes > -- > > Key: MSITE-362 > URL: http://jira.codehaus.org/browse/MSITE-362 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-7 >Reporter: Marat Radchenko > > After last changes in sf.net infrastructure there are three ways of > uploading stuff to web area: > # sftp > # scp > # rsync over ssh > I've tried two first options and they both failed. Maven uploads zip > file (wagon.zip) and then tries to unzip it. However unzip > command is not available. > As far as I understand, Maven doesn't support site deployment via rsync. > So technically it is impossible to use Maven for site upload to sf.net > See http://sourceforge.net/community/forum/topic.php?id=3518&page for sf.net > announcement on this changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2261) Automatic upload of mockito versions.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153323#action_153323 ] Erik Brakkee commented on MAVENUPLOAD-2261: --- Just to prevent questions: Note that the remote path for rsync is '/'. This path is correct because on the server side, the path is modified to a full pathname of the repository root. This is necessary to prevent access to the full filesystem on my server. > Automatic upload of mockito versions. > - > > Key: MAVENUPLOAD-2261 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2261 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Erik Brakkee > > Authenticity > = > Please contact Szczepan Faber for information about the authenticity of this > request. He is the owner of the mockito.org domain. > Also, my name will appear shortly on the mockito wiki at > http://code.google.com/p/mockito/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2262) jewelcli sync request
jewelcli sync request - Key: MAVENUPLOAD-2262 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2262 Project: Maven Upload Requests Issue Type: Wish Reporter: Tim Wood Attachments: mavensync "uk.co.flamingpenguin.jewelcli","[EMAIL PROTECTED]:/home/groups/j/je/jewelcli/htdocs/m2repo","rsync_ssh","Tim Wood","[EMAIL PROTECTED]",, http://webwhois.nic.uk/cgi-bin/whois.cgi?query=flamingpenguin.co.uk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-362) Site upload is not compatible with sourceforge.net changes
[ http://jira.codehaus.org/browse/MSITE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153329#action_153329 ] Barrie Treloar commented on MSITE-362: -- Isn't web site deployment to web.sf.net instead? And that is a restricted environment that does not allow shell access. > Site upload is not compatible with sourceforge.net changes > -- > > Key: MSITE-362 > URL: http://jira.codehaus.org/browse/MSITE-362 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-7 >Reporter: Marat Radchenko > > After last changes in sf.net infrastructure there are three ways of > uploading stuff to web area: > # sftp > # scp > # rsync over ssh > I've tried two first options and they both failed. Maven uploads zip > file (wagon.zip) and then tries to unzip it. However unzip > command is not available. > As far as I understand, Maven doesn't support site deployment via rsync. > So technically it is impossible to use Maven for site upload to sf.net > See http://sourceforge.net/community/forum/topic.php?id=3518&page for sf.net > announcement on this changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-362) Site upload is not compatible with sourceforge.net changes
[ http://jira.codehaus.org/browse/MSITE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153332#action_153332 ] johan lindquist commented on MSITE-362: --- I hope I understand your question correctly - the create command will create a shell with the project directory mounted, allowing Wagon to do its job as usual > Site upload is not compatible with sourceforge.net changes > -- > > Key: MSITE-362 > URL: http://jira.codehaus.org/browse/MSITE-362 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-7 >Reporter: Marat Radchenko > > After last changes in sf.net infrastructure there are three ways of > uploading stuff to web area: > # sftp > # scp > # rsync over ssh > I've tried two first options and they both failed. Maven uploads zip > file (wagon.zip) and then tries to unzip it. However unzip > command is not available. > As far as I understand, Maven doesn't support site deployment via rsync. > So technically it is impossible to use Maven for site upload to sf.net > See http://sourceforge.net/community/forum/topic.php?id=3518&page for sf.net > announcement on this changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGES-130) Announce mail : Merging content from the changes file and from jira
[ http://jira.codehaus.org/browse/MCHANGES-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHANGES-130. - Resolution: Fixed fixed in rev [712007|http://svn.apache.org/viewvc?rev=712007&view=rev] SNAPSHOT deployed. > Announce mail : Merging content from the changes file and from jira > --- > > Key: MCHANGES-130 > URL: http://jira.codehaus.org/browse/MCHANGES-130 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature > Components: announcement >Affects Versions: 2.0-beta-2, 2.0-beta-3, 2.0 >Reporter: Olivier Lamy > Fix For: 2.1 > > > I'd like to be able to merge content in the announce email : > - actions from the changes.xml. > - items from jira. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3507) ANSI Color logging for improved output visibility.
[ http://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153356#action_153356 ] Sean Flanigan commented on MNG-3507: The maven-colorlogger project references a chain of el4j parent poms which aren't in the zip. If anyone else wants to try it, I found the immediate parent here: https://el4j.svn.sourceforge.net/svnroot/el4j/trunk/el4j/maven/pom.xml In the end, I just removed the parent reference, told the maven-compiler-plugin to compile for 1.5, and it all worked. An even easier way to try it is to download the el4j binaries from https://sourceforge.net/project/showfiles.php?group_id=147215&package_id=162180&release_id=638658 and use the modified Maven 2.0.9 therein. BTW, if anyone was using an awk hack like this one while waiting for colour logging in Maven - http://blog.bazoud.com/post/2008/10/20/Maven-in-colour-/-Maven-en-couleur - watch out for interactive goals which mess up awk's line buffering... > ANSI Color logging for improved output visibility. > -- > > Key: MNG-3507 > URL: http://jira.codehaus.org/browse/MNG-3507 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur > Fix For: 3.0 > > Attachments: maven-colorlogger.zip > > > Is it possible for Maven to use ANSI color logging? IMO it would make Maven > logs much easier to read and increase the visibility of items that the user > want to see at any given point in time. > I think Andrew Williams did some work under Plexus sandbox to enable color > logging. There also a color logger available in Ant. > http://ant.apache.org/manual/listeners.html#AnsiColorLogger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3507) ANSI Color logging for improved output visibility.
[ http://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Flanigan updated MNG-3507: --- Attachment: pom.xml pom.xml for maven-colorlogger, modified to remove parent reference. > ANSI Color logging for improved output visibility. > -- > > Key: MNG-3507 > URL: http://jira.codehaus.org/browse/MNG-3507 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur > Fix For: 3.0 > > Attachments: maven-colorlogger.zip, pom.xml > > > Is it possible for Maven to use ANSI color logging? IMO it would make Maven > logs much easier to read and increase the visibility of items that the user > want to see at any given point in time. > I think Andrew Williams did some work under Plexus sandbox to enable color > logging. There also a color logger available in Ant. > http://ant.apache.org/manual/listeners.html#AnsiColorLogger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-263) Interactive plugins cannot work in forked executions
[ http://jira.codehaus.org/browse/MRELEASE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153359#action_153359 ] Sean Flanigan commented on MRELEASE-263: Never mind, upon closer investigation, mvn release:prepare doesn't even seem to use StreamPumper, it has its own RawStreamPumper. My problem was caused by a shell alias I had forgotten about which passes mvn output through awk (which buffers by lines). > Interactive plugins cannot work in forked executions > > > Key: MRELEASE-263 > URL: http://jira.codehaus.org/browse/MRELEASE-263 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Daniel Kulp >Priority: Critical > > I was looking into the problems with the GPG plugin when run from the > release plugin and the problems seem to entirely be problems of the > release plugin and Plexus utils. They are showing up in the gpg > plugin, but any plugin that tries to do anything interactively would > most likely run into the same problems. > Issues: > 1) System.in - the release manager doesn't feed anything from System.in > into the forked process. I tried adding System.in to the > CommandLineUtils.executeCommandLine call, but that just causes a hang. > CommandLineUtils will wait until the "in" stream is completely consumed > (returns -1) before returning. With System.in, that never will happen. > 2) Buffered(line style) out - the StreamPumpers use > BufferedInputStream.readLine() to pump from one stream to the other. > This won't work. Anything that does something (like the release plugin > itself) that prompts and then waits for a response on the same line will > appear to just "hang" as the prompt will never make it to the screen. > Basically, those two issues completely prevent us from being able to > un-hard code GPG passphrases from build scripts and such. (unless you > set gpg.useagent to true and use an agent) > In anycase, MGPG-9 is really a release plugin bug although part of it is > due to plexus-utils not providing the support it would need to work > properly.Most likely, we'll need to add a method in CommandLineUtils > that would just take the raw streams (in/out/err) and do straight byte > copy reads without the line buffering. (and once the process > completely, stop pumping the in stream) (of course, that would then > require another plexus-utils release and then the release plugin would > only work with Maven 2.0.6+ with the utils shaded, but that may be > minor) I'll poke around more and see if I can come up with something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2257) Upload OpenXML4J 1.0-beta
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153362#action_153362 ] Yegor Kozlov commented on MAVENUPLOAD-2257: --- Please upload the attached version. It includes a number of critical bugs fixed since 200804. This is the version that will be used by upcoming POI-3.5-FINAL. OpenXML4J is going to be a part of Apache POI. The icla and ccla are already on file. We are just waiting for the software grant to get processed. So, a second -beta or -final will be distributed with groupId="org.apache.poi" and we will be able to push the artifacts ourselves. Thanks, Yegor > Upload OpenXML4J 1.0-beta > - > > Key: MAVENUPLOAD-2257 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2257 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Yegor Kozlov >Assignee: Brett Porter > > Please upload OpenXML4J -beta. We use this library in Apache POI to work with > Open XML files. > Thanks, > Yegor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
