[jira] Issue Comment Edited: (SUREFIRE-513) Surefire Integration Test no longer valid when run with Maven 2.0.9+
[
http://jira.codehaus.org/browse/SUREFIRE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145124#action_145124
]
danttran edited comment on SUREFIRE-513 at 8/15/08 2:22 AM:
I think i have a solution for this,
Have the surefire-integration-tests/pom.xml to pass surefire.version, extracted
from ${project.version} to surefire plugin, as system property.
Have the main test to pass down the version to all of its maven test projects.
was (Author: danttran):
I think i have a solution for this,
Have the surefire-integration-test/pom.xml to pass surefire.version, extracted
from ${project.version} to as system property,
have the main test to pass down the version down to all of its maven test
projects.
> Surefire Integration Test no longer valid when run with Maven 2.0.9+
>
>
> Key: SUREFIRE-513
> URL: http://jira.codehaus.org/browse/SUREFIRE-513
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: windows, unix
>Reporter: Dan Tran
>Assignee: Dan Tran
>
> The current surefire-intergration-test module does not define version tag in
> all of its test poms and therefore starting with maven 2.0.9, the integration
> tests use the implicit surefire 2.4.2.
> This means it does not run with dev version currently at 2.5-SNAPSHOT .
> Also any new features( ie SUREFIRE-511) cannot be tested either, it wont run
> with 2.4.2
> below is a list of fail tests that trigger this finding.
> Here is the summary
> Running org.apache.maven.surefire.its.TestNgSuiteXmlTest
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.89 sec <<<
> FA
> ILURE!
> Running org.apache.maven.surefire.its.TestNgSuiteXmlSingleTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.422 sec <<<
> FA
> ILURE!
> On Linux
> Failed tests:
> testTestNGSuite(org.apache.maven.surefire.its.TestNgSuiteXmlSingleTest)
> Tests in error:
>
> testTestNgSuiteXmlForkModeAlways(org.apache.maven.surefire.its.TestNgSuiteXmlT
> est)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145130#action_145130 ] Maria Odea Ching commented on MNG-553: -- I made some updates in the design docs: http://docs.codehaus.org/display/MAVEN/Secured+Passwords I already included password encryption in the document. Please review.. Thanks! > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 3.0 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145141#action_145141 ] Paul Benedict commented on MNG-553: --- I think we should go for the full kitchen sink solution. We shouldn't invite something new, but should provide adapters to datastores. Just do what Spring (Acegi) Security did, which is provide a simple API to be implemented by anyone who wants to write in a provider NT authentication, LDAP, DB2, etc. > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 3.0 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145141#action_145141 ] paul4christ79 edited comment on MNG-553 at 8/15/08 5:45 AM: I think we should go for the full kitchen sink solution. We shouldn't invent something new, but should provide adapters to datastores. Just do what Spring (Acegi) Security did, which is provide a simple API to be implemented by anyone who wants to write in a provider NT authentication, LDAP, DB2, etc. was (Author: paul4christ79): I think we should go for the full kitchen sink solution. We shouldn't invite something new, but should provide adapters to datastores. Just do what Spring (Acegi) Security did, which is provide a simple API to be implemented by anyone who wants to write in a provider NT authentication, LDAP, DB2, etc. > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 3.0 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-237) deploy broke in 2.0.10-RC8
deploy broke in 2.0.10-RC8 -- Key: WAGON-237 URL: http://jira.codehaus.org/browse/WAGON-237 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-4 Environment: Maven version: 2.0.10-RC8 Java version: 1.5.0_13 Default locale: en_US, platform encoding: ISO8859-1 OS name: "sunos" version: "5.10" arch: "sparc" family: "unix" Reporter: David J. M. Karlsen Starting from 2.0.10-RC8 deploy (with ssh and password) started to fail - I'm getting: [DEBUG] Connecting to repository: 'repo.sandsli.dnb.no' with url: 'scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage'. Keyboard interactive required, supplied password is ignored event though the pw is in settings.xml: With help from Brett this was added: org.apache.maven.wagon wagon-ssh 1.0-beta-2 which resolved the case. Fragment from settings.xml: MyUser MySecret 777 777 repo.sandsli.dnb.no Fragment from pom.xml: repo.sandsli.dnb.no DnBNOR Felles Repository scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse/storage repo.sandsli.dnb.no DnBNOR Felles Snapshot Repository scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage repo.sandsli.dnb.no scp://repo.sandsli.dnb.no/dnb/prosess/prosjektdok/no.dnbnor.websphere-1.3-SNAPSHOT/websphere-testenvironment -- 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: (WAGON-237) keyboard-interactive method is used even when password is supplied
[ http://jira.codehaus.org/browse/WAGON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-237: --- Summary: keyboard-interactive method is used even when password is supplied (was: deploy broke in 2.0.10-RC8) > keyboard-interactive method is used even when password is supplied > -- > > Key: WAGON-237 > URL: http://jira.codehaus.org/browse/WAGON-237 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 1.0-beta-4 > Environment: Maven version: 2.0.10-RC8 > Java version: 1.5.0_13 > Default locale: en_US, platform encoding: ISO8859-1 > OS name: "sunos" version: "5.10" arch: "sparc" family: "unix" >Reporter: David J. M. Karlsen > Fix For: 1.0-beta-5 > > > Starting from 2.0.10-RC8 deploy (with ssh and password) started to fail - I'm > getting: > [DEBUG] Connecting to repository: 'repo.sandsli.dnb.no' with url: > 'scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage'. > Keyboard interactive required, supplied password is ignored > event though the pw is in settings.xml: > With help from Brett this was added: > > > > org.apache.maven.wagon > wagon-ssh > 1.0-beta-2 > > > which resolved the case. > Fragment from settings.xml: > > > MyUser > MySecret > 777 > 777 > repo.sandsli.dnb.no > > Fragment from pom.xml: > > > repo.sandsli.dnb.no > DnBNOR Felles Repository > scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse/storage > > > repo.sandsli.dnb.no > DnBNOR Felles Snapshot Repository > > scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage > > > repo.sandsli.dnb.no > > scp://repo.sandsli.dnb.no/dnb/prosess/prosjektdok/no.dnbnor.websphere-1.3-SNAPSHOT/websphere-testenvironment > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-237) keyboard-interactive method is used even when password is supplied
[ http://jira.codehaus.org/browse/WAGON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-237. -- Assignee: Brett Porter Resolution: Fixed Fix Version/s: 1.0-beta-5 this was fixed by preferring the password authentication method when a password is supplied in the configuration > keyboard-interactive method is used even when password is supplied > -- > > Key: WAGON-237 > URL: http://jira.codehaus.org/browse/WAGON-237 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 1.0-beta-4 > Environment: Maven version: 2.0.10-RC8 > Java version: 1.5.0_13 > Default locale: en_US, platform encoding: ISO8859-1 > OS name: "sunos" version: "5.10" arch: "sparc" family: "unix" >Reporter: David J. M. Karlsen >Assignee: Brett Porter > Fix For: 1.0-beta-5 > > > Starting from 2.0.10-RC8 deploy (with ssh and password) started to fail - I'm > getting: > [DEBUG] Connecting to repository: 'repo.sandsli.dnb.no' with url: > 'scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage'. > Keyboard interactive required, supplied password is ignored > event though the pw is in settings.xml: > With help from Brett this was added: > > > > org.apache.maven.wagon > wagon-ssh > 1.0-beta-2 > > > which resolved the case. > Fragment from settings.xml: > > > MyUser > MySecret > 777 > 777 > repo.sandsli.dnb.no > > Fragment from pom.xml: > > > repo.sandsli.dnb.no > DnBNOR Felles Repository > scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse/storage > > > repo.sandsli.dnb.no > DnBNOR Felles Snapshot Repository > > scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage > > > repo.sandsli.dnb.no > > scp://repo.sandsli.dnb.no/dnb/prosess/prosjektdok/no.dnbnor.websphere-1.3-SNAPSHOT/websphere-testenvironment > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-239) remove password workaround hack in TraditionalKeyboardInteractive
remove password workaround hack in TraditionalKeyboardInteractive - Key: WAGON-239 URL: http://jira.codehaus.org/browse/WAGON-239 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-4 Reporter: Brett Porter since the preferred authentications is now set to prefer password when given, we should not try to intercept requests for this in keyboard interactive -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-238) cache passwords for the wagon connection once they have been typed in
cache passwords for the wagon connection once they have been typed in - Key: WAGON-238 URL: http://jira.codehaus.org/browse/WAGON-238 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-4 Reporter: Brett Porter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3717) Maven prompts for a password when one is provided over SSH in some circumstances
Maven prompts for a password when one is provided over SSH in some circumstances Key: MNG-3717 URL: http://jira.codehaus.org/browse/MNG-3717 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.10 Reporter: Brett Porter Maven 2.0.10 suffers from WAGON-237 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3717) Maven prompts for a password when one is provided over SSH in some circumstances
[ http://jira.codehaus.org/browse/MNG-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3717. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.0.10 > Maven prompts for a password when one is provided over SSH in some > circumstances > > > Key: MNG-3717 > URL: http://jira.codehaus.org/browse/MNG-3717 > Project: Maven 2 > Issue Type: Bug > Components: Deployment >Affects Versions: 2.0.10 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.0.10 > > > Maven 2.0.10 suffers from WAGON-237 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-101) Skip should skip everything including the Velocity initialization
Skip should skip everything including the Velocity initialization
-
Key: MCHECKSTYLE-101
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-101
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Steve Gilbert
The "skip" configuration property prevents the check from happening, however,
Velocity still gets initialized. For a small project, this takes the build
time from 5 seconds without checkstyle in the pom to 13 seconds with it in and
skip=true. While 8 seconds does not seem like much, it adds up over the course
of days and weeks. Note that we have checkstyle hooked in at the verify/check
phase/goal to cause the build to fail on a checkstyle violation during a
typical developer's compilation they do all the time.
Build output with skip=true:
[INFO] Preparing checkstyle:check
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] **
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File:
org\apache\velocity\runtime\defaults\velocity.properties
[INFO] Default ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated:
org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any
resource loader.
[INFO] Velocimacro : error using VM library template VM_global_library.vm :
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'VM_global_library.vm'
[INFO] Velocimacro : VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT
replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
global in scope if allowed.
[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[INFO] [checkstyle:checkstyle]
[INFO] [checkstyle:check {execution: default}]
See also MCHECKSTYLE-71.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3718) Build timestamp interpolator gives hours in AM/PM instead of 24-hour time
[ http://jira.codehaus.org/browse/MNG-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3718: Assignee: John Casey Fix Version/s: 2.0.10 > Build timestamp interpolator gives hours in AM/PM instead of 24-hour time > - > > Key: MNG-3718 > URL: http://jira.codehaus.org/browse/MNG-3718 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Minor > Fix For: 2.0.10 > > > switching "MMdd hhmm" to "MMdd HHmm" > somehow I can't keep those two straight... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3718) Build timestamp interpolator gives hours in AM/PM instead of 24-hour time
Build timestamp interpolator gives hours in AM/PM instead of 24-hour time - Key: MNG-3718 URL: http://jira.codehaus.org/browse/MNG-3718 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.10 Reporter: John Casey Priority: Minor Fix For: 2.0.10 switching "MMdd hhmm" to "MMdd HHmm" somehow I can't keep those two straight... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3718) Build timestamp interpolator gives hours in AM/PM instead of 24-hour time
[ http://jira.codehaus.org/browse/MNG-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3718. --- Resolution: Fixed unit test included. > Build timestamp interpolator gives hours in AM/PM instead of 24-hour time > - > > Key: MNG-3718 > URL: http://jira.codehaus.org/browse/MNG-3718 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Minor > Fix For: 2.0.10 > > > switching "MMdd-hhmm" to "MMdd-HHmm" > somehow I can't keep those two straight... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3718) Build timestamp interpolator gives hours in AM/PM instead of 24-hour time
[ http://jira.codehaus.org/browse/MNG-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3718: Description: switching "MMdd-hhmm" to "MMdd-HHmm" somehow I can't keep those two straight... was: switching "MMdd hhmm" to "MMdd HHmm" somehow I can't keep those two straight... > Build timestamp interpolator gives hours in AM/PM instead of 24-hour time > - > > Key: MNG-3718 > URL: http://jira.codehaus.org/browse/MNG-3718 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Minor > Fix For: 2.0.10 > > > switching "MMdd-hhmm" to "MMdd-HHmm" > somehow I can't keep those two straight... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-596) gwt-dev 1.4.62 POM points to gwt-servlet artifact
gwt-dev 1.4.62 POM points to gwt-servlet artifact - Key: MEV-596 URL: http://jira.codehaus.org/browse/MEV-596 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Jeffrey Willis http://repo1.maven.org/maven2/com/google/gwt/gwt-dev/1.4.62/gwt-dev-1.4.62.pom points to artifact ID "gwt-servlet", which is incorrect. It should be "gwt-dev". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-55) Filter IT POMs in-place if cloneProjectsTo is used
Filter IT POMs in-place if cloneProjectsTo is used
--
Key: MINVOKER-55
URL: http://jira.codehaus.org/browse/MINVOKER-55
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Benjamin Bentmann
Priority: Minor
Currently, the plugin outputs the filtered POMs to temporary files named
{{interpolated-pom.xml}}. When the IT projects are entirely cloned to a
temporary location via {{cloneProjectsTo}}, there is no need to use another
temporary POM file, we can directly filter the cloned POM.
This has the benefit that once {{invoker:run}} has been called, the directory
given by {{cloneProjectsTo}} contains a filtered clone of the IT projects. If
an IT failed, one can now easily {{cd}} to the cloned project and run
{{mvnDebug ...}} on the filtered POM.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-55) Filter IT POMs in-place if cloneProjectsTo is used
[
http://jira.codehaus.org/browse/MINVOKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINVOKER-55.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.3
Done in [r686291|http://svn.apache.org/viewvc?view=rev&revision=686291].
> Filter IT POMs in-place if cloneProjectsTo is used
> --
>
> Key: MINVOKER-55
> URL: http://jira.codehaus.org/browse/MINVOKER-55
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 1.3
>
>
> Currently, the plugin outputs the filtered POMs to temporary files named
> {{interpolated-pom.xml}}. When the IT projects are entirely cloned to a
> temporary location via {{cloneProjectsTo}}, there is no need to use another
> temporary POM file, we can directly filter the cloned POM.
> This has the benefit that once {{invoker:run}} has been called, the directory
> given by {{cloneProjectsTo}} contains a filtered clone of the IT projects. If
> an IT failed, one can now easily {{cd}} to the cloned project and run
> {{mvnDebug ...}} on the filtered POM.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3719) Need to have a way to either define plugin execution dependencies on other plugin executions having executed first (at least within same lifecycle phase)
Need to have a way to either define plugin execution dependencies on other
plugin executions having executed first (at least within same lifecycle phase)
-
Key: MNG-3719
URL: http://jira.codehaus.org/browse/MNG-3719
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9
Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client
VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
Reporter: Gary S. Weaver
Priority: Critical
Attachments: plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
I extend my sincere apologies if there is a much easier way of doing this, but
so far I haven't found any.
There should be some way to ensure order of plugin executions through
dependencies on other executions. See attached project for example, or see
below for the applicable example in a pom.xml. When plugins are defined in
pom.xml in the following manner to ensure correct execution order, they are not
executed sequentially and there is no way to indicate dependencies, as would be
expected (note- I'm not expecting that it interpret the "step 1...", ..., "step
5..." IDs, I'm only suggesting that either the plugins be executed in order
that they are found in the XML (most intuitive) or that there be some concept
of priority/ordinal added, or even perhaps (this would be most "ant-like") that
plugin executions (and maybe even plugin goal executions) be allowed to define
prequisite execution IDs to be run (even if they are IDs not defined in the
pom, but maybe a parent pom, even though I don't need that right now).
I know that this could be problematic if a plugin execution from one lifecycle
phase depends on another from another lifecycle phase (and you could get into
circular references that way that would have to be recognized during pom
validation after loading/merging pom.xmls). However, not being able to at the
very least define order of execution of different (or the same) plugin
executions as noted below and in attached project makes it difficult to chain
plugin executions that depend on each other, thereby reducing the practicality
of the pom.xml and Maven 2.
For example, these plugin executions cannot be ordered properly in Maven 2.0.9,
since there appears to be no way to indicate dependencies of one execution on
another:
{code}
org.apache.maven.plugins
maven-compiler-plugin
1.5
1.5
org.apache.maven.plugins
maven-antrun-plugin
step 1 - backup-original-web.xml-from-src
generate-resources
run
org.codehaus.mojo
jspc-maven-plugin
step 2 - jspc
generate-resources
compile
org.apache.pluto
pluto-taglib
1.1.3
jar
javax.portlet
portlet-api
1.0
jar
javax.servlet
jstl
1.1.2
jar
taglibs
standard
1.1.2
jar
org.apache.maven.plugins
maven-antrun-plugin
step 3 - copy-jspc-web.xml-atop-web.xml-in-src
generate-resources
run
[jira] Commented: (MNG-2784) Multiple executions of the same plugin at the same life cycle phase in a multi-module profile mixed up
[
http://jira.codehaus.org/browse/MNG-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145198#action_145198
]
Gary S. Weaver commented on MNG-2784:
-
Nevermind attachment MNG-2784-issue-with-maven-2.0.9.tar.gz and my comment - I
created another bug: MNG-3719 ("Need to have a way to either define plugin
execution dependencies on other plugin executions having executed first (at
least within same lifecycle phase")
> Multiple executions of the same plugin at the same life cycle phase in a
> multi-module profile mixed up
> --
>
> Key: MNG-2784
> URL: http://jira.codehaus.org/browse/MNG-2784
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build, Plugins and Lifecycle, Profiles,
> Reactor and workspace
>Affects Versions: 2.0.4, 2.0.5
>Reporter: Maik Ebert
>Assignee: Jason van Zyl
>Priority: Critical
> Fix For: 2.0.7
>
> Attachments: MNG-2784-issue-with-maven-2.0.9.tar.gz, MNG-2784.patch
>
>
> I use the latest Maven 2.0.5 build found at
> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/
> I have multiple executions of the same plugin at the same life cycle phase in
> a multi-module parent POM. There was a bug regarding the order of this
> executions. This was fixed at 2.0.5.
> Now I needed to extract these plugin executions to a profile in this parent
> POM. Now the executions are not ordered correctly anymore :-(
> Before (works fine):
> parent\pom.xml <= multiple executions of the same plugin at the same life
> cycle phase in the default build element
> parent \child1\pom.xml
> parent \child2\pom.xml
> Calling mvn install in parent works fine.
> After (fails):
> parent\pom.xml <= multiple executions of the same plugin at the same life
> cycle phase in the build element of a profile
> parent \child1\pom.xml
> parent \child2\pom.xml
> Calling mvn install in parent mixed up the execution order in the childs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3719) Need to have a way to either define plugin execution dependencies on other plugin executions having executed first (at least within same lifecycle phase)
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145199#action_145199
]
Gary S. Weaver commented on MNG-3719:
-
Note: the fact that that associated project's pom.xml and plugin executions
above are tied to the same lifecycle and yet do not execute in order seems to
be a bug with Maven 2, since it states on the lifecycle page in the
documentation
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
that:
"Note: As of Maven 2.0.5, multiple goals bound to a phase are executed in the
same order as they are declared in the POM."
However, it appears that is not working in Maven 2.0.9, because if it were,
then the above pom would execute in order as intended.
I think though that having executions be allowed to specify dependencies on
other executions is probably the better way to do it, wouldn't it be?
> Need to have a way to either define plugin execution dependencies on other
> plugin executions having executed first (at least within same lifecycle phase)
> -
>
> Key: MNG-3719
> URL: http://jira.codehaus.org/browse/MNG-3719
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.9
> Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
> Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
>Reporter: Gary S. Weaver
>Priority: Critical
> Attachments: plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
>
>
> I extend my sincere apologies if there is a much easier way of doing this,
> but so far I haven't found any.
> There should be some way to ensure order of plugin executions through
> dependencies on other executions. See attached project for example, or see
> below for the applicable example in a pom.xml. When plugins are defined in
> pom.xml in the following manner to ensure correct execution order, they are
> not executed sequentially and there is no way to indicate dependencies, as
> would be expected (note- I'm not expecting that it interpret the "step 1...",
> ..., "step 5..." IDs, I'm only suggesting that either the plugins be executed
> in order that they are found in the XML (most intuitive) or that there be
> some concept of priority/ordinal added, or even perhaps (this would be most
> "ant-like") that plugin executions (and maybe even plugin goal executions) be
> allowed to define prequisite execution IDs to be run (even if they are IDs
> not defined in the pom, but maybe a parent pom, even though I don't need that
> right now).
> I know that this could be problematic if a plugin execution from one
> lifecycle phase depends on another from another lifecycle phase (and you
> could get into circular references that way that would have to be recognized
> during pom validation after loading/merging pom.xmls). However, not being
> able to at the very least define order of execution of different (or the
> same) plugin executions as noted below and in attached project makes it
> difficult to chain plugin executions that depend on each other, thereby
> reducing the practicality of the pom.xml and Maven 2.
> For example, these plugin executions cannot be ordered properly in Maven
> 2.0.9, since there appears to be no way to indicate dependencies of one
> execution on another:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
[jira] Created: (MINVOKER-56) Clone all projects which are locally reachable from the invoked IT project
Clone all projects which are locally reachable from the invoked IT project
--
Key: MINVOKER-56
URL: http://jira.codehaus.org/browse/MINVOKER-56
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Benjamin Bentmann
Imagine the following directory structure:
{noformat}
./
aggregator/ (references module)
module/ (inherits from module-parent)
module-parent/
{noformat}
Further assume the Invoker Plugin is configured to clone the projects and
{{aggregator}} is the only project selected for invocation via {{pomIncludes}}.
Currently, the plugin will only clone projects which have been matched via the
include/exclude patterns. For the above example, this means only {{aggregator}}
is cloned. Its invocation will then fail since the other projects (indirectly)
referenced by it, namely {{module}} and {{module-parent}}, haven't been cloned.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-56) Clone all projects which are locally reachable from the invoked IT project
[
http://jira.codehaus.org/browse/MINVOKER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINVOKER-56.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.3
Done in [r686368|http://svn.apache.org/viewvc?view=rev&revision=686368].
> Clone all projects which are locally reachable from the invoked IT project
> --
>
> Key: MINVOKER-56
> URL: http://jira.codehaus.org/browse/MINVOKER-56
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.3
>
>
> Imagine the following directory structure:
> {noformat}
> ./
> aggregator/ (references module)
> module/ (inherits from module-parent)
> module-parent/
> {noformat}
> Further assume the Invoker Plugin is configured to clone the projects and
> {{aggregator}} is the only project selected for invocation via
> {{pomIncludes}}.
> Currently, the plugin will only clone projects which have been matched via
> the include/exclude patterns. For the above example, this means only
> {{aggregator}} is cloned. Its invocation will then fail since the other
> projects (indirectly) referenced by it, namely {{module}} and
> {{module-parent}}, haven't been cloned.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-399) Provider Util Class could be generalized
Provider Util Class could be generalized Key: SCM-399 URL: http://jira.codehaus.org/browse/SCM-399 Project: Maven SCM Issue Type: Improvement Affects Versions: 1.1 Reporter: Vincent Siveton See StarteamUtil vs CvsUtil vs SvnUtil vs GitUtil -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGSITE-61) mirror sync: rsync improvements
mirror sync: rsync improvements --- Key: MNGSITE-61 URL: http://jira.codehaus.org/browse/MNGSITE-61 Project: Maven 2 Project Web Site Issue Type: Bug Environment: Linux, but probably other unix-like systems as well Reporter: Jørgen Wahlberg After having problems fetching artifacts from my private maven 2 repository mirror, I discovered that I had no read permission for asm:asm:pom:3.1 After cursing a bit and debugging some more, I disovered that only owner and group were allowed to enter the directory .../asm/asm/3.1/ in my file system. I then disovered that the rsync suggested in http://maven.apache.org/guides/mini/guide-mirror-settings.html have a deficiency: it will not change the permissions of files and directories after they have been downloaded. In this case, I suspect that the directory was set to permissions 750 (or similar) the first time it was downloaded to my mirror and then later changed to 775. Fix: change the suggested rsync command to rsync -v -p -t -l -r mirrors.ibiblio.org::maven2 /your/local/path (notice the -p switch), or suggest using a chmod -R a+rX /your/local/path after doing the rsync. -- 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: (MDEP-176) excludes not considered in analyze?
[ http://jira.codehaus.org/browse/MDEP-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145229#action_145229 ] Brian Fox commented on MDEP-176: Where / how exactly is it failing? Are you extending an interface, or using a constant? Both of these are known to trick the analysis into thinking it's not needed because the compiler optimizes it out. > excludes not considered in analyze? > --- > > Key: MDEP-176 > URL: http://jira.codehaus.org/browse/MDEP-176 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0 >Reporter: David Jencks >Assignee: Brian Fox > > in dependencyManagement of parent pom I have: > > org.apache.xmlbeans > xmlbeans > 2.3.0 > > > stax > stax-api > > > > In a child project... > > org.apache.xmlbeans > xmlbeans > > > org.apache.geronimo.specs > geronimo-stax-api_1.0_spec > > dependency:analyze reports > [WARNING] Unused declared dependencies found: > [WARNING] > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile > but removing the geronimo stax api makes the build fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-511) Proposal to use java Map for surefire's systemProperties
[ http://jira.codehaus.org/browse/SUREFIRE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SUREFIRE-511. - Resolution: Fixed Fixed at Revision: 686454 Author: dantran Date: 10:58:02 PM, Friday, August 15, 2008 Message: - SUREFIRE-511: Replacement of 'systemProperties' to use Map interface. - Add partial fix for SUREFIRE-513 to support SUREFIRE-511 ITs - ignore eclipse workspace folder Modified : /maven/surefire/trunk Modified : /maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java Modified : /maven/surefire/trunk/maven-surefire-plugin/src/site/apt/examples/system-properties.apt Modified : /maven/surefire/trunk/surefire-integration-tests/pom.xml Added : /maven/surefire/trunk/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/AbstractSurefireIT.java Modified : /maven/surefire/trunk/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/AbstractTestCaseTest.java Modified : /maven/surefire/trunk/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/SystemPropertiesTest.java Modified : /maven/surefire/trunk/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/TestNgSuiteXmlTest.java Modified : /maven/surefire/trunk/surefire-integration-tests/src/test/resources/system-properties/pom.xml Modified : /maven/surefire/trunk/surefire-integration-tests/src/test/resources/system-properties/src/test/java/systemProperties/BasicTest.java Modified : /maven/surefire/trunk/surefire-integration-tests/src/test/resources/testng-suite-xml/pom.xml > Proposal to use java Map for surefire's systemProperties > - > > Key: SUREFIRE-511 > URL: http://jira.codehaus.org/browse/SUREFIRE-511 > Project: Maven Surefire > Issue Type: Improvement > Components: plugin >Affects Versions: 2.4.3 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 2.5 > > Attachments: SUREFIRE-511.patch > > > There is a known problem documented at > http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html > where maven properties other than java String are not able to pass into > surefire > This is mainly because systemProperties is mapped to java Properties class. > However if we map it to java Map > the problem solves. > see > http://svn.codehaus.org/mojo/trunk/mojo/build-helper-maven-plugin/src/it/surefire > for details. > So I would like to propose that we deprecate "systemProperties" and introduce > a new one "systemPropertyVariables" to use java Map ( similar to surefire's > environmentVariables" > Thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-514) Provide a way to skip a project's tests if nothing has changed
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 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
