[jira] Commented: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249626#action_249626 ] Lukas Theussl commented on MCHANGES-190: @Christian: If it's unrelated, please attach it to a new issue. @Dennis: as a hack, this is fine, I am just somewhat reluctant as introducing this means that we 'officially' support this feature, which was never the intention. Just making sure you are aware of the implications... ;) HTML in changes.xml stopped working --- Key: MCHANGES-190 URL: http://jira.codehaus.org/browse/MCHANGES-190 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes.xml Affects Versions: 2.3 Environment: Maven version: 2.0.10 Java version: 1.5.0_17 OS name: linux version: 2.6.32-686 arch: i386 Family: unix Reporter: Christian Schulte Priority: Critical Attachments: changes.xml, changes.xml, MCHANGES-190-2.patch, MCHANGES-190.patch, MCHANGES-190.zip The fix for MCHANGES-189 does not seem to be correct. A changes.xml file containing HTML-Tags got rendered correctly using version 2.2. Starting with version 2.3, HTML-Tags will be encoded using HTML entities for the '' and '' characters leading to the actual tags getting shown in the report. See the attached example changes.xml file containing HTML no longer working with version 2.3. -- 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: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249628#action_249628 ] Dennis Lundberg commented on MCHANGES-190: -- Right. Do you think I should add a disclaimer in the parameter documentation about this? Something like this: Putting any kind of markup inside a CDATA section might mess up the Changes Report or other generated documents, such as PDFs, that are based on your changes.xml file. HTML in changes.xml stopped working --- Key: MCHANGES-190 URL: http://jira.codehaus.org/browse/MCHANGES-190 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes.xml Affects Versions: 2.3 Environment: Maven version: 2.0.10 Java version: 1.5.0_17 OS name: linux version: 2.6.32-686 arch: i386 Family: unix Reporter: Christian Schulte Priority: Critical Attachments: changes.xml, changes.xml, MCHANGES-190-2.patch, MCHANGES-190.patch, MCHANGES-190.zip The fix for MCHANGES-189 does not seem to be correct. A changes.xml file containing HTML-Tags got rendered correctly using version 2.2. Starting with version 2.3, HTML-Tags will be encoded using HTML entities for the '' and '' characters leading to the actual tags getting shown in the report. See the attached example changes.xml file containing HTML no longer working with version 2.3. -- 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: (MSHARED-177) Filter files are not filtered with already known filter values
[ http://jira.codehaus.org/browse/MSHARED-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249634#action_249634 ] Daniel Mohni commented on MSHARED-177: -- I will create a unit test for this issue when I am back from holiday, but this will have to wait until end of January when I get back to work... I faced the problem working on a customer site project, using the assembly-plugin version 2.2, we used multiple filter files to create environment specific configurations. Filter File A contains portions of a value of Filter File B, using the key of File B to replace a value in a resource file still contained the key of File A... Filter files are not filtered with already known filter values -- Key: MSHARED-177 URL: http://jira.codehaus.org/browse/MSHARED-177 Project: Maven Shared Components Issue Type: Bug Components: maven-filtering Environment: all Reporter: Daniel Mohni Attachments: PropertyUtils.patch While loading multiple Filter files the current file is filtered but the combined filter properties are not updated. The problem is related that the current filter properties are combined before they are filterd. The copmbined values are not updated after filtering... Attached is a patch that will also update the value in the combinedProperties -- 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-138) release:prepare fails when checking in modified POMs of a multi-modules project
[ http://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249635#action_249635 ] Mark Struberg commented on MRELEASE-138: I heavily use multi module projects and do not face any problems. So let's start with getting info about your environment situation. .) Do you release all your projects at once from the parent module? .) do you have a pom (build pom) in c:\javadev\prj\myproject\ ? .) Do you invoke $ mvn release:prepare on the commandline or run the goal from inside eclipse? .) which version of maven and the release-plugin do u use? .) do your poms contain a correct relativePath in the parent section? release:prepare fails when checking in modified POMs of a multi-modules project --- Key: MRELEASE-138 URL: http://jira.codehaus.org/browse/MRELEASE-138 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Environment: WinXP + Eclipse Reporter: ol Assignee: Emmanuel Venisse Priority: Critical Here is the project structure on the disk : c:\javadev\prj\myproject\module1 c:\javadev\prj\myproject\module2 c:\javadev\prj\myproject\master These 3 folders represent the 3 eclipse projects, each one containing a pom.xml. The master project's pom is the parent of the modules. When I execute the release:prepare goal, Everything works fine (it asks to me the tag name, the next dev version, ...) until I receive this error : [INFO] Checking in modified POMs... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not contained in C:\javadev\prj\myproject\master [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not contained in C:\javadev\prj\myproject\master at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) The problem is that the project structure is the only one that can be used with eclipse. -- 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: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated MRELEASE-128:
---
Fix Version/s: (was: 2.1)
2.2
SCM properties being replaced during release:perform
Key: MRELEASE-128
URL: http://jira.codehaus.org/browse/MRELEASE-128
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
Reporter: Craig Dickson
Assignee: Brett Porter
Priority: Critical
Fix For: 2.2
Attachments: after-release-perform-pom.xml,
after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
original-pom.xml
The scm section of a pom in CVS for a pom archetype project looks like this
prior to executing release:prepare :
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
/scm
Then after executing release:prepare, the pom in CVS looks like this (new
tag tag is only difference):
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
tagR-1_7/tag
/scm
Then after executing release:perform, the pom looks like this in CVS:
scm
connectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/connection
developerConnectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/developerConnection
urlhttp://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom/url
/scm
Notice that the properties that were there for the base URLs for CVS and
ViewCVS have been replaced with literal values.
No other properties in the POM are being replaced
--
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-488) site:deploy shouldn't repace variables from site.xml
[
http://jira.codehaus.org/browse/MSITE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249636#action_249636
]
Krashan Brahmanjara commented on MSITE-488:
---
I don't remember original sequence - probably mvn site deploy.
Problem is in final result, I see pom file and site.xml file in mvn repository
and generated site in another location. site.xml is different than orginal.
site:deploy shouldn't repace variables from site.xml
Key: MSITE-488
URL: http://jira.codehaus.org/browse/MSITE-488
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.1.1
Reporter: Krashan Brahmanjara
Action site:deploy pushes site.xml to external location.
This action works ok but parse original site description and send different
to server.
For example orignal site.xml contain line
item name=${project.name} href=. /
sended file contain line
item name=Core Parent POM href=. /
instead..
I suppose that developers expect that original file will be commited to maven
repository.
--
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: (MCHANGES-200) Problem with login to jira over https and proxy
[
http://jira.codehaus.org/browse/MCHANGES-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249637#action_249637
]
Krashan Brahmanjara commented on MCHANGES-200:
--
I cannot agree with closed status. MCHANGES-175 and MCHANGES-60 are different
cases.
Real problem is in invalid java code with incorrect or deprecated login
algorithm to ssl site.
Attached solution in AbstractJiraDownloader.java is very easy patch and should
be merged with main code.
Problem with login to jira over https and proxy
---
Key: MCHANGES-200
URL: http://jira.codehaus.org/browse/MCHANGES-200
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: jira
Environment: Jdk 1.6_18
Jira Enterprise Edition, Version: 3.13.3-#344)
Reporter: Krashan Brahmanjara
Attachments: AbstractJiraDownloader.java
I cannot get changes log from JIRA but url used by maven is correct.
I mean url
https://jira.prv.pl/secure/IssueNavigator.jspa?view=rsspid=INSCSresolution=1sorter/field=issuetypesorter/order=ASCtempMax=100reset=truedecorator=none
get correct xml in browsers like FF or IE however untrusted certificate info
are displayed..
BTW
Login phase is very long.
Deatils
{noformat}
[DEBUG] Using proxy: 10.4.1.1 at port 3118
[DEBUG] JIRA lives at: https://jira.prv.pl
[DEBUG] Login URL:
https://jira.prv.pl/login.jsp?os_destination=/secure/os_username=TR$%^os_password=*
[DEBUG] Successfully logged in into JIRA.
[DEBUG] download jira issues from url
https://jira.prv.pl/secure/IssueNavigator.jspa?view=rsspid=INSCSresolution=1sorter/field=issuetypesorter/order=ASCtempMax=100reset=truedecorator=none
[INFO] Downloading from JIRA at:
https://jira.prv.pl/secure/IssueNavigator.jspa?view=rsspid=INSCSresolution=1sorter/field=issuetypesorter/order=ASCtempMax=100reset=truedecorator=none
[WARNING] Downloading from JIRA failed. Received: [503]
{noformat}
Pom configuration
{code:xml}
issueManagement
systemjira/system
urlhttps://jira.prv.pl/browse?id=INSCS/url
/issueManagement
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.3/version
reportSets
reportSet
reports
/reports
/reportSet
/reportSets
configuration
onlyCurrentVersiontrue/onlyCurrentVersion
filterresolution=1amp;sorter/field=issuetypeamp;sorter/order=ASC/filter
statusIdsClosed/statusIds
jiraPasswordx/jiraPassword
jiraUserTR/jiraUser
onlyCurrentVersiontrue/onlyCurrentVersion
/configuration
/plugin
{code}
--
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: (MSHARED-177) Filter files are not filtered with already known filter values
[ http://jira.codehaus.org/browse/MSHARED-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHARED-177: - Fix Version/s: maven-filtering-1.0-beta-5 Filter files are not filtered with already known filter values -- Key: MSHARED-177 URL: http://jira.codehaus.org/browse/MSHARED-177 Project: Maven Shared Components Issue Type: Bug Components: maven-filtering Environment: all Reporter: Daniel Mohni Assignee: Olivier Lamy Fix For: maven-filtering-1.0-beta-5 Attachments: PropertyUtils.patch While loading multiple Filter files the current file is filtered but the combined filter properties are not updated. The problem is related that the current filter properties are combined before they are filterd. The copmbined values are not updated after filtering... Attached is a patch that will also update the value in the combinedProperties -- 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: (MSHARED-177) Filter files are not filtered with already known filter values
[ http://jira.codehaus.org/browse/MSHARED-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249639#action_249639 ] Olivier Lamy commented on MSHARED-177: -- ok sounds reasonnable use case. Don't miss to create an issue in MASSEMBLY too for upgrading the lib version. Thanks Filter files are not filtered with already known filter values -- Key: MSHARED-177 URL: http://jira.codehaus.org/browse/MSHARED-177 Project: Maven Shared Components Issue Type: Bug Components: maven-filtering Environment: all Reporter: Daniel Mohni Fix For: maven-filtering-1.0-beta-5 Attachments: PropertyUtils.patch While loading multiple Filter files the current file is filtered but the combined filter properties are not updated. The problem is related that the current filter properties are combined before they are filterd. The copmbined values are not updated after filtering... Attached is a patch that will also update the value in the combinedProperties -- 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: (MPLUGIN-165) Upgrading to Maven Site 2.1 messes up plugin site generation
[ http://jira.codehaus.org/browse/MPLUGIN-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPLUGIN-165: --- Attachment: MPLUGIN-165.patch IE-MPLUGIN-165.bmp FF-MPLUGIN-165.bmp Attached two examples of how plugin detail pages were rendered (IE + FF). Also a patch which removes the align=left. This will place the tables back under each other. Upgrading to Maven Site 2.1 messes up plugin site generation Key: MPLUGIN-165 URL: http://jira.codehaus.org/browse/MPLUGIN-165 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: API Affects Versions: 2.5.1 Reporter: Mike Youngstrom Attachments: deployable-mojo.html, FF-MPLUGIN-165.bmp, IE-MPLUGIN-165.bmp, maven.png, MPLUGIN-165.patch, plugin-report.jpg If I upgrade my site plugin to 2.1 then my plugin sites get all messed up. Two problems I noted in particular include: 1. The Report links aren't rendered at all on the left side of the screen. 2. The plugin goal detail page layout is messed up. headers don't align with backgrounds for headers. -- 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: (MCHANGES-200) Problem with login to jira over https and proxy
[
http://jira.codehaus.org/browse/MCHANGES-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249648#action_249648
]
Dennis Lundberg commented on MCHANGES-200:
--
First off, there is no patch attached to this issue, only a Java source file.
You need to make it a proper patch file for us to be able to see what changes
you are proposing and later to be able to apply those changes to the source
repository.
You also need to describe the problem better, so that we can understand it.
Problem with login to jira over https and proxy
---
Key: MCHANGES-200
URL: http://jira.codehaus.org/browse/MCHANGES-200
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: jira
Environment: Jdk 1.6_18
Jira Enterprise Edition, Version: 3.13.3-#344)
Reporter: Krashan Brahmanjara
Attachments: AbstractJiraDownloader.java
I cannot get changes log from JIRA but url used by maven is correct.
I mean url
https://jira.prv.pl/secure/IssueNavigator.jspa?view=rsspid=INSCSresolution=1sorter/field=issuetypesorter/order=ASCtempMax=100reset=truedecorator=none
get correct xml in browsers like FF or IE however untrusted certificate info
are displayed..
BTW
Login phase is very long.
Deatils
{noformat}
[DEBUG] Using proxy: 10.4.1.1 at port 3118
[DEBUG] JIRA lives at: https://jira.prv.pl
[DEBUG] Login URL:
https://jira.prv.pl/login.jsp?os_destination=/secure/os_username=TR$%^os_password=*
[DEBUG] Successfully logged in into JIRA.
[DEBUG] download jira issues from url
https://jira.prv.pl/secure/IssueNavigator.jspa?view=rsspid=INSCSresolution=1sorter/field=issuetypesorter/order=ASCtempMax=100reset=truedecorator=none
[INFO] Downloading from JIRA at:
https://jira.prv.pl/secure/IssueNavigator.jspa?view=rsspid=INSCSresolution=1sorter/field=issuetypesorter/order=ASCtempMax=100reset=truedecorator=none
[WARNING] Downloading from JIRA failed. Received: [503]
{noformat}
Pom configuration
{code:xml}
issueManagement
systemjira/system
urlhttps://jira.prv.pl/browse?id=INSCS/url
/issueManagement
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.3/version
reportSets
reportSet
reports
/reports
/reportSet
/reportSets
configuration
onlyCurrentVersiontrue/onlyCurrentVersion
filterresolution=1amp;sorter/field=issuetypeamp;sorter/order=ASC/filter
statusIdsClosed/statusIds
jiraPasswordx/jiraPassword
jiraUserTR/jiraUser
onlyCurrentVersiontrue/onlyCurrentVersion
/configuration
/plugin
{code}
--
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: (SUREFIRE-498) POJO tests have only partially implemented fixture support
[ http://jira.codehaus.org/browse/SUREFIRE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-498: Component/s: JUnit 3.x support POJO tests have only partially implemented fixture support -- Key: SUREFIRE-498 URL: http://jira.codehaus.org/browse/SUREFIRE-498 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Reporter: Christian Gruber Attachments: fixture.diff, fixture.diff The current support for POJO executes each test method, and before and after each test method there is a method on PojoTestSet executed for fixture setup and teardown. In the executeMethod() method, there are try/catch blocks around a delegated method (setUpFixture() and tearDownFixture()) but the implementation of those two methods is empty. So under no circumstances is setup or teardown able to occur, except with in each method. I've attached a patch which looks up the setUp() and tearDown() public methods on the pojo test class, and if such exist, executes them appropriately. All the try/catch logic is already there - it just needed the last step of deciding what these methods were going to be called, and calling them. -- 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: (SUREFIRE-514) Provide a way to skip a project's tests if nothing has changed
[ http://jira.codehaus.org/browse/SUREFIRE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-514: Component/s: Maven Surefire Plugin Provide a way to skip a project's tests if nothing has changed -- Key: SUREFIRE-514 URL: http://jira.codehaus.org/browse/SUREFIRE-514 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Reporter: Dan Fabulich Surefire should have an incremental mode, perhaps enabled by default. We should check the timestamps of every element of the classpath (and every class in any classpath folder) and touch a file in target with that timestamp. If none of those files have been updated, skip tests for the current project. It definitely needs to be possible to turn this feature off, though, because sometimes you need to re-run tests based on external resources not on the classpath: deployed web servers, database schema changes, etc. -- 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: (SUREFIRE-528) Splitting tests names in two categories : success and failure
[ http://jira.codehaus.org/browse/SUREFIRE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-528: Component/s: Maven Surefire Plugin Splitting tests names in two categories : success and failure - Key: SUREFIRE-528 URL: http://jira.codehaus.org/browse/SUREFIRE-528 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.0 (2.2 plugin) Reporter: Emmanuel Lécharny We have to check all the *.txt files to find the ones which contain some errors. The fact that failed tests are listed before does not help a lot when you have hundred of tests run with sometime lot of logs. I would rather propose that we either create two sub-directories (failure/success) or that we postfix tests. A good example : ... Tests run: 197, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports for the individual test results. ... Would be better to have : Please refer to /home/elecharny/apacheds/mina/trunk/core/target/surefire-reports/failure for the individual test failures. -- 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: (SUREFIRE-533) maven test java timezone
[
http://jira.codehaus.org/browse/SUREFIRE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-533:
Component/s: process forking
maven test java timezone
Key: SUREFIRE-533
URL: http://jira.codehaus.org/browse/SUREFIRE-533
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Environment: Windows XP Pro 2002
Reporter: Sotirios Maroudas
Attachments: pom.xml
Hello maven team,
I try to execute a junit test through maven. the method is:
@Test
public void loadData() {
EntityTransaction tx = null;
try {
tx = em.getTransaction();
tx.begin();
Query q1 = em.createQuery(update CnCode c set
c.activationDate=current_timestamp where c.codeType=15071010);
q1.executeUpdate();
tx.commit();
Query q = em.createQuery(select c from CnCode c where
c.codeType=15071010);
List l = q.getResultList();
if (l.size() 0) {
CnCode c = (CnCode) l.get(0);
SimpleDateFormat df=new SimpleDateFormat(dd/MM/
hh:mm:ss);
System.out.println(df.format(c.getActivationDate().getTime()));
}
System.out.println(TimeZone.getDefault().getDSTSavings());
System.out.println(TimeZone.getDefault().getRawOffset());
} catch (RuntimeException e) {
if (tx != null tx.isActive()) {
tx.rollback();
}
throw e; // or display error message
}
when i execute this method through maven the current_timestamp query
parameter saves the current_timestamp 2 hours before my localtime in ORACLE
Database. The Database is on the same machine with the executing code and its
timezone is GMT+2.
I then created an eclipse project and executed the same junit and the date
saved correctly in my local time. Is something happening with surefire
plugin? i attach also the pom.xml
thanks
Sotiris Maroudas
--
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: (SUREFIRE-534) Xpp3Dom gets in the way of org.omg.CORBA.INITIALIZE
[ http://jira.codehaus.org/browse/SUREFIRE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-534: Component/s: classloading Xpp3Dom gets in the way of org.omg.CORBA.INITIALIZE --- Key: SUREFIRE-534 URL: http://jira.codehaus.org/browse/SUREFIRE-534 Project: Maven Surefire Issue Type: Bug Components: classloading Reporter: Emilian Bold I have a unit test which creates an InitialContext and connects to a Glassfish application. I'm using sunfire 2.1.3 (in order to -disableassertions). While creating the InitialContext, I get exception at the end of the post. Basically I have appserver-rt in the dependency list (in my local repository). This jar contains the com/sun/corba/ee/impl/orb/ORBImpl.class. maven-surefire-plugin is also configured this way in the build: version2.1.3/version configuration forkModepertest/forkMode !-- also always ? -- argLine-da/argLine !-- force the appserver ORB in front of the default one ?-- childDelegationtrue/childDelegation Note my test with childDelegation which seems to do nothing in particular. org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation com.sun.corba.ee.impl.orb.ORBImpl vmcid: 0x0 minor code: 0 completed: No at org.omg.CORBA.ORB.create_impl(ORB.java:297) at org.omg.CORBA.ORB.init(ORB.java:336) at com.sun.enterprise.util.ORBManager.initORB(ORBManager.java:506) at com.sun.enterprise.util.ORBManager.getORB(ORBManager.java:264) at com.sun.enterprise.naming.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:141) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.init(InitialContext.java:175) at com.example.xxx.xxx.TestMe.connect(TestParent.java:41) at com.example.xxx.TestTransactions.setUp(TestTransactions.java:33) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:126) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785) Caused by: java.lang.VerifyError: (class: com/sun/corba/ee/impl/orb/ORBImpl, method: create_context_list signature: ()Lorg/omg/CORBA/ContextList;) Incompatible argument to function at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.omg.CORBA.ORB.create_impl(ORB.java:295) ... 32 more -- 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: (SUREFIRE-561) after running test, when tests fail, it's hard to the find the failure reason
[ http://jira.codehaus.org/browse/SUREFIRE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-561: Component/s: Maven Surefire Plugin after running test, when tests fail, it's hard to the find the failure reason - Key: SUREFIRE-561 URL: http://jira.codehaus.org/browse/SUREFIRE-561 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.4.3 Reporter: Szczepan Faber Maven surefire has been here for a while but still I'm missing this feature. When my tests fail, I'd like to know exact failure reason. 1. Surefire summary does not show the stack trace / line number / assertion. Browsing results files in target dir is frustrating time consuming. 2. It is impossible to use surefire-report plugin in fully automated way. If I plug report-only goal to phase test, this goal is not executed when phase test fails Current workaround in my project is that every maven submodule has a handy batch file with 'mvn surefire-report:report-only'. One of the ways of implementing it is adding stacktrace/assertion information in test summary. What do you guys think about this idea? -- 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: (SUREFIRE-611) surefire exit code should explicitly distinguish between crashed and failed unit test(s)
[ http://jira.codehaus.org/browse/SUREFIRE-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-611: Component/s: Maven Surefire Plugin surefire exit code should explicitly distinguish between crashed and failed unit test(s) Key: SUREFIRE-611 URL: http://jira.codehaus.org/browse/SUREFIRE-611 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Tycho Lamerigts Attachments: tc-junit-crash.tar.gz - If a unit test crashes, surefire skips all remaining tests, prints a message [ERROR] There are test failures. ... to the console, and does NOT print a test summary report. - If one or more unit tests fail, maven completes remaining tests, prints a message [ERROR] There are test failures. ... to the console, and DOES print a test summary report. The only distinction between crash and fail is the presence (or absence) of a summary report. This is a problem for some tools (like TeamCity), because they typically don't pick up on the fact that many testcases were not run at all in case of a crashed unit test. Instead in case of a crashed test they simply report, for example, 100 tests succeeded, 0 failed. They do not report 50 tests skipped due to a crash after test #100, and it is quite hard for those tools to recognize this situation. If surefire would report a crash more explicitly, other tools can act accordingly. I have attached a small maven project to reproduce the problem. By commenting and uncommenting the marked line in file ATest.java, you can reproduce both fail and crash scenarios. In the crash scenario, Maven will correctly report a failed build (unless you use the -Dmaven.test.failure.ignore flag, in which case it even won't do that), but it fails to indicate there was a crash which caused tests (in this case 3) to be skipped. -- 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: (SUREFIRE-659) Maven PDF plugin:showSuccess=false creates empty table causing error
[ http://jira.codehaus.org/browse/SUREFIRE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-659: Component/s: Maven Surefire Report Plugin Maven PDF plugin:showSuccess=false creates empty table causing error Key: SUREFIRE-659 URL: http://jira.codehaus.org/browse/SUREFIRE-659 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Affects Versions: 2.6 Environment: maven 2.2.1, surefire 2.6, maven-pdf-plugin Reporter: Darren Hartford The problem is that for showSuccess=false an empty table is written but fo expects some tableRows even if they are empty. Cheers, -Lukas Darren Hartford wrote: Hey all, Not sure where to put this issue, but using the surefire-report(2.6) with showSuccess=false, with the maven-pdf-plugin (1.1) breaks. This is using a multi-module/aggregate report approach, maven 2.2.1. With showSuccess=true, everything works fine. Basic intent is to, on a release, create an aggregate/summary PDF of the release, but some of the items. such as the surefire-report, are too verbose. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.6/version configuration !-- although would prefer this, causing fo:table-body generation issues -- showSuccessfalse/showSuccess aggregatetrue/aggregate /configuration /plugin Error === [ERROR] BUILD ERROR [INFO] [INFO] Error during document generation: Error creating PDF from /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: org.apache.fop.fo.ValidationException: file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): fo:table-body is missing child elements. Required Content Model: marker* (table-row+|table-cell+) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during document generation: Error creating PDF from /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: org.apache.fop.fo.ValidationException: file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): fo:table-body is missing child elements. Required Content Model: marker* (table-row+|table-cell+) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during document generation: Error creating PDF from /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: org.apache.fop.fo.ValidationException: file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): fo:table-body is missing child elements. Required Content Model: marker* (table-row+|table-cell+) at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:574) at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) ... 16 more Caused by:
[jira] Updated: (SUREFIRE-319) skiptrue/skip cannot be overridden using mvn -Dmaven.test.skip=false test
[ http://jira.codehaus.org/browse/SUREFIRE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-319: Component/s: Maven Surefire Plugin skiptrue/skip cannot be overridden using mvn -Dmaven.test.skip=false test - Key: SUREFIRE-319 URL: http://jira.codehaus.org/browse/SUREFIRE-319 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Environment: java version 1.5.0_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) Reporter: Graham Leggett Fix For: Backlog If the pom file is configured to skip tests using skiptrue/skip, and an attempt is made to override this on the command line using mvn -Dmaven.test.skip=false test, the attempt does not work (the test is still skipped). In theory, the command line flag should override the pom setting. -- 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: (SUREFIRE-85) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException
[ http://jira.codehaus.org/browse/SUREFIRE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-85: --- Component/s: classloading java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException - Key: SUREFIRE-85 URL: http://jira.codehaus.org/browse/SUREFIRE-85 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin) Environment: Windows XP / Sun JDK 1.5.0_06 Reporter: David J. M. Karlsen Fix For: Backlog Attachments: log.txt java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException Exception in thread main is thrown during execution of the maven-surefire-plugin -- 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: (SUREFIRE-577) running only some method of a unit class (with -Dtest.method=myMethod)
[ http://jira.codehaus.org/browse/SUREFIRE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-577: Component/s: Maven Surefire Plugin running only some method of a unit class (with -Dtest.method=myMethod) -- Key: SUREFIRE-577 URL: http://jira.codehaus.org/browse/SUREFIRE-577 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Reporter: Olivier Lamy I definitely don't know if it's possible with junit. But it's an idea, I have now :-). -- 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: (SUREFIRE-645) Meaningful message when test has no runnable methods
[ http://jira.codehaus.org/browse/SUREFIRE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-645: Component/s: Maven Surefire Plugin Meaningful message when test has no runnable methods Key: SUREFIRE-645 URL: http://jira.codehaus.org/browse/SUREFIRE-645 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: Backlog Reporter: Stefan Birkner Fix For: 2.7.2 Attachments: extendedErrorMessage.patch If there's a test class without any runnable methods, the test fails with an error. The output to the command line is: Tests in error: initializationError(EmptyTest) The supplied patch extends this message for all errors. For the error at hand, the output to the command line will be: Tests in error: initializationError(EmptyTest): No runnable methods -- 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: (SUREFIRE-531) Extend -Dtest to let test *methods* to be specified, rather than just test classes.
[ http://jira.codehaus.org/browse/SUREFIRE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-531: Component/s: Maven Surefire Plugin Extend -Dtest to let test *methods* to be specified, rather than just test classes. --- Key: SUREFIRE-531 URL: http://jira.codehaus.org/browse/SUREFIRE-531 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Haikal Saadh Priority: Minor It would be nice if -Dtest could be used to run a certain test method. For example, mvn surefire:surefire -Dtest=TestFoo/testMyFailingTest -- 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: (SUREFIRE-131) Excluding tests with command line pattern
[
http://jira.codehaus.org/browse/SUREFIRE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-131:
Component/s: Maven Surefire Plugin
Excluding tests with command line pattern
-
Key: SUREFIRE-131
URL: http://jira.codehaus.org/browse/SUREFIRE-131
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Plugin
Affects Versions: 2.0 (2.2 plugin)
Environment: All environments running JUnit tests
Reporter: Johannes Carlén
Priority: Minor
Fix For: Backlog
I'd like to be able to exclude certain tests from being run. An example of
this could be a scenario where I'd like just the unit tests and not the
integration tests to run. In our case, we name all integration test with the
postfix IntTest instead of just Test.
This is now possible through configuring the plugin in the pom, however it is
not possible to decide at the command line if I just like to run some tests
and not all.
Example of use with this implementation would be:
mvn -Dexclude=*IntTest test
which would run all tests - excluding those that ends with IntTest
The amount of code needed for implementation is minimal. In
SurefirePlugin.java:
Just add a property - something like:
/**
* Specify this parameter to exclude test by their name. It follows
* the same conventions as the codetest/code parameter.
*
* @parameter expression=${exclude}
*
*/
private String exclude;
Add this code at line 527
if ( this.exclude != null )
{
String exclude = **/ + this.exclude + .java;
excludes.add(exclude);
getLog().debug( Excluding test with pattern : + exclude
);
}
...and that's all.
--
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: (SUREFIRE-625) Testclass which fails during launch claims to have no tests
[
http://jira.codehaus.org/browse/SUREFIRE-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-625:
Component/s: Junit 4.x support
Testclass which fails during launch claims to have no tests
---
Key: SUREFIRE-625
URL: http://jira.codehaus.org/browse/SUREFIRE-625
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.5
Environment: Maven version: 2.0.10 (surefire 2.5)
Java version: 1.6.0_15
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Karen Lease
Priority: Minor
Attachments: surefire_junit4.8.1_issue.zip
I have a test which fails during launch due to this exception:
bq.java.lang.SecurityException: class
;com.spx.messageservice.MessageServiceException's signer information does
not match signer information of other classes in the same package
This happened because the class under test depends on some other classes in
the same package in a signed jar.
The problem is that using our normal maven environment, this error is not
shown at all. Instead the surefire report for this class contained the
results from the previous test in the module!
If the test is run by itself with mvn -Dtest=TestClass, then maven says there
are no tests run and no errors!
If I use junit 4.8.1 in my pom file, I get this output on the console and in
the surefire .txt report:
bq.Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
The XML surefire report is not produced at all.
If I use junit 4.6 in my pom file, I get this output:
{quote}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.047
sec FAILURE!
initializationError(com.spx.messageservice.BusinessEventRegistrarTest) Time
elapsed: 0 sec ERROR!
java.lang.SecurityException: class
com.spx.messageservice.MessageServiceException's signer information does
not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
...
{quote}
Both the .txt .xml version of the surefire reports are produced.
After some experiments, I found that this happens for any junit version 4.6.
If I run the test class with junit from the command line, both the 4.6
4.8.1 produce a stack trace showing the exception during launch.
--
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: (SUREFIRE-595) Add surefire:force-test mojo to postpone tests
[ http://jira.codehaus.org/browse/SUREFIRE-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-595: Component/s: Maven Surefire Plugin Add surefire:force-test mojo to postpone tests -- Key: SUREFIRE-595 URL: http://jira.codehaus.org/browse/SUREFIRE-595 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Reporter: Dan Fabulich The standard lifecycle does all testing before installing artifacts in the local repository. When running our experimental concurrent Maven, we find that doing compiling/packaging/installing before testing can promote better concurrency. It would be helpful to have a surefire:force-test mojo, which simply extends the standard mojo but ignores the -DskipTests and -Dmaven.test.skip properties. That way, you could run the build like this: mvn install -DskipTests surefire:force-test The tests would be skipped during the install lifecycle, and then run separately at the end of the build. -- 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: (SUREFIRE-424) A class providing JUnit's suite() method need not itself implement Test. But Surefire ignores the suite if it doesn't.
[
http://jira.codehaus.org/browse/SUREFIRE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-424:
Component/s: JUnit 3.x support
A class providing JUnit's suite() method need not itself implement Test. But
Surefire ignores the suite if it doesn't.
--
Key: SUREFIRE-424
URL: http://jira.codehaus.org/browse/SUREFIRE-424
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 3.x support
Affects Versions: 2.4
Reporter: Andreas Krüger
Priority: Minor
Fix For: Backlog
Often, there is one test method per test case. JUnit allows a test class to
be more flexible: It may generate a test suite at test run time, which may
contain any number of tests.
JUnit has traditionally required
* a {{public static suite()}} method
* returning {{junit.framework.Test}} (or some type, such as {{TestSuite}},
that can be cast to {{Test}} ).
In addition to these JUnit requirements, Surefire imposes one more
requirement:
* the class that contains the {{suite()}} method needs to itself implement
{{junit.framework.Test}} .
If that additional requirement is not met, the {{suite()}} method is not
called, but silently ignored.
Surefire should not impose this additional requirement, but call any
{{suite()}} method that returns something that can be cast to
{{junit.framework.Test}} , in any test class.
--
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: (SUREFIRE-667) Setting up maven resources when testing in addition to testResources
[
http://jira.codehaus.org/browse/SUREFIRE-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-667:
Component/s: Maven Surefire Plugin
Setting up maven resources when testing in addition to testResources
Key: SUREFIRE-667
URL: http://jira.codehaus.org/browse/SUREFIRE-667
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: vychtrle
Hey,
I think that developers would need resource goal of resource plugin to be set
up differently for
test phase, than for build phase. When testing one needs to exclude stuff
from src/main/resources. It seems it can't be done, testResources goal
is irrelevant for this because it can't operate on src/main/* and resource
goal can have only one
setting in pom definition, that takes effect in both test and build
phase...
For example, I'd need following settings to look differently (some
excludes) in testing phase :
resources
resource
directory${project.basedir}/src/main/java/directory
includes
include**/*.java/include
includeservice.properties/include
/includes
/resource
resource
directory${project.basedir}/src/main/resources/directory
includes
include**/*.xml/include
include**/*.properties/include
/includes
/resource
/resources
The ideal behavior would be if one could define src/main/* in
testResources but it unfortunately can't be done right now
--
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
