[jira] (SUREFIRE-955) Surefire top-level website has obscure navigation (at least in Chrome)
Benson Margulies created SUREFIRE-955: - Summary: Surefire top-level website has obscure navigation (at least in Chrome) Key: SUREFIRE-955 URL: https://jira.codehaus.org/browse/SUREFIRE-955 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 2.13 Reporter: Benson Margulies Browse to http://maven.apache.org/surefire And you will find yourself at an 'about' page with the only navigation being top-level dropdown menus. Maybe this JIRA needs to be redirected to a skin, but it took me several minutes to see how I could get from this page to anywhere else, and I bet others will have the same problem. It also does not comply with Apache trademark guidelines; there are no trademark notices for Maven or Surefire. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318224#comment-318224
]
Benson Margulies commented on SUREFIRE-954:
---
{noformat}
[benson] rlp/source/java-benchmark [java-benchmark:] % java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-413-12A269)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-413, mixed mode)
{noformat}
> Hard-to-believe abstract method error
> -
>
> Key: SUREFIRE-954
> URL: https://jira.codehaus.org/browse/SUREFIRE-954
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Benson Margulies
>
> I have a set of junit test that I am running with Surefire 2.13 with forkMode
> always. Two classes die with the following hard-to-belive backtrace. The
> others are fine. Sadly, I can't open-source the test case, so I'm hoping that
> you will give me some advice as to how to be a remote-control debugging
> assistant to look into this. The AbstractMethodError is very hard for me to
> imagine explaining.
> {noformat}
> Running com.basistech.TestLogCallback
> 0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
> 6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
> java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
> 6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
> Exiting cleanup thread
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
> java.lang.AbstractMethodError:
> java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
> at
> org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-946) Maven hangs on SIGTERM when using Surefire forking (CommandLineUtils.ProcessHook)
[
https://jira.codehaus.org/browse/SUREFIRE-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-946.
---
Resolution: Fixed
Assignee: Kristian Rosenvold
Fixed in a series of patches ;)
> Maven hangs on SIGTERM when using Surefire forking
> (CommandLineUtils.ProcessHook)
> -
>
> Key: SUREFIRE-946
> URL: https://jira.codehaus.org/browse/SUREFIRE-946
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Jesse Glick
>Assignee: Kristian Rosenvold
> Fix For: 2.14
>
> Attachments: stack.txt, SUREFIRE-946.patch
>
>
> Java 7u7, Surefire with JUnit {{forkMode="perthread"}} + {{threadCount="1"}}
> + {{reuseForks="true"}}. After pressing Ctrl-C to stop the Maven test run,
> the process hangs and must be killed with SIGKILL. From the thread dump,
> {{CommandLineUtils.ProcessHook}} and {{StreamFeeder}} look responsible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-949) Create forkCount parameter
[ https://jira.codehaus.org/browse/SUREFIRE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-949: Fix Version/s: 2.14 > Create forkCount parameter > -- > > Key: SUREFIRE-949 > URL: https://jira.codehaus.org/browse/SUREFIRE-949 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Kristian Rosenvold > Fix For: 2.14 > > > The "threadCount" parameter is overloaded to the extent that it is becoming > problematic. A forkCount parameter would be nice, maybe supporting the same > style as maven-core "1.5C" for 1.5 x number of cores. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-949) Create forkCount parameter
[ https://jira.codehaus.org/browse/SUREFIRE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reassigned SUREFIRE-949: --- Assignee: Kristian Rosenvold > Create forkCount parameter > -- > > Key: SUREFIRE-949 > URL: https://jira.codehaus.org/browse/SUREFIRE-949 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.14 > > > The "threadCount" parameter is overloaded to the extent that it is becoming > problematic. A forkCount parameter would be nice, maybe supporting the same > style as maven-core "1.5C" for 1.5 x number of cores. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318221#comment-318221
]
Kristian Rosenvold commented on SUREFIRE-954:
-
You /may/ have to open surefire source, set a breakpoint at
LegacyPojoStackTraceWriter.java:54, run your test with
-Dmaven.surefire.debug=true and attach a debugger to see WTF is going on here
;) I wonder what "t" is. Also, it may be "interesting" what you can find out
about t's classloader; like inspecting t.getClass().getClassLoader(). /If/ the
classloader is an "IsolatedClassLoader" it has a roleName attribute. I sure
hope it's not the IsolatedClassLoader btw ;)
> Hard-to-believe abstract method error
> -
>
> Key: SUREFIRE-954
> URL: https://jira.codehaus.org/browse/SUREFIRE-954
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Benson Margulies
>
> I have a set of junit test that I am running with Surefire 2.13 with forkMode
> always. Two classes die with the following hard-to-belive backtrace. The
> others are fine. Sadly, I can't open-source the test case, so I'm hoping that
> you will give me some advice as to how to be a remote-control debugging
> assistant to look into this. The AbstractMethodError is very hard for me to
> imagine explaining.
> {noformat}
> Running com.basistech.TestLogCallback
> 0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
> 6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
> java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
> 6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
> Exiting cleanup thread
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
> java.lang.AbstractMethodError:
> java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
> at
> org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318219#comment-318219
]
Kristian Rosenvold commented on SUREFIRE-954:
-
Which jdk version are you running on ?
> Hard-to-believe abstract method error
> -
>
> Key: SUREFIRE-954
> URL: https://jira.codehaus.org/browse/SUREFIRE-954
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Benson Margulies
>
> I have a set of junit test that I am running with Surefire 2.13 with forkMode
> always. Two classes die with the following hard-to-belive backtrace. The
> others are fine. Sadly, I can't open-source the test case, so I'm hoping that
> you will give me some advice as to how to be a remote-control debugging
> assistant to look into this. The AbstractMethodError is very hard for me to
> imagine explaining.
> {noformat}
> Running com.basistech.TestLogCallback
> 0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
> 6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
> java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
> 6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
> Exiting cleanup thread
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
> java.lang.AbstractMethodError:
> java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
> at
> org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-386) build failure with jdk 1.7
Olivier Lamy created WAGON-386: -- Summary: build failure with jdk 1.7 Key: WAGON-386 URL: https://jira.codehaus.org/browse/WAGON-386 Project: Maven Wagon Issue Type: Bug Components: wagon-http, wagon-http-lightweight Affects Versions: 2.4 Environment: jdk 1.7 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-372. -- Resolution: Fixed > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen >Assignee: Olivier Lamy > Fix For: 2.4 > > Attachments: maven-httpwagen-httpclient-ssl-setup.patch, > maven-httpwagen-httpclient-ssl-setup-refactoring.patch > > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318207#comment-318207 ] Nicholas Williams commented on MNG-3559: My problem, it would appear, is that I now have the following options: - Duplicate the shared classes in every module. - Have a separate module that contains all of the unit tests for all modules; do not put unit tests in the modules they belong in. - Don't use modules. - Don't use Maven. I don't really like my choices here. :-/ > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: https://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Fix For: Issues to be reviewed for 3.x > > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318206#comment-318206 ] Nicholas Williams commented on MNG-3559: I don't understand how I'm losing dependency management here. I have a set of "helper" classes used to make certain testing operations easier in my project. These cannot be abstracted out of the project, because they depend on the project core. However, the tests for the project core rely on them for the testing. Putting them in the compile scope of a separate module would introduce a circular dependency; therefore, that is automatically not an option. What I want seems pretty simple. I want the test code for one module to be able to depend on the test code from another module. If we can make the main code from one module depend on the test code from another module, it seems we should be able to do the same thing for test code. And, indeed, there's this magical feature in Maven that is supposed to be able to do that, except it's broken. Whether or not this is a good feature in Maven is an entirely different discussion that I'd be happy to have with you. But the fact of the matter is that the feature exists in Maven and is documented as serving this purpose (http://maven.apache.org/guides/mini/guide-attached-tests.html). In fact, the documentation even says: bq. Note that previous editions of this guide suggested to use tests instead of test-jar. While this currently works for some cases, it does not properly work during a reactor build of the test JAR module and any consumer if a lifecycle phase prior to install is invoked. The problem, however, is that not even works during a reactor build of the test JAR module and any consumer. Not unless you run test-compile. But Even if you run test-compile, if you invoke subsequent goals it stil doesn't work. If it's not a good feature, then maybe it should be removed. I would argue that it needs to be fixed. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: https://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Fix For: Issues to be reviewed for 3.x > > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > ce
[jira] (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318203#comment-318203 ] Robert Scholte commented on MNG-3559: - @Nicholas: the short answer is https://twitter.com/jasondillon/status/290628687202754561, the more detailed answer is http://rfscholte.wordpress.com/2010/09/05/how-to-create-a-jar-containing-reusableabstract-testclasses-with-maven/ To me this issue is more of an anti-pattern and the blog explains why: you will loose dependency management. The patch assumes a way too simple usecase. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: https://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Fix For: Issues to be reviewed for 3.x > > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-954) Hard-to-believe abstract method error
Benson Margulies created SUREFIRE-954:
-
Summary: Hard-to-believe abstract method error
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The others
are fine. Sadly, I can't open-source the test case, so I'm hoping that you will
give me some advice as to how to be a remote-control debugging assistant to
look into this. The AbstractMethodError is very hard for me to imagine
explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-172) Checkstyle Plugin 2.8+ generates an additional aggregate report
[
https://jira.codehaus.org/browse/MCHECKSTYLE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318199#comment-318199
]
Dennis Lundberg commented on MCHECKSTYLE-172:
-
We need to release the plugins-parent first.
After that I'll release the maven-checkstyle-plugin 2.10.
> Checkstyle Plugin 2.8+ generates an additional aggregate report
> ---
>
> Key: MCHECKSTYLE-172
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-172
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.8, 2.9
> Environment: mvn --version
> Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: SebbASF
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> Using a very simple single module project, the aggregated report is created
> by default.
> Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-170) http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found
[ https://jira.codehaus.org/browse/MNGSITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318198#comment-318198 ] Robert Scholte commented on MNGSITE-170: That's because it does not exist. See http://maven.apache.org/plugins/maven-assembly-plugin/index.html#Assembly_and_Component_Descriptor_Schemas_XSD for all valid xsd's. Is there a page which refers to this XSD? > http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found > - > > Key: MNGSITE-170 > URL: https://jira.codehaus.org/browse/MNGSITE-170 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Ronnie Downing >Priority: Minor > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-89) Having an equivalent for auxclasspath option
[ https://jira.codehaus.org/browse/MPMD-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318197#comment-318197 ] Olivier Lamy commented on MPMD-89: -- sounds good. Feel free to apply it yourself :-) > Having an equivalent for auxclasspath option > > > Key: MPMD-89 > URL: https://jira.codehaus.org/browse/MPMD-89 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: PMD >Affects Versions: 2.4 > Environment: PMD 4.2.3 >Reporter: Benjamin Pochat > Attachments: MPMD-89.patch > > > Hi, > PMD 4.2.3 introduced the option "auxclasspath" described as follows in the > PMD help : > "-auxclasspath: specifies the classpath for libraries used by the source code > (used by type resolution)" > Currently, there seems to be no way to use this very useful option in the PMD > maven2 plugin. > I either found no workaround to deal with type resolution inside the project > that has just been built through the compile maven goal. > This would be great ! > Benjamin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-372: --- Fix Version/s: 2.4 Assignee: Olivier Lamy > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen >Assignee: Olivier Lamy > Fix For: 2.4 > > Attachments: maven-httpwagen-httpclient-ssl-setup.patch, > maven-httpwagen-httpclient-ssl-setup-refactoring.patch > > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-383) Regression for SSLv3
[ https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-383: --- Fix Version/s: 2.4 > Regression for SSLv3 > > > Key: WAGON-383 > URL: https://jira.codehaus.org/browse/WAGON-383 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2, 2.3 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka >Priority: Critical > Fix For: 2.4 > > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-170) http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found
Ronnie Downing created MNGSITE-170: -- Summary: http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found Key: MNGSITE-170 URL: https://jira.codehaus.org/browse/MNGSITE-170 Project: Maven Project Web Site Issue Type: Bug Reporter: Ronnie Downing Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318192#comment-318192 ] Olivier Lamy commented on WAGON-372: ok I have reverted some commits and it's better now. > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > Attachments: maven-httpwagen-httpclient-ssl-setup.patch, > maven-httpwagen-httpclient-ssl-setup-refactoring.patch > > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-136) Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT
[ https://jira.codehaus.org/browse/MSHADE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318184#comment-318184 ] Anthony Dahanne commented on MSHADE-136: Thanks to you Olivier ! looking forward the next release ! > Shade dependency reduced pom uses timestamp in artifact names instead of > -SNAPSHOT > -- > > Key: MSHADE-136 > URL: https://jira.codehaus.org/browse/MSHADE-136 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Hung Huynh >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: MSHADE-136_code2.patch, > MSHADE-136_integration-test1.patch > > > The major problem that we run into is that Maven would download that exact > timestamp artifact instead of using the latest. > Instead of this > > org.mycom > management-core > 1.1.0-20130115.201411-23 > compile > > should have been this > > org.mycom > management-core > 1.1.0-SNAPSHOT > compile > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski updated WAGON-372: Attachment: maven-httpwagen-httpclient-ssl-setup-refactoring.patch Let us try to tackle the problem in several incremental steps. Could you please see if all test cases pass for you locally with this patch only? The patch only refactors the SSL initialization code sowewhat without (intentionally) changing its behavior. Oleg > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > Attachments: maven-httpwagen-httpclient-ssl-setup.patch, > maven-httpwagen-httpclient-ssl-setup-refactoring.patch > > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-136) Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT
[ https://jira.codehaus.org/browse/MSHADE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-136. --- Resolution: Fixed Fix Version/s: 3.0 Assignee: Olivier Lamy applied http://svn.apache.org/r1439435 Thanks ! > Shade dependency reduced pom uses timestamp in artifact names instead of > -SNAPSHOT > -- > > Key: MSHADE-136 > URL: https://jira.codehaus.org/browse/MSHADE-136 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Hung Huynh >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: MSHADE-136_code2.patch, > MSHADE-136_integration-test1.patch > > > The major problem that we run into is that Maven would download that exact > timestamp artifact instead of using the latest. > Instead of this > > org.mycom > management-core > 1.1.0-20130115.201411-23 > compile > > should have been this > > org.mycom > management-core > 1.1.0-SNAPSHOT > compile > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-99) ${project.baseUri} and ${maven.build.timestamp} are not expanded by resource filtering
[
https://jira.codehaus.org/browse/MRESOURCES-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318179#comment-318179
]
Matthias Müller commented on MRESOURCES-99:
---
Just ran into this issue today. It's a pity it isn't solved after more than
three years :-(
Is backwards-compatibility to Maven 2.x important at this point?
When upgrading to Maven 3.x, man could somehow use a
{code}src.main.java.org.apache.maven.model.interpolation.BuildTimestampValueSource{code}
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/interpolation/BuildTimestampValueSource.java
I think someone who's familiar with building maven plugins (which excludes me
;-)) could do this in very little time...
> ${project.baseUri} and ${maven.build.timestamp} are not expanded by resource
> filtering
> ---
>
> Key: MRESOURCES-99
> URL: https://jira.codehaus.org/browse/MRESOURCES-99
> Project: Maven 2.x Resources Plugin
> Issue Type: Improvement
> Components: interpolation
>Affects Versions: 2.3, 2.4
>Reporter: Thomas Champagne
>
> When filtering resources, ${project.baseUri} and ${maven.build.timestamp} are
> not expanded (remains unchanged in the output file).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-374) dependency:tree -Dverbose isn't verbose anymore
[
https://jira.codehaus.org/browse/MDEP-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318178#comment-318178
]
Dev Antor commented on MDEP-374:
This bug is a removed feature? If the new verbose flag is deprecated, how I can
get omitted for conflict dependencies reports?
{noformat}
+- (org.springframework:spring-test:jar:3.0.5.RELEASE:compile - omitted for
conflict with 3.1.2.RELEASE)
[INFO] | +- (org.springframework:spring-beans:jar:3.0.5.RELEASE:compile -
omitted for conflict with 3.1.2.RELEASE)
[INFO] | +- (org.springframework:spring-core:jar:3.0.5.RELEASE:compile -
omitted for conflict with 3.1.2.RELEASE)
[INFO] | +- (org.springframework:spring-context:jar:3.0.5.RELEASE:compile -
omitted for conflict with 3.1.2.RELEASE)
{noformat}
> dependency:tree -Dverbose isn't verbose anymore
> ---
>
> Key: MDEP-374
> URL: https://jira.codehaus.org/browse/MDEP-374
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 2.5, 2.5.1
> Environment: maven 3.0.4 windows7 and linux
>Reporter: Arne Brix
>Priority: Minor
>
> Older versions of the plugin (for example 2.4) show information about
> duplicates when invoked with -Dverbose.
> The current versions show no reaction to -Dverbose at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[
https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318177#comment-318177
]
Oleg Kalnichevski commented on WAGON-372:
-
{{{
oleg@ubuntu:~/src/apache.org/maven/maven-wagon$ mvn -version
Maven home: /opt/maven
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: /opt/oracle-jdk-1.6.0.35/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.5.0-22-generic", arch: "amd64", family: "unix"
}}}
Oleg
> SSL client-side certificates stopped working in maven 3.0.4
> ---
>
> Key: WAGON-372
> URL: https://jira.codehaus.org/browse/WAGON-372
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2
> Environment: Fedora, Ubuntu
>Reporter: Igor von Nyssen
> Attachments: maven-httpwagen-httpclient-ssl-setup.patch
>
>
> The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem
> to open the key store and therefore client side certificate authentication
> fails as maven never presents a certificate to the server.
> mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12
> -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12
> adding -Djavax.net.debug=all reveals that the keystore is never loaded.
> Confirmed with strace that the keystore file is never touched or opened.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[
https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318177#comment-318177
]
Oleg Kalnichevski edited comment on WAGON-372 at 1/28/13 8:46 AM:
--
---
oleg@ubuntu:~/src/apache.org/maven/maven-wagon$ mvn -version
Maven home: /opt/maven
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: /opt/oracle-jdk-1.6.0.35/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.5.0-22-generic", arch: "amd64", family: "unix"
---
Oleg
was (Author: olegk):
{{{
oleg@ubuntu:~/src/apache.org/maven/maven-wagon$ mvn -version
Maven home: /opt/maven
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: /opt/oracle-jdk-1.6.0.35/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.5.0-22-generic", arch: "amd64", family: "unix"
}}}
Oleg
> SSL client-side certificates stopped working in maven 3.0.4
> ---
>
> Key: WAGON-372
> URL: https://jira.codehaus.org/browse/WAGON-372
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2
> Environment: Fedora, Ubuntu
>Reporter: Igor von Nyssen
> Attachments: maven-httpwagen-httpclient-ssl-setup.patch
>
>
> The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem
> to open the key store and therefore client side certificate authentication
> fails as maven never presents a certificate to the server.
> mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12
> -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12
> adding -Djavax.net.debug=all reveals that the keystore is never loaded.
> Confirmed with strace that the keystore file is never touched or opened.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[
https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318174#comment-318174
]
Olivier Lamy commented on WAGON-372:
what is your env ?
Because here https test doesn't pass anymore.
{code}
Maven home: /Users/olamy/softs/maven/trunk
Java version: 1.6.0_37, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: fr_FR, platform encoding: MacRoman
OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
{code}
> SSL client-side certificates stopped working in maven 3.0.4
> ---
>
> Key: WAGON-372
> URL: https://jira.codehaus.org/browse/WAGON-372
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2
> Environment: Fedora, Ubuntu
>Reporter: Igor von Nyssen
> Attachments: maven-httpwagen-httpclient-ssl-setup.patch
>
>
> The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem
> to open the key store and therefore client side certificate authentication
> fails as maven never presents a certificate to the server.
> mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12
> -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12
> adding -Djavax.net.debug=all reveals that the keystore is never loaded.
> Confirmed with strace that the keystore file is never touched or opened.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-158) Relative file name doesn't work when specifying ruleset
[
https://jira.codehaus.org/browse/MPMD-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Pushyk reopened MPMD-158:
---
Hi Denis!
Yes, I agree that this is expected behavior for Maven (resolving resources from
a module level). But it is unexpected behavior for Maven PMD Plugin, it looks
like it works inefficiently and tries to re-read configurations for every
sub-module.
Let me explain my idea: we have aggregator parent project with many child
sub-modules. Additionally it is a holder for PMD configuration files. So, I
want to benefit from such Maven feature as plugin inheritance which should
allow me to define/configure PMD plug-in at parent project level but to execute
it for all child sub-modules. What could you recommend in my situation? And I
don't want to duplicate PMD configuraion files for all child sub-mudules where
PMD report is needed.
Currently we are using workaround with PMD configuration location set with an
URL to configuration files our CI server which is not a good solution.
Btw, same thing (relative configuration file reference) works perfectly for
Maven Checkstyle plug-in...
Thanks for your support
> Relative file name doesn't work when specifying ruleset
> ---
>
> Key: MPMD-158
> URL: https://jira.codehaus.org/browse/MPMD-158
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.7.1
> Environment: Windows 7
>Reporter: Taras Pushyk
> Attachments: MPMD-158-With-Child-Module.zip, MPMD-158.zip
>
>
> When ruleset specified as follows:
> {code}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 2.7.1
>
> false 100 1.5
>
>../config/basic.xml
>
>
>
> {code}
> File is not resolved. Also following message appears on console:
> [DEBUG] The resource '../config/basic.xml' was not found with resourceLoader
> org.codehaus.plexus.resource.loader.FileResourceLoader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318172#comment-318172 ] Oleg Kalnichevski commented on WAGON-372: - Sorry, I should have mentioned that in my previous post. All tests when run as 'mvn clean test' pass for me. --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Maven Wagon SUCCESS [2.100s] [INFO] Apache Maven Wagon :: API . SUCCESS [3.069s] [INFO] Apache Maven Wagon :: Provider Test ... SUCCESS [1.273s] [INFO] Apache Maven Wagon :: Providers ... SUCCESS [0.296s] [INFO] Apache Maven Wagon :: Providers :: File Provider .. SUCCESS [1.139s] [INFO] Apache Maven Wagon :: Providers :: FTP Provider ... SUCCESS [6.410s] [INFO] Apache Maven Wagon :: Providers :: HTTP Shared Library 4 SUCCESS [1.284s] [INFO] Apache Maven Wagon :: Test Compatibility Kits . SUCCESS [0.214s] [INFO] Apache Maven Wagon :: HTTP Test Compatibility Kit . SUCCESS [0.625s] [INFO] Apache Maven Wagon :: Providers :: HTTP Provider .. SUCCESS [2:19.005s] [INFO] Apache Maven Wagon :: Providers :: HTTP Shared Library SUCCESS [1.027s] [INFO] Apache Maven Wagon :: Providers :: Lightweight HTTP Provider SUCCESS [1:52.511s] [INFO] Apache Maven Wagon :: Providers :: SCM Provider ... SUCCESS [4.794s] [INFO] Apache Maven Wagon :: Providers :: SSH Common Library SUCCESS [0.708s] [INFO] Apache Maven Wagon :: Providers :: SSH Common Tests SUCCESS [0.543s] [INFO] Apache Maven Wagon :: Providers :: SSH External Provider SUCCESS [0.491s] [INFO] Apache Maven Wagon :: Providers :: SSH Provider ... SUCCESS [0.569s] [INFO] Apache Maven Wagon :: Providers :: WebDav Provider SUCCESS [37.491s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 5:14.309s [INFO] Finished at: Mon Jan 28 15:27:05 CET 2013 [INFO] Final Memory: 26M/205M- --- git status --- oleg@ubuntu:~/src/apache.org/maven/maven-wagon$ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: wagon-providers/wagon-http-shared4/src/main/java/org/apache/maven/wagon/shared/http4/AbstractHttpClientWagon.java # modified: wagon-providers/wagon-http-shared4/src/main/java/org/apache/maven/wagon/shared/http4/ConfigurableSSLSocketFactory.java # new file: wagon-providers/wagon-http-shared4/src/main/java/org/apache/maven/wagon/shared/http4/ConfigurableSSLSocketFactoryDecorator.java --- git rev-parse HEAD --- d8b1974e91b1944efe964579b858bb54168fb70a --- Oleg > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > Attachments: maven-httpwagen-httpclient-ssl-setup.patch > > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-172) Checkstyle Plugin 2.8+ generates an additional aggregate report
[
https://jira.codehaus.org/browse/MCHECKSTYLE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318171#comment-318171
]
Justin Ye commented on MCHECKSTYLE-172:
---
Thank you, Dennis!
BTW, when will 2.10 be release?
> Checkstyle Plugin 2.8+ generates an additional aggregate report
> ---
>
> Key: MCHECKSTYLE-172
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-172
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.8, 2.9
> Environment: mvn --version
> Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: SebbASF
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> Using a very simple single module project, the aggregated report is created
> by default.
> Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-426) Improved handling of authenticated repositories when generating a project from an archetype
[ https://jira.codehaus.org/browse/ARCHETYPE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar moved MNG-5427 to ARCHETYPE-426: -- Complexity: (was: Intermediate) Component/s: (was: Artifacts and Repositories) Plugin Affects Version/s: (was: 3.0.4) Key: ARCHETYPE-426 (was: MNG-5427) Project: Maven Archetype (was: Maven 2 & 3) > Improved handling of authenticated repositories when generating a project > from an archetype > --- > > Key: ARCHETYPE-426 > URL: https://jira.codehaus.org/browse/ARCHETYPE-426 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Reporter: Greg Thomas >Priority: Minor > > Currently, if you wish to generate a project from an archetype that is held > in an authenticated repository, you have to ensure that the server holding > the artefact has an id in the format [archetypeArtifactId]-repo > (reference: > http://maven.apache.org/archetype/maven-archetype-plugin/faq.html). > This means that if you have half-a-dozen different archetypes in your > authenticated repository, you have to have half-a-dozen servers defined in > your settings.xml that differ only in their id. > Instead, it would make more sense if it was possible to supply the server id > as an optional parameter, e.g. -DServerId=banana (with associated entry in > the archetype-catalog). This could default to [archetypeArtifactId]-repo if > not supplied for backward compatibility. > That way, the settings.xml file will not fill up with duplicate > entries, all of which need modifying each and every time the password is > changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSOURCES-65) Can you please add skipIfEmpty like maven jar plugin.
[ https://jira.codehaus.org/browse/MSOURCES-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318168#comment-318168 ] Olivier Lamy commented on MSOURCES-65: -- per default forceCreation parameter have false value. So if your project doesn't have any sources no sources jar will be created. What is your use case exactly ? > Can you please add skipIfEmpty like maven jar plugin. > - > > Key: MSOURCES-65 > URL: https://jira.codehaus.org/browse/MSOURCES-65 > Project: Maven 2.x Source Plugin > Issue Type: Improvement >Reporter: Lefebvre JF > > Can you please add skipIfEmpty like maven jar plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAR-162) skipIfEmpty not work for test-jar goal
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318167#comment-318167 ] Olivier Lamy commented on MJAR-162: --- There is an integration test for MJAR-139 and it works (test jar not created) So do you have a sample project to demonstrate your trouble ? Thanks > skipIfEmpty not work for test-jar goal > -- > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF > > skipIfEmpty not work for test-jar goal -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5427) Improved handling of authenticated repositories when generating a project from an archetype
Greg Thomas created MNG-5427: Summary: Improved handling of authenticated repositories when generating a project from an archetype Key: MNG-5427 URL: https://jira.codehaus.org/browse/MNG-5427 Project: Maven 2 & 3 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 3.0.4 Reporter: Greg Thomas Priority: Minor Currently, if you wish to generate a project from an archetype that is held in an authenticated repository, you have to ensure that the server holding the artefact has an id in the format [archetypeArtifactId]-repo (reference: http://maven.apache.org/archetype/maven-archetype-plugin/faq.html). This means that if you have half-a-dozen different archetypes in your authenticated repository, you have to have half-a-dozen servers defined in your settings.xml that differ only in their id. Instead, it would make more sense if it was possible to supply the server id as an optional parameter, e.g. -DServerId=banana (with associated entry in the archetype-catalog). This could default to [archetypeArtifactId]-repo if not supplied for backward compatibility. That way, the settings.xml file will not fill up with duplicate entries, all of which need modifying each and every time the password is changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-358) Following mirror configuration from settings.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318160#comment-318160
]
Anders Hammar commented on ARCHETYPE-358:
-
As a note, there's A LOT of docs to update if we implement this change. It is
stated in several pages that the central repo url is used by default, which
should be changed to state that the url defined by the (magic) repo id
'central' is used.
> Following mirror configuration from settings.xml
>
>
> Key: ARCHETYPE-358
> URL: https://jira.codehaus.org/browse/ARCHETYPE-358
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator, Plugin
>Affects Versions: 2.1
>Reporter: Grégory Joseph
> Fix For: 2.3
>
> Attachments: patch.txt
>
>
> It looks like the current snapshot of the plugin does not follow the mirror
> configuration from my settings.xml when I do {{mvn archetype:generate}}. I
> would expect it to grab the catalog from
> {{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
> instead of the central one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style
[
https://jira.codehaus.org/browse/JXR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318161#comment-318161
]
Olivier Lamy commented on JXR-63:
-
yup please.
Merci !
> Bottom line in jxr report does not correspond to Javadoc style
> --
>
> Key: JXR-63
> URL: https://jira.codehaus.org/browse/JXR-63
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Michael Osipov
>
> I user JXR with Maven and produce Javadoc too.
> I've set:
> 2004
> MyOrg
> http://www.somedomain.com
> What the JAvadoc plugin does for the javadoc report is, it creates a bottom
> line like this:
> {code}
> Copyright © 2004-2008 http://www.somedomain.com";>MyOrg. All
> Rights Reserved.
> {code}
> but what jxr produces is
> {code}
> Copyright © 2004-2008 MyOrg. All Rights Reserved.
> {code}
> Because JXR tries to resemble javadoc, this bottom line should produce the
> same ouput
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-358) Following mirror configuration from settings.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318159#comment-318159
]
Anders Hammar commented on ARCHETYPE-358:
-
I agree. Trading the hardcoded url for the repo/server id is good. And then use
the standard Maven logic for using the correct mirror.
> Following mirror configuration from settings.xml
>
>
> Key: ARCHETYPE-358
> URL: https://jira.codehaus.org/browse/ARCHETYPE-358
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator, Plugin
>Affects Versions: 2.1
>Reporter: Grégory Joseph
> Fix For: 2.3
>
> Attachments: patch.txt
>
>
> It looks like the current snapshot of the plugin does not follow the mirror
> configuration from my settings.xml when I do {{mvn archetype:generate}}. I
> would expect it to grab the catalog from
> {{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
> instead of the central one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4
[ https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski updated WAGON-372: Attachment: maven-httpwagen-httpclient-ssl-setup.patch By default Apache HttpClient does not make use of global system properties. One needs to explicitly configure the connection manager to take system properties into account at the initialization time, if appropriate winthin a particular application context. The attach patch should fix the issue by tweaking SSL context initialization in the AbstractHttpClientWagon class. Please review. Oleg > SSL client-side certificates stopped working in maven 3.0.4 > --- > > Key: WAGON-372 > URL: https://jira.codehaus.org/browse/WAGON-372 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2 > Environment: Fedora, Ubuntu >Reporter: Igor von Nyssen > Attachments: maven-httpwagen-httpclient-ssl-setup.patch > > > The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem > to open the key store and therefore client side certificate authentication > fails as maven never presents a certificate to the server. > mvn deploy -Djavax.net.ssl.keyStore=/home//ssl/key.p12 > -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12 > adding -Djavax.net.debug=all reveals that the keystore is never loaded. > Confirmed with strace that the keystore file is never touched or opened. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-196) use of repository assembly is no longer working
[
https://jira.codehaus.org/browse/MASSEMBLY-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318137#comment-318137
]
David Bernard commented on MASSEMBLY-196:
-
Same issue with maven 3.0.4 and maven-assembly-plugin 2.4
The jar of the project is missing (pom.xml is present) from the generated
repository.
It's a crappy but I used the following work arround :
{code:xml}
${project.build.directory}
/lib/net/alchim31/runner/${project.artifactId}/${project.version}
${project.build.finalName}.jar
/lib
true
runtime
{code}
> use of repository assembly is no longer working
> ---
>
> Key: MASSEMBLY-196
> URL: https://jira.codehaus.org/browse/MASSEMBLY-196
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Brett Porter
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I have the following that works in 2.1:
>
>
> repository/releases
> true
>
>
> org.apache.maven
> 2.0.5
>
> maven-plugin-surrogate-parent
> maven-archetype
> maven-archetype-core
> maven-archiver
> maven-parent
> maven-jxr
> maven-plugin-tools-java
> maven-plugin-tools-beanshell
> maven-plugin-tools-api
> maven-plugin-tools
>
>
>
>
>
> However, in 2.2-beta-1 it results in an empty directory being created in the
> assembly instead of copying the repository contents.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
