[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335742#comment-335742 ] Gili commented on MNG-1388: --- Happy birthday! 8 years old and counting. > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-158) Symbol name should be displayed during compiler error using Java 7
[
https://jira.codehaus.org/browse/MCOMPILER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335747#comment-335747
]
Leonid Ilyevsky commented on MCOMPILER-158:
---
I see this problem is fixed in the plugin version 3.1.
> Symbol name should be displayed during compiler error using Java 7
> --
>
> Key: MCOMPILER-158
> URL: https://jira.codehaus.org/browse/MCOMPILER-158
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Raghuram
>
> Got to install Java 7. Tried it out on some of our source code which uses
> maven. Worked fine till there was a compilation error.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
> (default-compile) on project my-app: Compilation failure
> [ERROR] \work\my-app\src\main\java\com\mycompany\app\App.java:[11,45] error:
> cannot find symbol
> [ERROR] -> [Help 1]
> {code}
> I am ok with the error, but which _symbol_ does it fail to find? Tried the
> same thing with Java 6.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
> (default-compile) on project my-app: Compilation failure
> [ERROR] \work\my-app\src\main\java\com\mycompany\app\App.java:[11,45] cannot
> find symbol
> [ERROR] symbol : variable Dummy
> [ERROR] location: class com.mycompany.app.App
> [ERROR] -> [Help 1]
> {code}
> I can clearly see which variable is not found. So what has changed?
> Tried *javac* on the class. Output with java 7.
> {code}
> javac App.java
> App.java:11: error: cannot find symbol
> System.out.println( "Hello World!" + Dummy);
> ^
> symbol: variable Dummy
> location: class App
> 1 error
> {code}
> Output with java 6.
> {code}
> javac App.java
> App.java:11: cannot find symbol
> symbol : variable Dummy
> location: class com.mycompany.app.App
> System.out.println( "Hello World!" + Dummy);
> ^
> 1 error
> {code}
> We can see a couple of differences with Java 7 compiler compared to Java 6.
> * Location does not show complete package, just the class
> * Symbol and location now come after the line which has the error, instead of
> before.
> * An additional "error" word comes before the error message
> Essentially there is a change in compiler output in case of errors, which I
> guess needs a corresponding maven compiler change.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1028) Unable to run single test (junit)
[
https://jira.codehaus.org/browse/SUREFIRE-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335726#comment-335726
]
Andrew Gaul edited comment on SUREFIRE-1028 at 11/15/13 11:27 AM:
--
I can trigger these symptoms when setting parallel=classes, similar to
http://jira.codehaus.org/browse/SUREFIRE-827#comment-290928
{noformat}
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=none
-Dsurefire.version=2.15
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=none
-Dsurefire.version=2.16
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=classes
-DthreadCount=1 -Dsurefire.version=2.15
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=classes
-DthreadCount=1 -Dsurefire.version=2.16
main:
[debug] execute contextualize
[debug] execute contextualize
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project commons-lang3: No tests were executed! (Set
-DfailIfNoTests=false to ignore this error.) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
{noformat}
was (Author: gaul):
I can trigger these symptoms when setting parallel=classes, similar to
http://jira.codehaus.org/browse/SUREFIRE-827?focusedCommentId=290928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-290928
{noformat}
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=none
-Dsurefire.version=2.15
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=none
-Dsurefire.version=2.16
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=classes
-DthreadCount=1 -Dsurefire.version=2.15
...
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
$ mvn test -Dtest=ImmutablePairTest#testBasic -Dparallel=classes
-DthreadCount=1 -Dsurefire.version=2.16
main:
[debug] execute contextualize
[debug] execute contextualize
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project commons-lang3: No tests were executed! (Set
-DfailIfNoTests=false to ignore this error.) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
{noformat}
> Unable to run single test (junit)
> -
>
> Key: SUREFIRE-1028
> URL: https://jira.codehaus.org/browse/SUREFIRE-1028
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Diwaker Gupta
>Priority: Critical
> Fix For: 2.17
>
>
> This is a regression from 2.15. It also looks like Surefire keeps regressing
> on this feature (e.g. see SUREFIRE-827) -- are there no unit or integration
> tests to prevent such regressions?
> With Surefire 2.15
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> ...
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> With Surefire 2.16
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5176) Print build times in an ISO 8601-style manner
[
https://jira.codehaus.org/browse/MNG-5176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5176:
Attachment: MNG-5176.patch
Updated patch. The last ones were buggy and failed the tests. Patch applied
against Maven 3.1.1.
> Print build times in an ISO 8601-style manner
> -
>
> Key: MNG-5176
> URL: https://jira.codehaus.org/browse/MNG-5176
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.2.1, 3.0.3
> Environment: Maven 2.2.1 and 3.0.3
>Reporter: Michael Osipov
> Attachments: MNG-5176.patch
>
>
> The current output of build times is hard to read and does not follow any
> standard. I have patched branch 2.2.x and 3 trunk to follow ISO 8601-style
> date/time formats.
> My patches need less code compared to the current solution. I had the
> following ideas in mind:
> 1. Display times in the same proportional format.
> 2. hour display is fixed to max 24 h as in ISO defined.
> 3. Days are directly integrated, not brain math necessary anymore. Though
> this should be a rare case.
> 3. remove the smallest component if a bigger one is added.
> 4. Easier to parse, predictable output.
> More over, I have changed the finish and total time to ISO too. I did not
> touch the finish time in Maven 2.2.x because it is alphanumeric. I'd rather
> prefer that as total time but this is maybe a matter of taste and harder to
> parse.
> This is a real output:
> {noformat}
> [INFO] Building tar :
> /.amd_mnt/blnn728x/home/osipovmi/Projekte/maven-3/apache-maven/target/apache-maven-3.0.4-SNAPSHOT-bin.tar.gz
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Maven .. SUCCESS [00:04.732]
> [INFO] Maven Model ... SUCCESS [00:06.332]
> [INFO] Maven Artifact SUCCESS [00:02.551]
> [INFO] Maven Plugin API .. SUCCESS [00:03.855]
> [INFO] Maven Model Builder ... SUCCESS [00:06.708]
> [INFO] Maven Settings SUCCESS [00:02.292]
> [INFO] Maven Settings Builder SUCCESS [00:02.138]
> [INFO] Maven Repository Metadata Model ... SUCCESS [00:01.931]
> [INFO] Maven Aether Provider . SUCCESS [00:02.442]
> [INFO] Maven Core SUCCESS [00:28.509]
> [INFO] Maven Compat .. SUCCESS [00:20.260]
> [INFO] Maven Embedder SUCCESS [00:03.478]
> [INFO] Maven Distribution SUCCESS [00:26.715]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 01:52.618
> [INFO] Finished at: 2011-09-19 14:25:24
> [INFO] Final Memory: 36M/144M
> [INFO]
>
> {noformat}
> A crafted output with all formats would look like this:
> {noformat}
> [INFO] Building tar :
> /.amd_mnt/blnn728x/home/osipovmi/Projekte/maven-3/apache-maven/target/apache-maven-3.0.4-SNAPSHOT-bin.tar.gz
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Maven .. SUCCESS [1 d 03:04]
> [INFO] Maven Model ... SUCCESS [01:00:06]
> [INFO] Maven Artifact SUCCESS [00:02.551]
> [INFO] Maven Plugin API .. SUCCESS [00:03.855]
> [INFO] Maven Model Builder ... SUCCESS [00:06.708]
> [INFO] Maven Settings SUCCESS [00:02.292]
> [INFO] Maven Settings Builder SUCCESS [00:02.138]
> [INFO] Maven Repository Metadata Model ... SUCCESS [00:01.931]
> [INFO] Maven Aether Provider . SUCCESS [00:02.442]
> [INFO] Maven Core SUCCESS [00:28.509]
> [INFO] Maven Compat .. SUCCESS [00:20.260]
> [INFO] Maven Embedder SUCCESS [00:03.478]
> [INFO] Maven Distribution SUCCESS [00:26.715]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1 d 03:05
> [INFO] Finished at:
[jira] (MEAR-173) EJB Modules defined in a parent POM are ignored from the child POM
[
https://jira.codehaus.org/browse/MEAR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MEAR-173:
Description:
When a parent pom (pom packaging) defines ejbModules in the configuration
section, these ejbModules are ignored in a child module (ear packaging)
The others modules (jar, war) are correctly taken into account.
Here is the pom structure:
{noformat}
parent-ear (with ejbModules defined, common to all child modules)
| ear-1 (with specific ejbModules)
| ear-2 (with other specific ejbModules)
{noformat}
was:
When a parent pom (pom packaging) defines ejbModules in the configuration
section, these ejbModules are ignored in a child module (ear packaging)
The others modules (jar, war) are correctly taken into account.
Here is the pom structure:
parent-ear (with ejbModules defined, common to all child modules)
| ear-1 (with specific ejbModules)
| ear-2 (with other specific ejbModules)
> EJB Modules defined in a parent POM are ignored from the child POM
> --
>
> Key: MEAR-173
> URL: https://jira.codehaus.org/browse/MEAR-173
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: Windows XP 64bits
>Reporter: Benoît Berthonneau
>Priority: Critical
>
> When a parent pom (pom packaging) defines ejbModules in the configuration
> section, these ejbModules are ignored in a child module (ear packaging)
> The others modules (jar, war) are correctly taken into account.
> Here is the pom structure:
> {noformat}
> parent-ear (with ejbModules defined, common to all child modules)
> | ear-1 (with specific ejbModules)
> | ear-2 (with other specific ejbModules)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335762#comment-335762 ] Damian Bradicich commented on MNG-1388: --- yes, happy birthday my old friend ;) > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1042) Provide way of running tests so that stack trace isn't dumped onto console
Data Nucleus created SUREFIRE-1042: -- Summary: Provide way of running tests so that stack trace isn't dumped onto console Key: SUREFIRE-1042 URL: https://jira.codehaus.org/browse/SUREFIRE-1042 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.16 Environment: Maven 3.x, Linux Reporter: Data Nucleus We never used to get stack traces from any failed tests (asserts) being dumped onto the console. "Upgrading" to 2.16 means that they now get dumped onto the console (UGLY IMHO). Can we at least have the option of the previous output behaviour? If there already is a way of achieving this, please advise, I couldn't find anything that had an effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1042) Provide way of running tests so that stack trace isn't dumped onto console
[ https://jira.codehaus.org/browse/SUREFIRE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Data Nucleus updated SUREFIRE-1042: --- Description: We never used to get stack traces from any failed tests (asserts) being dumped onto the console. "Upgrading" to 2.16 means that they now get dumped onto the console (UGLY IMHO). Can we at least have the option of the previous output behaviour (2.10 for example)? If there already is a way of achieving this, please advise, I couldn't find anything that had an effect. (was: We never used to get stack traces from any failed tests (asserts) being dumped onto the console. "Upgrading" to 2.16 means that they now get dumped onto the console (UGLY IMHO). Can we at least have the option of the previous output behaviour? If there already is a way of achieving this, please advise, I couldn't find anything that had an effect.) Affects Version/s: 2.13 2.14 2.15 > Provide way of running tests so that stack trace isn't dumped onto console > -- > > Key: SUREFIRE-1042 > URL: https://jira.codehaus.org/browse/SUREFIRE-1042 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.13, 2.14, 2.15, 2.16 > Environment: Maven 3.x, Linux >Reporter: Data Nucleus > > We never used to get stack traces from any failed tests (asserts) being > dumped onto the console. "Upgrading" to 2.16 means that they now get dumped > onto the console (UGLY IMHO). Can we at least have the option of the previous > output behaviour (2.10 for example)? If there already is a way of achieving > this, please advise, I couldn't find anything that had an effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
