[jira] Commented: (MNG-3588) ${maven.repo.local} in settings.xml doesn't work.
[
http://jira.codehaus.org/browse/MNG-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138495#action_138495
]
Brett Porter commented on MNG-3588:
---
sorry, all I meant was has the setting you are trying to use worked in a
previous version of Maven in your experience?
If you do wish to write a test case that exhibits a problem, the instructions
are here:
http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test
> ${maven.repo.local} in settings.xml doesn't work.
> -
>
> Key: MNG-3588
> URL: http://jira.codehaus.org/browse/MNG-3588
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Marcin Kuthan
>Priority: Minor
> Fix For: 2.0.x
>
>
> I can't use ${maven.repo.local} parameter inside settings.xml file. The
> parameter is simply ignored.
>
> c:\base_repo_location
>
>
> my-profile
>
>
> C:\alternative_repo_location
>
>
>
>
> When I run
> "mvn -P my-profile package"
> all downloaded artifacts are stored under "c:\base_repo_location" not
> "C:\alternative_repo_location".
> When I run
> "mvn -Dmaven.repo.local=C:\alternative_repo_location package" package
> artifacts are stored under "C:\alternative_repo_location" as I expected.
--
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-3588) ${maven.repo.local} in settings.xml doesn't work.
[
http://jira.codehaus.org/browse/MNG-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138494#action_138494
]
Marcin Kuthan commented on MNG-3588:
The parameter ${settings.localRepository} doesn't work as well. The parameter
inside profile is simply ignored.
It seems that command "mvn
-Dsettings.localRepository=C:\alternative_repo_location package" also doesn't
work, all artifacts are stored under default location.
I don't know how to prepare regression test for this case. Where can I find any
maven regression testing manual?
> ${maven.repo.local} in settings.xml doesn't work.
> -
>
> Key: MNG-3588
> URL: http://jira.codehaus.org/browse/MNG-3588
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Marcin Kuthan
>Priority: Minor
> Fix For: 2.0.x
>
>
> I can't use ${maven.repo.local} parameter inside settings.xml file. The
> parameter is simply ignored.
>
> c:\base_repo_location
>
>
> my-profile
>
>
> C:\alternative_repo_location
>
>
>
>
> When I run
> "mvn -P my-profile package"
> all downloaded artifacts are stored under "c:\base_repo_location" not
> "C:\alternative_repo_location".
> When I run
> "mvn -Dmaven.repo.local=C:\alternative_repo_location package" package
> artifacts are stored under "C:\alternative_repo_location" as I expected.
--
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: (MANTRUN-75) tasks if or unless does not work properly
[
http://jira.codehaus.org/browse/MANTRUN-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138493#action_138493
]
Teemu Lehto commented on MANTRUN-75:
Is it possible to rebuild plugin with ant 1.7.0 (see Carl's attachment) and
release minor version (1.1.1 or something) ? I work for organization that will
not allow changes to existing packages or plugins etc.
> tasks if or unless does not work properly
> --
>
> Key: MANTRUN-75
> URL: http://jira.codehaus.org/browse/MANTRUN-75
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
> Environment: Win XP ( CYGWIN) JDK 1.5 update 7
>Reporter: Alan Mehio
> Attachments: mantrun-75.diff
>
>
> the below
>
>
>
> does not work from the example at
> http://maven.apache.org/plugins/maven-antrun-plugin/examples/tasksAttributes.html
> The complete POM file ; please see below
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://vmaven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> mygr
> myartifact
> pom
> 1.1.0
> myartifact
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
>
> true
>
> ./
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> commons-net
>
> commons-net
> 1.4.1
>
>
> ant
>
> ant-commons-net
> 1.6.5
>
>
>
>
> install
> install
>
>unless="maven.test.skip">
>
> message="To skip me, just call mvn -Dmaven.test.skip=true" />
>
> message="Alan Mehio ---: project.build.finalName: ${basedir}/build.xml" />
>
>
>
> run
>
>
>
>
>
>
>
> the command I run is
> mvn clean install -Dmaven.test.skip=true
> it did not skip the "tasks" and it always go through the tasks
> I use the "if" attribute and it does not do any check for the property; it
> passes the validation eventhougth the property is not set
>
>
>
> it passes the check (if condition) event the property
> "maven.project.alan.mehio.does.not.exit" does not exist
> Regards,
> Alan Mehio
> London, UK
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org
[jira] Commented: (MNG-3510) download with http 403 status code assumed by maven to be OK, then checksum failed error
[
http://jira.codehaus.org/browse/MNG-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138492#action_138492
]
Brett Porter commented on MNG-3510:
---
fwiw, the repository I set up also returns the HTML page (using ErrorDocument
on apache).
> download with http 403 status code assumed by maven to be OK, then checksum
> failed error
>
>
> Key: MNG-3510
> URL: http://jira.codehaus.org/browse/MNG-3510
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
> Environment: Win xp pro., JDK6, mvn 2.0.6, netbeans 6, mevenide
> plugin in netbeans.
>Reporter: Bruce Chapman
>Priority: Minor
>
> Our firewall/cache is blocking access to
> http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar becuase it
> thinks it has a virus (that's the not the problem)
> {{$ wget http://repo1.maven.org/maven2/javax/mail/mail
> --14:13:46-- http://repo1.maven.org/maven2/javax/mail/mail
>=> `mail'
> Resolving cache... done.
> Connecting to cache[172.30.41.11]:8080... connected.
> Proxy request sent, awaiting response... 403 Forbidden
> 14:13:47 ERROR 403: Forbidden.}}
> but the firewall also returns content for the browser
> {{
> CONTENT="no-cache"> http-equiv="Content-Type" content="text/html; charset=UTF-8">SonicWALL
> - Blocked by Application Firewall text=#FF> width=500 bgcolor=#9CBACE> cellpadding=5 width=450> color=00 size=4>This request is blocked by the SonicWALL Gateway
> Anti-Virus Service. Name: WMF.Gen-2
> (Exploit)
> }}
> The problem is that maven is ignoring the status code, goes ahead and
> downloads the file then decides that the checksum for the content does not
> match what is expected. This is misleading and makes it more difficult to
> diagnose the cause of the failed download.
> Here is what maven does
> {{
>
> Building Hudson core
>task-segment: [install]
>
> Maven Version: 2.0.6
> JDK Version: 1.6.0_05 normalized as: 1.6.0-5
> OS Info: Arch: x86 Family: windows Name: windows xp Version: 5.1
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.pom
> 993/993b
> 993b downloaded
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'e0bb0f663e436cde3a6e1e5b8e8e80be43bde8a3'; remote =
> '1aa1579ae5ecd41920c4f355b0a9ef40b68315dd' - RETRYING
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> }}
> Maven should only go on and download the file and compare checksums if the
> http status is valid eg 200, in the case of a failing http status code, it
> would be much more useful if maven failed earlier with the status code and
> text as the error message.
--
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-3510) download with http 403 status code assumed by maven to be OK, then checksum failed error
[
http://jira.codehaus.org/browse/MNG-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138490#action_138490
]
Bruce Chapman commented on MNG-3510:
if the server just returns 403 with no content in the response I guess maven
doesn't see the content.
I suspect the problem occured because the server returned 403 status AND also
returned content (an HTML page explaining the fact that the firewall thought
the jar file contained a virus). This is permitted under http, but may not be
normal.
The http reply contains the text "This request is blocked by the SonicWALL
Gateway Anti-Virus Service", I wonder if sonic wall have a public proxy that
does this? (ours is in our infrastructure so that can't help you).
Sorry I've gotta rush, and won't be able to respond for around 3 days.
cheers
> download with http 403 status code assumed by maven to be OK, then checksum
> failed error
>
>
> Key: MNG-3510
> URL: http://jira.codehaus.org/browse/MNG-3510
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
> Environment: Win xp pro., JDK6, mvn 2.0.6, netbeans 6, mevenide
> plugin in netbeans.
>Reporter: Bruce Chapman
>Priority: Minor
>
> Our firewall/cache is blocking access to
> http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar becuase it
> thinks it has a virus (that's the not the problem)
> {{$ wget http://repo1.maven.org/maven2/javax/mail/mail
> --14:13:46-- http://repo1.maven.org/maven2/javax/mail/mail
>=> `mail'
> Resolving cache... done.
> Connecting to cache[172.30.41.11]:8080... connected.
> Proxy request sent, awaiting response... 403 Forbidden
> 14:13:47 ERROR 403: Forbidden.}}
> but the firewall also returns content for the browser
> {{
> CONTENT="no-cache"> http-equiv="Content-Type" content="text/html; charset=UTF-8">SonicWALL
> - Blocked by Application Firewall text=#FF> width=500 bgcolor=#9CBACE> cellpadding=5 width=450> color=00 size=4>This request is blocked by the SonicWALL Gateway
> Anti-Virus Service. Name: WMF.Gen-2
> (Exploit)
> }}
> The problem is that maven is ignoring the status code, goes ahead and
> downloads the file then decides that the checksum for the content does not
> match what is expected. This is misleading and makes it more difficult to
> diagnose the cause of the failed download.
> Here is what maven does
> {{
>
> Building Hudson core
>task-segment: [install]
>
> Maven Version: 2.0.6
> JDK Version: 1.6.0_05 normalized as: 1.6.0-5
> OS Info: Arch: x86 Family: windows Name: windows xp Version: 5.1
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.pom
> 993/993b
> 993b downloaded
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'e0bb0f663e436cde3a6e1e5b8e8e80be43bde8a3'; remote =
> '1aa1579ae5ecd41920c4f355b0a9ef40b68315dd' - RETRYING
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> }}
> Maven should only go on and download the file and compare checksums if the
> http status is valid eg 200, in the case of a failing http status code, it
> would be much more useful if maven failed earlier with the status code and
> text as the error message.
--
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-3510) download with http 403 status code assumed by maven to be OK, then checksum failed error
[
http://jira.codehaus.org/browse/MNG-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138486#action_138486
]
Brett Porter commented on MNG-3510:
---
I haven't set up a cache or web proxy server, but if I point directly at a
repository that returns 403 I receive the expected result. Do you know of any
public proxy server that exhibits this behaviour?
> download with http 403 status code assumed by maven to be OK, then checksum
> failed error
>
>
> Key: MNG-3510
> URL: http://jira.codehaus.org/browse/MNG-3510
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
> Environment: Win xp pro., JDK6, mvn 2.0.6, netbeans 6, mevenide
> plugin in netbeans.
>Reporter: Bruce Chapman
>Priority: Minor
>
> Our firewall/cache is blocking access to
> http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar becuase it
> thinks it has a virus (that's the not the problem)
> {{$ wget http://repo1.maven.org/maven2/javax/mail/mail
> --14:13:46-- http://repo1.maven.org/maven2/javax/mail/mail
>=> `mail'
> Resolving cache... done.
> Connecting to cache[172.30.41.11]:8080... connected.
> Proxy request sent, awaiting response... 403 Forbidden
> 14:13:47 ERROR 403: Forbidden.}}
> but the firewall also returns content for the browser
> {{
> CONTENT="no-cache"> http-equiv="Content-Type" content="text/html; charset=UTF-8">SonicWALL
> - Blocked by Application Firewall text=#FF> width=500 bgcolor=#9CBACE> cellpadding=5 width=450> color=00 size=4>This request is blocked by the SonicWALL Gateway
> Anti-Virus Service. Name: WMF.Gen-2
> (Exploit)
> }}
> The problem is that maven is ignoring the status code, goes ahead and
> downloads the file then decides that the checksum for the content does not
> match what is expected. This is misleading and makes it more difficult to
> diagnose the cause of the failed download.
> Here is what maven does
> {{
>
> Building Hudson core
>task-segment: [install]
>
> Maven Version: 2.0.6
> JDK Version: 1.6.0_05 normalized as: 1.6.0-5
> OS Info: Arch: x86 Family: windows Name: windows xp Version: 5.1
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.pom
> 993/993b
> 993b downloaded
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'e0bb0f663e436cde3a6e1e5b8e8e80be43bde8a3'; remote =
> '1aa1579ae5ecd41920c4f355b0a9ef40b68315dd' - RETRYING
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> }}
> Maven should only go on and download the file and compare checksums if the
> http status is valid eg 200, in the case of a failing http status code, it
> would be much more useful if maven failed earlier with the status code and
> text as the error message.
--
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-3434) [regression] Integration test it0103 is broken
[ http://jira.codehaus.org/browse/MNG-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3434. - Assignee: Brett Porter Resolution: Fixed working now > [regression] Integration test it0103 is broken > -- > > Key: MNG-3434 > URL: http://jira.codehaus.org/browse/MNG-3434 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1-alpha-1 > > > This is currently being demonstrated locally and in Continuum. > The error starts with: > org.apache.maven.it.VerificationException: Exit code > was non-zero: 1; log = > + Error stacktraces are turned on. > WAGON_VERSION: 1.0-beta-2 > url = http://repo1.maven.org/maven2 > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/its/it0103/level1/1/level1-1.pom > [ERROR] > Failed to resolve parent-POM from repository. > Parent POM Information: > Group-Id: org.apache.maven.its.it0103 > Artifact-Id: level1 > Version: 1 > Local Repository: /export/home/build/.m2/repository > Remote Repositories: > central -& http://repo1.maven.org/maven2 > Reason: Unable to download the artifact from any repository > org.apache.maven.its.it0103:level1:pom:1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > Project Id: [inherited]:level3:jar:1 > From file: /var/tmp/it0103/level1/level2/level3/pom.xml > Error stacktrace: > org.apache.maven.reactor.MavenExecutionException: Error scanning for > extensions: Error building model lineage in order to pre-scan for extensions: > Cannot find artifact for parent POM: org.apache.maven.its.it0103:level1::1 > for project [inherited]:level3:jar:1 at > /var/tmp/it0103/level1/level2/level3/pom.xml > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:281) > at > org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:105) > at > org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:162) > at > org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) > at > org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:895) > at > org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) > at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.extension.ExtensionScanningException: Error > building model lineage in order to pre-scan for extensions: Cannot find > artifact for parent POM: org.apache.maven.its.it0103:level1::1 for project > [inherited]:level3:jar:1 at /var/tmp/it0103/level1/level2/level3/pom.xml > at > org.apache.maven.extension.DefaultBuildExtensionScanner.buildModelLineage(DefaultBuildExtensionScanner.java:428) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:136) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:106) > at org.apach
[jira] Closed: (MNG-3432) [regression] Integration test it0042 is broken
[ http://jira.codehaus.org/browse/MNG-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3432. - Assignee: Brett Porter Resolution: Fixed working now > [regression] Integration test it0042 is broken > -- > > Key: MNG-3432 > URL: http://jira.codehaus.org/browse/MNG-3432 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1-alpha-1 > > > This is currently being demonstrated locally and in Continuum. > The error starts with: > junit.framework.AssertionFailedError: Expected file was > not found: /var/tmp/it0042/test-component-c/target/my-test -- 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-3625) revisit it0026
revisit it0026 -- Key: MNG-3625 URL: http://jira.codehaus.org/browse/MNG-3625 Project: Maven 2 Issue Type: Bug Components: Settings Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 this integration test was disabled, presumably because of the removal of the system properties for settings. We still want to test that merging works however, so look for alternate methods of support. Also document the removal of the above settings -- 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-3625) revisit it0026
[ http://jira.codehaus.org/browse/MNG-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3625: -- Fix Version/s: 2.1-alpha-1 > revisit it0026 > -- > > Key: MNG-3625 > URL: http://jira.codehaus.org/browse/MNG-3625 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > this integration test was disabled, presumably because of the removal of the > system properties for settings. > We still want to test that merging works however, so look for alternate > methods of support. > Also document the removal of the above settings -- 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-3510) download with http 403 status code assumed by maven to be OK, then checksum failed error
[
http://jira.codehaus.org/browse/MNG-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138483#action_138483
]
Bruce Chapman commented on MNG-3510:
Brett,
No, I am not getting a 403 from the repo, I am getting it from our local
cache/firewall.
I only used wget to show what the firewall was returning in order to put some
evidence in this report.
To reproduce set up a cache or web proxy server between your test and the
actual maven repository. Have the cache/proxy return status 403 AND a document
(such as the html supplied in this fault report) when asked for a particular
jar file.
Attempt to load that jar via maven, maven will treat the returned html error
page as if it were the jar file, and save it locally in the repository cache
thingy (can't remember what maven calls it), maven will ignore the 403 status
code, maven will then blow up later saying checksums fail.
To repeat the core problem from the initial fault description...
Maven should only go on and download the file and compare checksums if the http
status is valid eg 200, in the case of a failing http status code, it would be
much more useful if maven failed earlier with the status code and text as the
error message.
... and I'll add...
without saving the "document from the failing http response" in the local maven
cache/repository.
Bruce
> download with http 403 status code assumed by maven to be OK, then checksum
> failed error
>
>
> Key: MNG-3510
> URL: http://jira.codehaus.org/browse/MNG-3510
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
> Environment: Win xp pro., JDK6, mvn 2.0.6, netbeans 6, mevenide
> plugin in netbeans.
>Reporter: Bruce Chapman
>Priority: Minor
>
> Our firewall/cache is blocking access to
> http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar becuase it
> thinks it has a virus (that's the not the problem)
> {{$ wget http://repo1.maven.org/maven2/javax/mail/mail
> --14:13:46-- http://repo1.maven.org/maven2/javax/mail/mail
>=> `mail'
> Resolving cache... done.
> Connecting to cache[172.30.41.11]:8080... connected.
> Proxy request sent, awaiting response... 403 Forbidden
> 14:13:47 ERROR 403: Forbidden.}}
> but the firewall also returns content for the browser
> {{
> CONTENT="no-cache"> http-equiv="Content-Type" content="text/html; charset=UTF-8">SonicWALL
> - Blocked by Application Firewall text=#FF> width=500 bgcolor=#9CBACE> cellpadding=5 width=450> color=00 size=4>This request is blocked by the SonicWALL Gateway
> Anti-Virus Service. Name: WMF.Gen-2
> (Exploit)
> }}
> The problem is that maven is ignoring the status code, goes ahead and
> downloads the file then decides that the checksum for the content does not
> match what is expected. This is misleading and makes it more difficult to
> diagnose the cause of the failed download.
> Here is what maven does
> {{
>
> Building Hudson core
>task-segment: [install]
>
> Maven Version: 2.0.6
> JDK Version: 1.6.0_05 normalized as: 1.6.0-5
> OS Info: Arch: x86 Family: windows Name: windows xp Version: 5.1
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.pom
> 993/993b
> 993b downloaded
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'e0bb0f663e436cde3a6e1e5b8e8e80be43bde8a3'; remote =
> '1aa1579ae5ecd41920c4f355b0a9ef40b68315dd' - RETRYING
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> }}
> Maven should only go on and download the file and compare checksums if the
> http status is valid eg 200, in the case of a failing http status code, it
> would be much more useful if maven failed earlier with the status code and
> text as the error message.
--
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-3281) revisit backwards compat of extensions in 2.1 (IT 0114)
[ http://jira.codehaus.org/browse/MNG-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138482#action_138482 ] Brett Porter commented on MNG-3281: --- also affected: 111, mng3485 > revisit backwards compat of extensions in 2.1 (IT 0114) > --- > > Key: MNG-3281 > URL: http://jira.codehaus.org/browse/MNG-3281 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > currently, it 0114 doesn't pass due to the removal of extension support > we need to either: > - restore some form of backwards compat by loading the extension into the > expected place > - provide a graceful failure instead -- 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-3624) release plexus-interpolation 1.0-SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3624: -- Fix Version/s: 2.1-alpha-1 > release plexus-interpolation 1.0-SNAPSHOT > - > > Key: MNG-3624 > URL: http://jira.codehaus.org/browse/MNG-3624 > Project: Maven 2 > Issue Type: Task > Components: Bootstrap & Build >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > -- 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-3624) release plexus-interpolation 1.0-SNAPSHOT
release plexus-interpolation 1.0-SNAPSHOT - Key: MNG-3624 URL: http://jira.codehaus.org/browse/MNG-3624 Project: Maven 2 Issue Type: Task Components: Bootstrap & Build Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 -- 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: (MARTIFACT-5) non-handling of legacy repositories needs to be more graceful
[ http://jira.codehaus.org/browse/MARTIFACT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138481#action_138481 ] Brett Porter commented on MARTIFACT-5: -- additionally, we should document this in the release notes, and also write a guide on how to convert the repository format, or install a repository manager. > non-handling of legacy repositories needs to be more graceful > - > > Key: MARTIFACT-5 > URL: http://jira.codehaus.org/browse/MARTIFACT-5 > Project: Maven Artifact > Issue Type: Bug >Reporter: Brett Porter > Fix For: 3.0-alpha-1 > > > legacy repository support was removed. > Currently, it appears to still partially handle it - using 2.1-SNAPHOT today > it requests groupId/types/artifactId-version.ext as before, but chokes on the > non-existence of a POM in the desired format. > If this support is to be removed, it should be removed completely, and legacy > repositories should be ignored in the repository list, with a warning > presented so that it sohuld either resolve from an alternate repository, or > present as an artifact not found exception. -- 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: (MRELEASE-356) depreate the automated release profile
depreate the automated release profile -- Key: MRELEASE-356 URL: http://jira.codehaus.org/browse/MRELEASE-356 Project: Maven 2.x Release Plugin Issue Type: Task Reporter: Brett Porter the release profile is being removed from the super POM in Maven 2.1-alpha-1, so the release plugin should pre-emptively start ensuring users do this themselves -- 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-3623) [regression] it0081 and it0065 fail since the xbean migration
[ http://jira.codehaus.org/browse/MNG-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3623: -- Fix Version/s: 2.1-alpha-1 > [regression] it0081 and it0065 fail since the xbean migration > - > > Key: MNG-3623 > URL: http://jira.codehaus.org/browse/MNG-3623 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > both contain errors similar to: > Caused by: org.apache.xbean.recipe.ConstructionException: Type class could > not be found: org.apache.maven.plugin.coreit.TestBasedirMojo > at org.apache.xbean.recipe.ObjectRecipe.getType(ObjectRecipe.java:351) > at > org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:262) > at > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) > at > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) > at > org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49) > at > org.codehaus.plexus.component.builder.XBeanComponentBuilder.createComponentInstance(XBeanComponentBuilder.java:122) > ... 28 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3623) [regression] it0081 and it0065 fail since the xbean migration
[regression] it0081 and it0065 fail since the xbean migration - Key: MNG-3623 URL: http://jira.codehaus.org/browse/MNG-3623 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 both contain errors similar to: Caused by: org.apache.xbean.recipe.ConstructionException: Type class could not be found: org.apache.maven.plugin.coreit.TestBasedirMojo at org.apache.xbean.recipe.ObjectRecipe.getType(ObjectRecipe.java:351) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:262) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49) at org.codehaus.plexus.component.builder.XBeanComponentBuilder.createComponentInstance(XBeanComponentBuilder.java:122) ... 28 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MARTIFACT-4) allow wildcards and versions in In/ExcludesArtifactFilter
[ http://jira.codehaus.org/browse/MARTIFACT-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-4: - Fix Version/s: (was: 3.0-alpha-1) 3.0 I don't need this for the first release > allow wildcards and versions in In/ExcludesArtifactFilter > - > > Key: MARTIFACT-4 > URL: http://jira.codehaus.org/browse/MARTIFACT-4 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Brett Porter > Fix For: 3.0 > > -- 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-3550) Support more prerequisites like compiler version
[
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3550.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.1-alpha-1)
seems toolchains will address this?
> Support more prerequisites like compiler version
>
>
> Key: MNG-3550
> URL: http://jira.codehaus.org/browse/MNG-3550
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: Vincent Siveton
>Priority: Minor
>
> It should be useful if the tag could support more
> informations than the maven version. I could imagine something like:
> {noformat}
>
> ...
>
> 2.0.6
> 1.5
> 512m
> 100m
>
> ...
>
> {noformat}
> See the concrete use case in the Maven Plugin Plugin report:
> http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html
--
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-3567) pluginManagement from parent POM not used in child
[ http://jira.codehaus.org/browse/MNG-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138478#action_138478 ] Brett Porter commented on MNG-3567: --- is this a regression from 2.0.9? > pluginManagement from parent POM not used in child > -- > > Key: MNG-3567 > URL: http://jira.codehaus.org/browse/MNG-3567 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1-alpha-1 > > -- 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
issues@maven.apache.org
[
http://jira.codehaus.org/browse/MNG-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3492:
--
Fix Version/s: (was: 2.1-alpha-1)
2.1
> File.deleteOnExit not enough for embedder&CI
>
>
> Key: MNG-3492
> URL: http://jira.codehaus.org/browse/MNG-3492
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.7
>Reporter: Kohsuke Kawaguchi
> Fix For: 2.1
>
>
> When Maven is used in another long-running process (in this case Hudson),
> File.deleteOnExit() is not run early enough, so we end up accumulating insane
> amount of temporary files. DefaultWagonManager in particular does that a lot,
> even though (at least in some cases) the file could have been deleted
> explicitly.
> For example, in the putRemoteFile method, the code reads as follows,
> {noformat}
> // We do this in here so we can checksum the artifact metadata
> too, otherwise it could be metadata itself
> for ( Iterator i = checksums.keySet().iterator(); i.hasNext(); )
> {
> String extension = (String) i.next();
> // TODO: shouldn't need a file intermediatary - improve wagon
> to take a stream
> File temp = File.createTempFile( "maven-artifact", null );
> temp.deleteOnExit();
> FileUtils.fileWrite( temp.getAbsolutePath(), (String)
> sums.get( extension ) );
> wagon.put( temp, remotePath + "." + extension );
> }
> {noformat}
> ... butI don't see why the temporary file cannot be deleted after the put
> method, or at least at the end of the method, after the Wagon component is
> released.
--
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-3038) Transitive DepMan not working (per MNG-1577) [use case attached]
[
http://jira.codehaus.org/browse/MNG-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3038:
--
Fix Version/s: (was: 2.1-alpha-1)
2.1
> Transitive DepMan not working (per MNG-1577) [use case attached]
>
>
> Key: MNG-3038
> URL: http://jira.codehaus.org/browse/MNG-3038
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.5, 2.0.6
>Reporter: Joakim Erdfelt
>Assignee: Patrick Schneider
> Fix For: 2.1
>
> Attachments: carlos_transitive_version.tar.gz
>
>
> When working with the example use case described by Carlos on the MNG-1577
> thread.
> http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
> {noformat}
> What about this use case for transitive dependencyManagement? has been tested?
> A -> B -> C -> D
> C depends on D 1.0
> B has D 2.0 in dependencyManagement, no D in dependencies
> A should get D 2.0
> {noformat}
> It was discovered that this does not work.
> Sample Project / Use Case is attached. (655 bytes)
--
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-3412) State of Maven Embedder and documentation
[ http://jira.codehaus.org/browse/MNG-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3412: -- Fix Version/s: (was: 2.1-alpha-1) 2.1 > State of Maven Embedder and documentation > - > > Key: MNG-3412 > URL: http://jira.codehaus.org/browse/MNG-3412 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Dimitry Voytenko > Fix For: 2.1 > > > Is Meven Embedder project still alive? The documentation in > http://maven.apache.org/guides/mini/guide-embedding-m2.html doesn't match > org.apache.maven/maven-embedder artifact at all (I tried against 2.0.4 > version). -- 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-3544) Beautify debug output for mojo parameters of type array
[
http://jira.codehaus.org/browse/MNG-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3544:
--
Fix Version/s: 2.0.x
> Beautify debug output for mojo parameters of type array
> ---
>
> Key: MNG-3544
> URL: http://jira.codehaus.org/browse/MNG-3544
> Project: Maven 2
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.0.9
>Reporter: Benjamin Bentmann
>Priority: Trivial
> Fix For: 2.0.x
>
> Attachments: debug-mojo-array-params.patch
>
>
> Currently:
> {noformat}
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar'
> -->
> [DEBUG] (f) excludes = [Ljava.lang.String;@c3c315
> [DEBUG] -- end configuration --
> {noformat}
> i.e. arrays won't show up nicely.
> The attached patch returns a string similar to the result of
> {code:java}
> Arrays.asList( (Object[]) value ).toString()
> {code}
> but uses reflection to handle arrays of primitives as well.
--
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-3529) mvn -Da=" " throws an excepltion
[ http://jira.codehaus.org/browse/MNG-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3529: -- Fix Version/s: 2.0.x > mvn -Da=" " throws an excepltion > > > Key: MNG-3529 > URL: http://jira.codehaus.org/browse/MNG-3529 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.8 >Reporter: Sean Bridges >Priority: Trivial > Fix For: 2.0.x > > > Doing, > mvn -Da=" " > throws, > --- > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at > java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:146) > at java.lang.StringBuffer.setLength(StringBuffer.java:154) > at > org.apache.maven.cli.MavenCli$CLIManager.cleanArgs(MavenCli.java:793) > at org.apache.maven.cli.MavenCli$CLIManager.parse(MavenCli.java:746) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-3480) Extend unit test for DefaultMavenProjectBuilder to check inheritance from super POM
[ http://jira.codehaus.org/browse/MNG-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3480: -- Fix Version/s: 2.0.x > Extend unit test for DefaultMavenProjectBuilder to check inheritance from > super POM > --- > > Key: MNG-3480 > URL: http://jira.codehaus.org/browse/MNG-3480 > Project: Maven 2 > Issue Type: Task > Components: POM >Reporter: Benjamin Bentmann >Priority: Trivial > Fix For: 2.0.x > > Attachments: project-builder-minimal-pom-test.patch > > > I originally wanted to create a unit test to trigger the failures Brian > mentioned in MNG-3478. I ended up with a test that doesn't fail as expected > but it might be useful nevertheless. -- 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-3451) Add german translation
[ http://jira.codehaus.org/browse/MNG-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3451: -- Fix Version/s: 2.0.x > Add german translation > -- > > Key: MNG-3451 > URL: http://jira.codehaus.org/browse/MNG-3451 > Project: Maven 2 > Issue Type: Improvement > Components: Logging >Reporter: Benjamin Bentmann >Priority: Trivial > Fix For: 2.0.x > > Attachments: i18n-de.patch > > > There are some message files hanging around in maven-core that miss a german > edition. > However, I wonder whether these files are actually really used. I searched my > working copy and couldn't find any references to a key from the bundle or the > bundle name itself. If this is really unused stuff from ancient times, it > should better be completely deleted. -- 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-3510) download with http 403 status code assumed by maven to be OK, then checksum failed error
[
http://jira.codehaus.org/browse/MNG-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3510.
-
Resolution: Cannot Reproduce
> download with http 403 status code assumed by maven to be OK, then checksum
> failed error
>
>
> Key: MNG-3510
> URL: http://jira.codehaus.org/browse/MNG-3510
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
> Environment: Win xp pro., JDK6, mvn 2.0.6, netbeans 6, mevenide
> plugin in netbeans.
>Reporter: Bruce Chapman
>Priority: Minor
>
> Our firewall/cache is blocking access to
> http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar becuase it
> thinks it has a virus (that's the not the problem)
> {{$ wget http://repo1.maven.org/maven2/javax/mail/mail
> --14:13:46-- http://repo1.maven.org/maven2/javax/mail/mail
>=> `mail'
> Resolving cache... done.
> Connecting to cache[172.30.41.11]:8080... connected.
> Proxy request sent, awaiting response... 403 Forbidden
> 14:13:47 ERROR 403: Forbidden.}}
> but the firewall also returns content for the browser
> {{
> CONTENT="no-cache"> http-equiv="Content-Type" content="text/html; charset=UTF-8">SonicWALL
> - Blocked by Application Firewall text=#FF> width=500 bgcolor=#9CBACE> cellpadding=5 width=450> color=00 size=4>This request is blocked by the SonicWALL Gateway
> Anti-Virus Service. Name: WMF.Gen-2
> (Exploit)
> }}
> The problem is that maven is ignoring the status code, goes ahead and
> downloads the file then decides that the checksum for the content does not
> match what is expected. This is misleading and makes it more difficult to
> diagnose the cause of the failed download.
> Here is what maven does
> {{
>
> Building Hudson core
>task-segment: [install]
>
> Maven Version: 2.0.6
> JDK Version: 1.6.0_05 normalized as: 1.6.0-5
> OS Info: Arch: x86 Family: windows Name: windows xp Version: 5.1
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.pom
> 993/993b
> 993b downloaded
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'e0bb0f663e436cde3a6e1e5b8e8e80be43bde8a3'; remote =
> '1aa1579ae5ecd41920c4f355b0a9ef40b68315dd' - RETRYING
> Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.jar
> 696/?
> }}
> Maven should only go on and download the file and compare checksums if the
> http status is valid eg 200, in the case of a failing http status code, it
> would be much more useful if maven failed earlier with the status code and
> text as the error message.
--
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-3614) settings.xml active profiles executed AFTER project profiles have been loaded and activated/not activated
[ http://jira.codehaus.org/browse/MNG-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3614: -- Fix Version/s: 2.0.x > settings.xml active profiles executed AFTER project profiles have been loaded > and activated/not activated > - > > Key: MNG-3614 > URL: http://jira.codehaus.org/browse/MNG-3614 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Profiles, Settings >Affects Versions: 2.0.9 > Environment: Solaris 5.10, ubuntu hardy x64 >Reporter: Donald Abrams >Priority: Minor > Fix For: 2.0.x > > > If you have the following settings.xml in ~/.m2: > > > > > userSettings > > > > > true > > > > > userSettings > > > and another child pom.xml somewhere down the line has a profile with an > activation like this: > http://maven.apache.org/POM/4.0.0";> > 4.0.0 > > > with-something > > false > > someproperty > true > > > > > > During run-time, the profile with-something will load before userSettings. > This causes with-something to be incorrectly not activated (as the property > someproperty does not exist). This can be seen with mvn help:active-profiles. > I know why this is true, but it is non-intuitive and one would expect > settings.xml profiles to be loaded before anything else. -- 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-3343) Add new lifecylce mapping "maven-skin"
[ http://jira.codehaus.org/browse/MNG-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3343: -- Fix Version/s: 2.1 consider for 2.1 if at all > Add new lifecylce mapping "maven-skin" > -- > > Key: MNG-3343 > URL: http://jira.codehaus.org/browse/MNG-3343 > Project: Maven 2 > Issue Type: New Feature > Components: General >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 2.1 > > Attachments: new-lifecycle-mappings.patch > > > Currently, creating a custom skin for Maven is done by a project with > packaging "jar". The attached patch intents to introduce an individual > lifecycle mapping named "maven-skin" for this purpose. > Why that? I consider the re-usage of the "jar" packaging an abuse for the > case of building a Maven skin. On the one hand, the "jar" packaging does too > much. Skins usually do not get compiled or unit-tested, do they? Since any > unused plugin invocation is an unnecessary risk of a build failure (sorry to > say), I would appreciate a lifecycle mapping that is not overdressed. On the > other hand, I could image that skins required some additional processing some > day like a check whether all required images are present in the skin or > whether the CSS references unknown IDs/names. Having a distinct lifecylcle > mapping in the Maven Core would allow for a central definition of the build > steps instead of requiring all users to extend the "jar" packaging. > Especially for the first reason, i.e. having a packaging that does not more > than required, the patch also defines a "resources" packaging. Such a > packaging is intended for JARs that just contain resources one wants to share > with other projects like rulesets for PMD, Checkstyle, etc. The lifecylcle > mappings "resources" and "maven-skin" are identiical (now) but I consider it > a bad practice to merge different use-cases just because they happen to be > equal by coindicence. -- 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-3589) multi level multi module build with cyclic references does not work
[ http://jira.codehaus.org/browse/MNG-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3589. - Resolution: Not A Bug > multi level multi module build with cyclic references does not work > --- > > Key: MNG-3589 > URL: http://jira.codehaus.org/browse/MNG-3589 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Reporter: Ulli Adrion >Assignee: Brian Fox >Priority: Minor > > Our main project consists of 3 multi modules projects m1, m2 and m3 > m1 is a multi module project which contains again several projects. > There is a cyclic reference in m1 (only for test cases) which we solved with > the dependency tag test: > A --> B --> only for test cases C --> A > If we build m1 separately it works. > If we want to build our main project it aborts with "The projects in the > reactor contain a cyclic reference" with the cycle shown above. -- 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-3604) when team member installs after deploy, snapshot is not updated
[ http://jira.codehaus.org/browse/MNG-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3604. - Resolution: Won't Fix it uses the metadata in the local repository. the current defined behaviour is to honour manually installed artifacts, unless the remote one is newer. i believe there is an open issue to review this for the future already, but for now it is by design. > when team member installs after deploy, snapshot is not updated > --- > > Key: MNG-3604 > URL: http://jira.codehaus.org/browse/MNG-3604 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.x > Environment: Win XP >Reporter: bartvdc >Priority: Minor > > I deployed a project A with a snapshot version and a team member did not get > the update when he builds another project B that has this project A as > dependency, not even with -U . We found out that it was because he did an > install of the same project A after I deployed it. He had not changed > anything, so the version part did not change. > On the repo we had a -20080516... and in his local repo there was a > -20080514... file. > Apparently Maven does not look at the file names(the -20080516... part) but > keeps the install time elsewhere. > If the deployed file comes before the the install time, no update is done. > The project must be deleted in his local repo to get the latest version. -- 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-3588) ${maven.repo.local} in settings.xml doesn't work.
[
http://jira.codehaus.org/browse/MNG-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3588:
--
Fix Version/s: 2.0.x
is this a regression? does settings.localRepository work?
> ${maven.repo.local} in settings.xml doesn't work.
> -
>
> Key: MNG-3588
> URL: http://jira.codehaus.org/browse/MNG-3588
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Marcin Kuthan
>Priority: Minor
> Fix For: 2.0.x
>
>
> I can't use ${maven.repo.local} parameter inside settings.xml file. The
> parameter is simply ignored.
>
> c:\base_repo_location
>
>
> my-profile
>
>
> C:\alternative_repo_location
>
>
>
>
> When I run
> "mvn -P my-profile package"
> all downloaded artifacts are stored under "c:\base_repo_location" not
> "C:\alternative_repo_location".
> When I run
> "mvn -Dmaven.repo.local=C:\alternative_repo_location package" package
> artifacts are stored under "C:\alternative_repo_location" as I expected.
--
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-3471) NullPointerException when version ranges overlap on snapshot.
[ http://jira.codehaus.org/browse/MNG-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3471: -- Fix Version/s: 2.0.x > NullPointerException when version ranges overlap on snapshot. > - > > Key: MNG-3471 > URL: http://jira.codehaus.org/browse/MNG-3471 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Errors >Affects Versions: 2.0.8 >Reporter: Scott Myron >Priority: Minor > Fix For: 2.0.x > > Attachments: projects.zip > > > I have 2 projects that have conflicting dependency definitions of the same > artifact (in the attached demo, project 'a' and 'b'). Project 'a' has a > dependency on project 'c' with the version range [1,2). However, project > 'b''s dependency on 'c' is specified with version [2.0.0-SNAPSHOT,3). Project > 'b' also has a dependency on 'a'. The different version ranges were a bug on > my part, they should have been the same. However, it causes the following > issue. When I try to run "mvn dependency:analyze" or "mvn eclipse:eclipse" > (or probably any maven command which resolves the dependencies of project > 'b'. I get the following exception: > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:199) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:76) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:543) > at > org.apache.maven.plugin.eclipse.EclipsePlugin.doDependencyResolution(EclipsePlugin.java:1526) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:490) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > To reproduce: > 1. Download the attached zip and extract it. > 2. Run 'mvn install' on 'c-1.0.0' > 3. Run 'mvn install' on 'c-2.0.0' > 4. Run 'mvn install' on 'a' > 5. Try running 'mvn eclipse:eclipse" or "mvn dependency:analyze" on 'b'. > <--- You should receive the exception here. -- 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-3549) Integration Test Executor Fails to Find Maven Distribution
[
http://jira.codehaus.org/browse/MNG-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3549.
-
Resolution: Fixed
already fixed
> Integration Test Executor Fails to Find Maven Distribution
> --
>
> Key: MNG-3549
> URL: http://jira.codehaus.org/browse/MNG-3549
> Project: Maven 2
> Issue Type: Bug
> Components: integration tests
>Affects Versions: 2.0.x
>Reporter: Shane Isbell
>Priority: Minor
> Attachments: dist.patch
>
>
> maven-core-it-runner has a dependency on apache-maven-${version}.tar.gz. But
> maven-distribution is packaging as maven-distribution-${version}.tar.gz. On a
> clean build, IT tests will fail to build due to missing artifacts. On other
> builds, IT tests will test older versions of the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3547) Profiling patch to display times of individual project/goal executions.
[ http://jira.codehaus.org/browse/MNG-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3547: -- Fix Version/s: 2.0.10 > Profiling patch to display times of individual project/goal executions. > --- > > Key: MNG-3547 > URL: http://jira.codehaus.org/browse/MNG-3547 > Project: Maven 2 > Issue Type: Improvement > Components: Performance >Affects Versions: 2.0.9 > Environment: Maven 2.0.9 >Reporter: David Bernhard >Priority: Minor > Fix For: 2.0.10 > > Attachments: maven-profiler.patch > > > We have a maven project that takes about 10 minutes to build from the root > pom. To analyze which parts of the build are the most time-intensive, I wrote > a small profiling patch to maven 2.0.9. > Running "mvn --profile" outputs information for each project and each goal of > a plugin. > It would be nice to have such an option available by default in maven. -- 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-3454) processing a relocation erases requested version range
[
http://jira.codehaus.org/browse/MNG-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3454:
--
Fix Version/s: 2.0.x
> processing a relocation erases requested version range
> --
>
> Key: MNG-3454
> URL: http://jira.codehaus.org/browse/MNG-3454
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.5, 2.0.6, 2.0.7, 2.0.8
>Reporter: Brian Fox
>Priority: Minor
> Fix For: 2.0.x
>
> Attachments: MNG-2861.tar.gz, MNG-2861_broken.zip
>
>
> While fixing MNG-2861, I came across a weird scenario where the contents of
> the relocation can affect what happens. In 2861, the relocation did not
> specify a version, only a group id. However, if a version is specified, in
> MavenMetadataSource: 164 the versionRange is reset to the contents of the
> relocation.getVersion(). This effectively tosses out the requested range
> information. We only get here after selecting the version that has been
> relocated, but now we have a recommended version, which can cause a different
> version to be selected. See the two sample projects in MNG-2861 to see how
> the handling is different. (brett's version has the version in the relocation
> and thus expresses the behavior described here)
> The fix is simple, change the line to:
> if ( relocation.getVersion() != null )
> {
> //we don't want to blast the versionRange
> information
> artifact.selectVersion( relocation.getVersion() );
> }
> however, I'm not certain what the ramifications of this are. The potential
> exists for having selected a version that no longer matches the requested
> version range. Say the version range was [1.0,2.0] and 2.0 was relocated to
> 3.0. The fix to 2861 involves reloading the available versions from the
> relocated artifact. This means that there is no not an artifact to match
> 1.0-2.0 and who knows what's going to happen.
> I'm choosing to document this and not fix it for now due to the risk of
> instability. A search of open issues didn't result in anyone experiencing
> trouble with this.
--
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-3528) Order of executing plugins in maven 2.0.9
[
http://jira.codehaus.org/browse/MNG-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3528.
-
Assignee: Brett Porter
Resolution: Duplicate
> Order of executing plugins in maven 2.0.9
> -
>
> Key: MNG-3528
> URL: http://jira.codehaus.org/browse/MNG-3528
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.9
> Environment: Maven 2.0.9
>Reporter: David Bernhard
>Assignee: Brett Porter
>Priority: Minor
> Attachments: 209test.zip
>
>
> Suppose you include a plugin like this:
>
> my.bug.test
> plugin
> 1.0
>
>
> first
> compile
>
> first
>
>
>
>
>
> my.bug.test
> plugin
> 1.0
>
>
> second
> compile
>
> second
>
>
>
>
> Then SECOND will execute before FIRST. The reason is in
> ModelUtils.java:MergePluginDefinitions the new definition is passed as parent
> and the old as child - and the parent comes first in the merged executions.
> However, this works correctly:
>
> my.bug.test
> plugin
> 1.0
>
>
> both
> test
>
> first
> second
>
>
>
>
> I have included a tiny test case that demonstrates this. Here's my output:
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [:second {execution: second}]
> SECOND
> [INFO] [:first {execution: first}]
> FIRST
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [:first {execution: both}]
> FIRST
> [INFO] [:second {execution: both}]
> SECOND
--
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-3539) Report plugins with inherited=false dropped by profile injector
[
http://jira.codehaus.org/browse/MNG-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3539:
--
Fix Version/s: 2.0.x
> Report plugins with inherited=false dropped by profile injector
> ---
>
> Key: MNG-3539
> URL: http://jira.codehaus.org/browse/MNG-3539
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Profiles
>Affects Versions: 2.0.9
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.0.x
>
> Attachments: MNG-3539.patch, reporting-profile-merge.patch
>
>
> Consider the following POM snippet:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.3
> false
>
>
>
>
>
> extended-site
>
> ... some other plugins but excluding the surefire-report-plugin
>
>
>
> {code}
> When running "mvn site -P extended-site", the Surefire Report Plugin will be
> excluded from the site output.
> For some reason, the {{DefaultProfileInjector}} is dropping plugins which
> have {{inherited=false}}. Inheritance shouldn't matter here, it's all about
> the same POM, no parent-child play.
> Attached is a unit test to show the failure. An IT will follow now that I
> have the JIRA ticket.
--
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-3413) Allow plugins to be downloaded from standard repository
[ http://jira.codehaus.org/browse/MNG-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3413. - Assignee: Brett Porter Resolution: Won't Fix I think given we've removed plugin repositories in trunk, we have a satisfactory long term answer to this > Allow plugins to be downloaded from standard repository > --- > > Key: MNG-3413 > URL: http://jira.codehaus.org/browse/MNG-3413 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies, Plugins and Lifecycle, Settings >Reporter: Paul Gier >Assignee: Brett Porter >Priority: Minor > > I would like to be able to define a single repository either in settings.xml > or in my pom that can be used for downloading both project dependencies and > plugins. In many situations the regular repository and the plugin repository > are the same place, so it would be nice to be able to do something like this: > > snapshots.mydomain.com > My snapshot repository > http://snapshots.mydomain.com/ > > true > > > false > > > true > > > > This would allow me to download snapshots of both project dependencies and > plugins from the repository without needing to configure a separate plugin > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3462) Settings: Proceeding slash should be removed from URLs
[ http://jira.codehaus.org/browse/MNG-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3462: -- Fix Version/s: 2.0.x > Settings: Proceeding slash should be removed from URLs > -- > > Key: MNG-3462 > URL: http://jira.codehaus.org/browse/MNG-3462 > Project: Maven 2 > Issue Type: Improvement > Components: Bootstrap & Build, Settings >Affects Versions: 2.0.8 >Reporter: Paul Benedict >Priority: Minor > Fix For: 2.0.x > > > When repositories and mirrors have their URL end with a slash, you will see a > double-slash in the URL. > Example configuration: > > > mergere > central > Mergere > http://repo.mergere.com/maven2/ > > > Output: > mvn help:effective-pom > Downloading: > http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.pom > 1K downloaded > Downloading: > http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.jar > 19K downloaded -- 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-3278) classifiers in dependencyManagement don't work
[ http://jira.codehaus.org/browse/MNG-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3278. - Resolution: Not A Bug this is by design - the classifier is part of the coordinate. Management is for managing versions and scopes. > classifiers in dependencyManagement don't work > -- > > Key: MNG-3278 > URL: http://jira.codehaus.org/browse/MNG-3278 > Project: Maven 2 > Issue Type: Bug >Reporter: Paul Sundling >Priority: Minor > > parent pom: > > > > > net.sf.json-lib > json-lib > 2.1 > jdk15 > > > > > If child pom will pick up everything else like excludes, except the > classifier, so classifier has to be added for every child pom. > > > > net.sf.json-lib > json-lib > jdk15 > > > > Expected to work, but fails: > > > > net.sf.json-lib > json-lib > > > -- 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-3266) maven-model RepositoryBase overrides equals() but not hashCode()
[ http://jira.codehaus.org/browse/MNG-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3266: -- Fix Version/s: 2.0.x > maven-model RepositoryBase overrides equals() but not hashCode() > > > Key: MNG-3266 > URL: http://jira.codehaus.org/browse/MNG-3266 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: Jared Roberts >Priority: Minor > Fix For: 2.0.x > > Attachments: MNG-3266-maven-model-v2.patch, MNG-3266-maven-model.patch > > > Overriding equals and not hashCode is considered bad practice. Also, while > looking around, I noticed the two subclasses (Repository and > PluginRepository) both override equals and just call "super.equals()". There > is a cryptic comment nearby that leads me to believe this is a temporary fix > for an old problem. -- 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-3290) add the ability to exclude dependencies from a plugin
[ http://jira.codehaus.org/browse/MNG-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3290: -- Fix Version/s: 2.0.x didn't we add this already? > add the ability to exclude dependencies from a plugin > - > > Key: MNG-3290 > URL: http://jira.codehaus.org/browse/MNG-3290 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: nicolas de loof >Priority: Minor > Fix For: 2.0.x > > > As plugins declare theyre own dependencies, we sometime need to override the > plugin dependencies to use a != version of the supported tool. > In some situations, due to groupId beeing relocated, this is not possible : > example : the axistool mojo depends on org.apache.axis:axis:1.4. To generate > code for a previous version of axis, we cannot override this dependency as > older axis versions use groupId "axis". > same on the castor mojo : cannot use a newest org.codehaus.castor version as > the plugin depends on groupId "castor". -- 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-3457) Add Method to AbstractMojo for Obtaining Toolchain
[ http://jira.codehaus.org/browse/MNG-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3457: -- Fix Version/s: 2.1 > Add Method to AbstractMojo for Obtaining Toolchain > --- > > Key: MNG-3457 > URL: http://jira.codehaus.org/browse/MNG-3457 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1-alpha-1 >Reporter: Shane Isbell >Priority: Minor > Fix For: 2.1 > > > I would like to see a method, say: AbstractMojo.getToolchainFor(String > toolchainType). -- 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-3458) Add Toolchain Requirements to Project Model
[ http://jira.codehaus.org/browse/MNG-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3458: -- Fix Version/s: 2.1 > Add Toolchain Requirements to Project Model > --- > > Key: MNG-3458 > URL: http://jira.codehaus.org/browse/MNG-3458 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.1-alpha-1 >Reporter: Shane Isbell >Priority: Minor > Fix For: 2.1 > > > Currently, the toolchain plugin will read information from its plugin > configuration > > > > MICROSOFT > 3.0 > > > > This is fine for building but not useful for resolving dependent artifacts > from a repository based on the build platform capabilities. There should be a > way to place the artifact requirements into the project model. -- 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-3470) Build does not fail on corrupted POM even with checksumPolicy=fail
[ http://jira.codehaus.org/browse/MNG-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3470: -- Fix Version/s: 2.0.x > Build does not fail on corrupted POM even with checksumPolicy=fail > -- > > Key: MNG-3470 > URL: http://jira.codehaus.org/browse/MNG-3470 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 2.0.x > > Attachments: mng-3470-it.patch > > > If a dependency has a corrupted POM and the corresponding remote repo is > configured with checksumPolicy=fail, Maven does still not fail the build. > This seems to caused by the fix for MNG-2282: The original > ChecksumFailedException is wrapped into a TransferFailedException which is > errorneously converted into a ResourceDoesNotExistException by > DefaultWagonManager.getArtifact(). Next up, DefaultArtifactResolver.resolve() > wraps this into an ArtifactNotFoundException. > DefaultMavenProjectBuilder.findModelFromRepository() will catch this and > simply create a stub POM instead of failing. > The code from the trunk looks different, not sure if it suffers from this. > Now that I have a JIRA id, I will try to setup an IT. -- 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-3386) Specific dependencies list makes the embedder to set 'varsionRange' for one of them to 'null'
[
http://jira.codehaus.org/browse/MNG-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3386:
--
Fix Version/s: 2.1
> Specific dependencies list makes the embedder to set 'varsionRange' for one
> of them to 'null'
> -
>
> Key: MNG-3386
> URL: http://jira.codehaus.org/browse/MNG-3386
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.1
>Reporter: Anton Makeev
>Priority: Minor
> Fix For: 2.1
>
>
> For the following project the embedder resolves a transitive dependency of
> 'ws-commons-util' named 'xml-apis:xml-apis:jar:1.0.b2:compile' and sets its
> 'versionRange' into null. I dunno wheither it's a bug or intended behaviour,
> but changing the order of dependencies or removing 'dom4j' seems to solve the
> problem.
> {code}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> test
> project
> 1
>
>
> dom4j
> dom4j
> 1.6.1
> runtime
>
>
> org.apache.ws.commons.util
> ws-commons-util
> 1.0.2
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3349) reactor build order doesn't consider plugins modules in build order
[ http://jira.codehaus.org/browse/MNG-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3349: -- Fix Version/s: 2.0.x > reactor build order doesn't consider plugins modules in build order > --- > > Key: MNG-3349 > URL: http://jira.codehaus.org/browse/MNG-3349 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Priority: Minor > Fix For: 2.0.x > > > When a project has maven plugins as modules, and some modules use the plugin, > the reactor SHOULD build the plugins before the modules that use it. > A workaround is to declare plugins modules FIRST in parent 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] Updated: (MNG-3504) Very slow dependency resolution with disabled proxy IP
[ http://jira.codehaus.org/browse/MNG-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3504: -- Fix Version/s: 2.0.x > Very slow dependency resolution with disabled proxy IP > -- > > Key: MNG-3504 > URL: http://jira.codehaus.org/browse/MNG-3504 > Project: Maven 2 > Issue Type: Bug > Components: Performance >Affects Versions: 2.0.8 > Environment: Windows Vista x64 >Reporter: Paul Dillon >Priority: Minor > Fix For: 2.0.x > > > I have a proxy defined in my settings.xml as follows: > > > false > http > 192.168.1.223 > 8080 > 192.168.* > > This proxy lives on my office network. It is inactive because I am currently > working from home. However, although the proxy is inactive, during > dependency resolution maven pauses for 15 seconds per dependency per > repository. Tracing the network showed multiple ARP requests for > 192.168.1.223. After commenting out the inactive proxy performance returned > to normal. > This issue is causing a 2 minute build to take over 1 hour. Using a DNS name > for the proxy address would also resolve the issue, but this is not allowed > on my work network. -- 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-3501) Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3501: -- Fix Version/s: 2.1-alpha-1 > Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT > - > > Key: MNG-3501 > URL: http://jira.codehaus.org/browse/MNG-3501 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.6, 2.1 >Reporter: Dave Syer >Priority: Minor > Fix For: 2.1-alpha-1 > > > Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT. This appears > to be a regression, since it works OK in 2.0.8, but not in 2.0.6 or 2.1. > To reproduce: > 1. set up a Maven project with versionId 1.0.0.-SNAPSHOT (or X.X.-SNAPSHOT). > 2. run "mvn install" > 3. Look in the local repository for the artifact, and find it in a directory > called "1.0.0". -- 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-3501) Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138466#action_138466 ] Brett Porter commented on MNG-3501: --- it works in 2.0.9 as well > Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT > - > > Key: MNG-3501 > URL: http://jira.codehaus.org/browse/MNG-3501 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.6, 2.1 >Reporter: Dave Syer >Priority: Minor > Fix For: 2.1-alpha-1 > > > Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT. This appears > to be a regression, since it works OK in 2.0.8, but not in 2.0.6 or 2.1. > To reproduce: > 1. set up a Maven project with versionId 1.0.0.-SNAPSHOT (or X.X.-SNAPSHOT). > 2. run "mvn install" > 3. Look in the local repository for the artifact, and find it in a directory > called "1.0.0". -- 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-3486) Incorrect dependency resolution when there are cyclic dependencies
[ http://jira.codehaus.org/browse/MNG-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3486. - Resolution: Duplicate > Incorrect dependency resolution when there are cyclic dependencies > -- > > Key: MNG-3486 > URL: http://jira.codehaus.org/browse/MNG-3486 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.8, 2.1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_12 > OS name: "linux" version: "2.6.17-1.2142_fc4smp" arch: "i386" Family: "unix" >Reporter: John Williams > > Maven's transitive dependency algorithm fails silently when there are cycles > in the dependency graph. The symptom is that Maven sometimes fails to find > all the dependencies that it should. For instance, suppose A depends on B, B > and C depend on each other, and C depends on D. Maven will fail to discover > that A transitively depends on D. > I would expect Maven to do one of two things in this case: Either it should > find that A transitively depends on B, C, and D, or it should terminate with > an error. In either case it should report that there is a cycle involving B > and C. -- 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] Moved: (MSHARED-47) maven-dependency-analyzer finds too many used dependencies
[ http://jira.codehaus.org/browse/MSHARED-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3620 to MSHARED-47: -- Component/s: (was: Dependencies) Key: MSHARED-47 (was: MNG-3620) Project: Maven Shared Components (was: Maven 2) > maven-dependency-analyzer finds too many used dependencies > -- > > Key: MSHARED-47 > URL: http://jira.codehaus.org/browse/MSHARED-47 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Matthew Beermann >Assignee: Brian Fox > Attachments: MNG-3620-maven-dependency-analyzer.patch > > > I'll just quote the post from our internal mailing list: > "I don't like that plugin - it has reported dozens of missing dependencies > that were unnecessary for me, so I stopped using it. The most common example > is when you have a dependency on a project that has a dependency on Xerces, > Xalan or some other XML project and your project has java.xml.* imports, > which you're resolving from the JDK, it gives a higher priority to external > dependencies, even if another project introduces them, than it does to JDK > libraries." > I've got a (possible) patch coming up in a few... -- 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-3267) replacing variables in version, groupId or artifactId when POM is installed/deployed
[ http://jira.codehaus.org/browse/MNG-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3267: -- Fix Version/s: 2.1 > replacing variables in version, groupId or artifactId when POM is > installed/deployed > > > Key: MNG-3267 > URL: http://jira.codehaus.org/browse/MNG-3267 > Project: Maven 2 > Issue Type: Improvement > Components: Deployment >Affects Versions: 2.0.7 >Reporter: Jörg Hohwiller > Fix For: 2.1 > > > In a pom.xml I can use variables in almost any place that get resolved > automatically and can even be declared in a parent POM. > This is an extremely cool feature! Now if for some reason I use variables in > one of the following POM-attributes: > groupId > artifactId > version > they are NOT resolved when the pom.xml file is installed. > After having trouble with complex multi-module projects using individual > module versioning I tried a new approach: > I define a global version as variable in the toplevel POM. All POMs that have > packaging "pom" remain version 1.0 (unfortunately necessary because I can not > only say ../pom.xml - should be > another feature request...). > It works surprisingly well: I do not need complex releas-plugins or whatever > - I just change the central version property removing -SNAPSHOT, create a tag > and then open development again by opening the successing SNAPSHOT version. > You might think that this is totally insane. However, it works fine. The only > problem is that the repository can no more be used to get a different version > anymore, even if the artifacts are there. > So all that is needed would be a specific rule in maven that resolves the > variables in the stated sections of the POM when it is installed or deployed. > If ../pom.xml would also work > locally then maven could also automatically fill in groupId, artifactId, and > version of the parent POM during install/deploy. > If no variables are used, the suggested modification would have no effect. If > variables are used, maven would be more reliable because the version could > not change by some side-effect after an artifact is installed. -- 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-3339) Embedder does not resolve transitive dependencies in multi-module project, unless the modules were installed into local repository previously.
[ http://jira.codehaus.org/browse/MNG-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3339: -- Fix Version/s: 2.1 > Embedder does not resolve transitive dependencies in multi-module project, > unless the modules were installed into local repository previously. > -- > > Key: MNG-3339 > URL: http://jira.codehaus.org/browse/MNG-3339 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.1 >Reporter: Anton Makeev > Fix For: 2.1 > > Attachments: transitive-deps.zip > > > I've attached the project that have three modules: > m1 (depends on m2) > m2 (depends on m3) > m3 (depends on junit) > all the dependencies are of the 'compile' scope. > I would expect that embedder resolves dependencies for m1 into m2, m3, and > junit. > But it doesn't do that if repository does not contain these modules > installed. The only dependency is the direct one (m2). > On the other hand, if I previously install the entire project into > repository, I'll have the expected behaviour. -- 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-3619) Dependency.equals(Object):boolean is missing for version 4.0.0 POMs
[
http://jira.codehaus.org/browse/MNG-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3619:
--
Fix Version/s: 2.1
> Dependency.equals(Object):boolean is missing for version 4.0.0 POMs
> ---
>
> Key: MNG-3619
> URL: http://jira.codehaus.org/browse/MNG-3619
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.x
>Reporter: Dennis Lundberg
> Fix For: 2.1
>
>
> The modello file for the 2.0.x branch does not have a for 4.0.0
> POMs that implements equals(Object):boolean. Modello doesn't generate one
> automatically either. Perhaps upgrading to a newer version of the modello
> plugin will solve this.
> http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-model/src/main/mdo/maven.mdo?revision=659677&view=markup
> There is a for 3.0.0 POMs only:
> {code}
> /**
> * @see java.lang.Object#equals(java.lang.Object)
> */
> public boolean equals( Object o )
> {
> if ( this == o )
> {
> return true;
> }
> if ( !( o instanceof Dependency ) )
> {
> return false;
> }
> Dependency d = (Dependency) o;
> return getId().equals( d.getId() );
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3587) Strange warnings while building a project
[ http://jira.codehaus.org/browse/MNG-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3587: -- Fix Version/s: 2.0.10 > Strange warnings while building a project > - > > Key: MNG-3587 > URL: http://jira.codehaus.org/browse/MNG-3587 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Seva Popov > Fix For: 2.0.10 > > Attachments: maven-warning.txt > > > We've switched from Maven 2.0.7 to Maven 2.0.9 and started observing strange > warnings happening in different contexts in our builds: > Example: > [WARNING] Attempting to build MavenProject instance for Artifact > (com.tvworks.tva.maven.plugins:maven-license-plugin:3.3-20080508.052638-16) > of type: maven-plugin; constructing POM artifact instead. > [WARNING] Attempting to build MavenProject instance for Artifact > (com.tvworks.tva.common:tva-common-logging:3.3-20080513.211757-62) of type: > jar; constructing POM artifact instead. > More details in this thread: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg85248.html -- 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-3621) site url inheritance broken for UNC paths
[
http://jira.codehaus.org/browse/MNG-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3621:
--
Fix Version/s: 2.0.10
> site url inheritance broken for UNC paths
> -
>
> Key: MNG-3621
> URL: http://jira.codehaus.org/browse/MNG-3621
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9
> Environment: Win XP SP2
>Reporter: James Nord
> Fix For: 2.0.10
>
> Attachments: build.txt, MNG-3621.patch
>
>
> I have a parent POM that is inherited by multiple projects that specifies
> site wide default settings.
> (e.g)
> Parent\pom.xml <--- this is the pom containing the site configuration
> Parent\CheckStyleConfig\pom.xml
> Part of this is the site deploy
>
>
> nds-uk.site
> file:/scg-nas.uk.nds.com/maven_sites/${project.groupId}/${project.artifactId}/${project.version}
>
>
> running site:deploy on the sub procject results in it using a corrupted
> version of the url.
> build output attached.
> Notice the corruption of the original parent file:/ (2 slashes are
> removed so it tries to deploy to local HDD)
> parent (OK 5 slashes)
> file:/scg-nas.uk.nds.com/maven_sites/com.nds.cab.scg/common-parent/1.0.0.0-SNAPSHOT
> - Session: Opened
> child (bad 3 slashes)
> file:///scg-nas.uk.nds.com/maven_sites/com.nds.cab.scg/common-checkstyle/1.0.0.0-SNAPSHOT/common-checkstyle
> - Session: Opened
--
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-3543) readProjectWithDependencies take very long time for some projects
[ http://jira.codehaus.org/browse/MNG-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3543: -- Fix Version/s: 2.1 how does it compare to CLI use of 2.0.9? could it be considered a regression? > readProjectWithDependencies take very long time for some projects > - > > Key: MNG-3543 > URL: http://jira.codehaus.org/browse/MNG-3543 > Project: Maven 2 > Issue Type: Bug > Components: Performance >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Jason van Zyl > Fix For: 2.1 > > > Invoking readProjectWithDependencies for all modules takes very long time for > some projects. For example, for servicemix-3.2.1 it takes about ~300 seconds > in online mode and ~90 seconds. I ran the code under profiler, and it seems > that in online mode this project is hit by MNG-3531. Both in online and > offline mode, however, significant time is spent in > DefaultBuildExtensionScanner.scanInternal(File, MavenExecutionRequest, List, > List, boolean), so I wonder if there is a way to cache extensions somehow. -- 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-3531) embedder always checks missing release artifacts
[ http://jira.codehaus.org/browse/MNG-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3531: -- Fix Version/s: 2.1 if done from the CLI - is this a regression from 2.0.9 to 2.1 behaviour? > embedder always checks missing release artifacts > > > Key: MNG-3531 > URL: http://jira.codehaus.org/browse/MNG-3531 > Project: Maven 2 > Issue Type: Bug > Components: Performance >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Jason van Zyl > Fix For: 2.1 > > > 2.1 embedder always checks remote repositories for missing release artifacts. > This is done multiple times during the same readProjectWithDependencies > invocation and results in bad performance problems in embedding application > (see MNGECLIPSE-523). -- 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-3611) allow to pass in location of global settings file to maven cli
[ http://jira.codehaus.org/browse/MNG-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3611: -- Fix Version/s: 2.1 > allow to pass in location of global settings file to maven cli > -- > > Key: MNG-3611 > URL: http://jira.codehaus.org/browse/MNG-3611 > Project: Maven 2 > Issue Type: New Feature >Reporter: Eugene Kuleshov > Fix For: 2.1 > > > It would be useful to be able to pass in location of the global settings file > (i.e. /conf/settings.xml) to MavenCli, similar how it is done for > user's settings with -s command line option -- 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-3546) command line cannot overwrite pom properties
[ http://jira.codehaus.org/browse/MNG-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3546: -- Fix Version/s: 2.0.x > command line cannot overwrite pom properties > > > Key: MNG-3546 > URL: http://jira.codehaus.org/browse/MNG-3546 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.9 >Reporter: Thomas Diesler > Fix For: 2.0.x > > > With a pom like this > > localhost > > and a command line like this > mvn -Pjboss422 -Djboss.bind.address=foo clean test-compilecxf.xml > I get a filtered resource like this >address='http://localhost:8080/jaxws-cxf-descriptor' > > implementor='org.jboss.test.ws.jaxws.cxf.descriptor.DescriptorEndpointImpl'> > > > > > > > Note, the bind address is localhost -- 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-3615) Provide Central Repository Download Statistics
[ http://jira.codehaus.org/browse/MNG-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3615. - Assignee: Brett Porter Resolution: Won't Fix nice idea, but not really relevant to Maven itself. Hopefully as we improve mirroring support, increase use of repository managers, etc., the use will be more efficient - but it will also make the data not very relevant. > Provide Central Repository Download Statistics > -- > > Key: MNG-3615 > URL: http://jira.codehaus.org/browse/MNG-3615 > Project: Maven 2 > Issue Type: New Feature >Reporter: Daniel Gredler >Assignee: Brett Porter > > As Maven becomes more prevalent, fewer people download third-party libraries > manually. It would be nice to get some basic download stats for > repo1.maven.org, so that developers have some information about which > libraries are popular (and which libraries aren't) among the Maven crowd. -- 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-3609) xbean breaks embedding within netbeans by using java.beans.PropertyEditorManager.registerEditor
[ http://jira.codehaus.org/browse/MNG-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3609: -- Fix Version/s: 2.1-alpha-1 > xbean breaks embedding within netbeans by using > java.beans.PropertyEditorManager.registerEditor > --- > > Key: MNG-3609 > URL: http://jira.codehaus.org/browse/MNG-3609 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1 > Environment: netbeans 6.1, mevenide 3.1.2+ >Reporter: Milos Kleint > Fix For: 2.1-alpha-1 > > Attachments: xbean.patch > > > The xbean binary shipping with maven in 2.1 is registering PropertyEditors > via java.beans.PropertyEditorManager.registerEditor() > that's wracking havoc in the IDE's own code that relies on it's own property > editors with customizer ui to be present. > http://www.netbeans.org/issues/show_bug.cgi?id=135868 is the obvious error > everyone noticed, there's more subtle ones as well, like being unable to edit > properties, or broken form GUI editor that's not processing real numbers > correctly. > I've hotfixed the issue by commenting out the property editor registration in > xbean (attached) -- 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-3612) property in settings.xml not interpolated when resolving parent POM from remote repository
[
http://jira.codehaus.org/browse/MNG-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3612:
--
Fix Version/s: 2.0.x
> property in settings.xml not interpolated when resolving parent POM from
> remote repository
> --
>
> Key: MNG-3612
> URL: http://jira.codehaus.org/browse/MNG-3612
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9
> Environment: Java 1.5.0_11, Windows XP
>Reporter: Pat Podenski
> Fix For: 2.0.x
>
> Attachments: parent-and-child.zip, pom.xml, pom.xml, settings.xml
>
>
> The objective was to use a property in the settings.xml within a profile.
> This property represents the remote repository host/port number. This is so
> that multiple entries of the host/port in the settings.xml profiles do not
> need to be edited when the host/port value changes.
> When working in a project whose parent POM is not installed in the local
> repository, download of the parent POM from the remote repository fails. If
> the host/port literal value is substituted in the repository element
> contained in the settings.xml profile, the download succeeds.
> If the parent POM is installed in the local repository resolution succeeds
> (of course we don't need the remote repository in this case unless trying to
> update the SNAPSHOT).
> Attached example files.
> 1 - settings.xml file used in ~/.m2/
> 2 - pom.xml for base-pom
> 3 - pom.xml for child
> To reproduce this problem:
> 1) deploy parent POM to remote repository (I use Artifactory which has an
> upload utility, so I didn't need to install parent POM in the local
> repository)
> 2) verify that parent POM is not in the local repository
> 3) try a 'mvn clean' or similar command in the child project - this operation
> fails (see below)
> 4) If the literal host/port value is put into the settings.xml repository
> element instead of ${repo-host}, the operation will succeed
> [INFO] Scanning for projects...
> [INFO] snapshot com.foo:base-pom:1-SNAPSHOT: checking for updates from central
> [WARNING] repository metadata for: 'snapshot com.foo:base-pom:1-SNAPSHOT'
> could not be retrieved
> from repository: central due to an error: Error transferring file
> [INFO] Repository 'central' will be blacklisted
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: com.foo
> ArtifactId: base-pom
> Version: 1-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> com.foo:base-pom:pom:1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> com.foo:base-pom for project:
> com.bar:child:jar:0.0.1-SNAPSHOT for project com.bar:child:jar:0.0.1-SNAPSHOT
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find
> parent: com.foo:base-pom f
> or project: com.bar:child:jar:0.0.1-SNAPSHOT for project
> com.bar:child:jar:0.0.1-SNAPSHOT
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBu
> ilder.java:1370)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuil
> der.java:821)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMa
> venProjectBuilder.java:506)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java
> :198)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven
[jira] Updated: (MNG-3608) Reporting Encoding Configuration: ${project.reporting.outputEncoding}
[
http://jira.codehaus.org/browse/MNG-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3608:
--
Fix Version/s: 2.1
> Reporting Encoding Configuration: ${project.reporting.outputEncoding}
> --
>
> Key: MNG-3608
> URL: http://jira.codehaus.org/browse/MNG-3608
> Project: Maven 2
> Issue Type: Sub-task
>Reporter: Herve Boutemy
> Fix For: 2.1
>
>
> see [Reporting Encoding Configuration
> proposal|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]
--
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-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3379: -- Fix Version/s: 2.1 > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown >Assignee: Brett Porter > Fix For: 2.1 > > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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] Moved: (MRESOURCES-69) Filtering with POM.xml elements
[
http://jira.codehaus.org/browse/MRESOURCES-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-3359 to MRESOURCES-69:
-
Affects Version/s: (was: 2.0.8)
Component/s: (was: POM)
Key: MRESOURCES-69 (was: MNG-3359)
Project: Maven 2.x Resources Plugin (was: Maven 2)
> Filtering with POM.xml elements
> ---
>
> Key: MRESOURCES-69
> URL: http://jira.codehaus.org/browse/MRESOURCES-69
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Reporter: Zach Legein
> Attachments: maven-bug.tar.gz
>
>
> I have this weird error where if I have a project like the one attached. It
> appears that when filtering is set to _true_ and you have an file that has a
> reference to a 'name' value, like so:
> {code:xml}
>
>
> ${something.name}
>
>
> {code}
> The pom.xml _name_ element will be used when filtering this file.
> So if your pom.xml is written like so:
> {code:xml}
>
>Look at Me!
>
> {code}
> This _name_ value will be used to do filtering if turned on.
> Granted you would want to set up your project like this, but this is not
> expected behavior, right?
--
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-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3595: -- Fix Version/s: 2.1 > Changes made to project resolved artifacts are overriden when a plugin uses > @requiresDependencyResolution > - > > Key: MNG-3595 > URL: http://jira.codehaus.org/browse/MNG-3595 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Jerome Lacoste > Fix For: 2.1 > > Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, > MNG-3595.diff > > > clover:instrument mojo creates instrumented artifacts and attaches them with > a 'clover' classifier. > It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which > tries to change the project direct and transitive dependencies after > 'swizzling' them [3] (replacing normal artifacts with their clovered ones). > This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR > containing all available clovered dependencies. > Unfortunately maven handles direct and transitive dependencies differently > [4]. While direct dependencies are somewhat preserved (the code comments > references clover), transitive dependencies are re-resolved, and thus the > results of the swizzling operation are lost as soon as a plugin > requiresDependencyResolution in a further part of the lifecycle. > I've managed to hack maven and clover:instrument to work together by allowing > a plugin to attach some sort of "dependency resolution post processing" > operation [5]. > In the case of clover:instrument, the swizzling is then registered in the > maven project and re-performed each time the artifacts are re-resolved. > I am not very fond of this solution, but it seems to work for us on the > attached example. I will further test the patch this week on a large scale > project. > I would like to discuss ways to solve this interaction, whether the clover > plugin should be implemented differently or if maven should have some sort of > support for this use case. > [1] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java > [2] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml > [3] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java > [4] > http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406 > [5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html -- 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-3597) Using ${project.parent.basedir} in causes InvalidProjectModelException
[
http://jira.codehaus.org/browse/MNG-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3597:
--
Fix Version/s: 2.0.x
> Using ${project.parent.basedir} in causes
> InvalidProjectModelException
>
>
> Key: MNG-3597
> URL: http://jira.codehaus.org/browse/MNG-3597
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.8
>Reporter: Jan Rudert
> Fix For: 2.0.x
>
>
> Hi
> although the Anttask prints out
> the proper path of my multiproject's root directory, I get an
> InvalidProjectModelException If I try to use it in the element
> of a dependency like this:
>
> org.company.my
> xyz
> 1.0
> system
> ${project.parent.basedir}/path/to/xyz.jar
>
> Also mvn help:effective-pom resolves that property if not used in
>
--
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-3607) Class loaders employed by Maven return invalid URLs to resources
[
http://jira.codehaus.org/browse/MNG-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3607:
--
Fix Version/s: 2.1
> Class loaders employed by Maven return invalid URLs to resources
>
>
> Key: MNG-3607
> URL: http://jira.codehaus.org/browse/MNG-3607
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Benjamin Bentmann
> Fix For: 2.1
>
>
> This is basically a Plexus thing because {{DefaultPlexusContainer}} from
> plexus-container-default:1.0-alpha-9-stable-1 is using {{File.toURL()}}
> instead of {{File.toURI().toURL()}} when populating the class realms from
> local JAR files (e.g. the resulting URLs return illegal characters like
> spaces).
> The latest plexus-container-default seems to already use the proper methods
> so this issue is more or less a request to incorporate this fix into the
> 2.0.x branch. For instance, usage of Ant 1.7 is severly affected by this
> (MANTRUN-68).
--
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-3603) Incomplete set of transitive dependencies resolved when transitive dependencies repository is not listed.
[ http://jira.codehaus.org/browse/MNG-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3603: -- Fix Version/s: 2.0.x > Incomplete set of transitive dependencies resolved when transitive > dependencies repository is not listed. > - > > Key: MNG-3603 > URL: http://jira.codehaus.org/browse/MNG-3603 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9 > Environment: windows vista jdk 1.5.0_11 >Reporter: Micah Whitacre > Fix For: 2.0.x > > Attachments: maven_testcase.zip > > > I have project D which is dependent on project C. Project D lists the > repository that the latest snapshot or release project C resides in. Project > C depends on project B which depends on project A. Both projects B and A > reside in a different repository than Project C and D. Project C properly > lists the repository A and B reside in. All dependency scopes are compile so > therefore transitively project D has a compile time dependency on A. The > issue arises in that when building project D with a clean local maven > repository project A is never resolved, no error is given but errors will > occur later when actually trying to run tests. > I have attached a testcase of this situation with projects A,B,C,and D. To > duplicate this issue: > 1. Unzip the attachment to a folder on your machine. > 2. At the root of that folder run "mvn deploy". This will deploy projects A > and B to fake-remote-repo2 and project C to fake-remote-repo1. One note is > the URL of the repositories is windows based to this will need to be adjusted > in the POMs and in the projectD pom if you are *nix based. > 3. Clear your local maven repository. > 4. Navigate to the "projectD" folder and run "mvn compile". > After step 4 completes browse your local maven repo and you will notice that > project A is not present. > In the actual situation I'm encountering this it not only fails to resolve > dependencies but also parent poms. -- 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-3560) unable to use plugins that exist in multiple repositories
[
http://jira.codehaus.org/browse/MNG-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3560:
--
Assignee: Brett Porter
Fix Version/s: 2.0.10
> unable to use plugins that exist in multiple repositories
> -
>
> Key: MNG-3560
> URL: http://jira.codehaus.org/browse/MNG-3560
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Maria Catherine Tan
>Assignee: Brett Porter
> Fix For: 2.0.10
>
> Attachments: MNG-3560-maven-artifact.patch
>
>
> I created two test cases using maven-2.0.9
> A. Here's the settings for my first test case which builds successfully using
> mvn site or mvn site -up
> 1. Created two remote repository
> - sandbox has maven-project-info-reports-plugin 2.0.1
> - corporate has maven-project-info-reports-plugin 2.0
> 2. No maven-project-info-reports-plugin in my local repository
> 3. Access to central repository is disabled
> 4. The order in my settings.xml for the plugin repositories is sandbox first
> before corporate
>
> sandbox
> http://localhost:9091/repository/sandbox
>
>
> corporate
> http://localhost:9091/repository/corporate
>
> Result:
> * downloaded maven-project-info-reports-plugin 2.0 pom in corporate
> * check maven-project-info-reports-plugin 2.0 jar in sandbox
> * downloaded maven-project-info-reports-plugin 2.0 jar in corporate
> {code}
> [EMAIL PROTECTED]:~/projects/testproject$ mvn site -up
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building testproject
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin:
> checking for updates from sandbox
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin:
> checking for updates from corporate
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin:
> checking for updates from central
> [WARNING] repository metadata for: 'artifact
> org.apache.maven.plugins:maven-project-info-reports-plugin' could not be
> retrieved from repository: central due to an error: Error transferring file
> [INFO] Repository 'central' will be blacklisted
> Downloading:
> http://localhost:9091/repository/corporate/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.pom
> 5K downloaded
> Downloading:
> http://localhost:9091/repository/sandbox/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.jar
> Downloading:
> http://localhost:9091/repository/corporate/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.jar
> [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] [site:site]
> [INFO] Generating "Source Repository" report.
> [INFO] Generating "Issue Tracking" report.
> [INFO] Generating "About" report.
> [INFO] Generating "Project License" report.
> [INFO] Generating "Project Summary" report.
> [INFO] Generating "Dependencies" report.
> [INFO] Generating "Continuous Integration" report.
> [INFO] Generating "Project Team" report.
> [INFO] Generating "Mailing Lists" report.
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> B. Here's the settings for my second test case which replicate this issue
> 1. Created two remote repository
> - sandbox has maven-project-info-reports-plugin 2.0.1
> - corporate has maven-project-info-reports-plugin 2.0
> 2. No maven-project-info-reports-plugin in my local repository
> 3. Access to central repository is disabled
> 4. The order in my settings.xml for the plugin repositories is corporate
> first before sandbox
>
> corporate
> http://localhost:9091/repository/corporate
>
>
> sandbox
> http://localhost:9091/repository/sandbox
>
> Result:
> * downloaded maven-project-info-reports-plugin 2.0 pom in sandbox which
> it did not find and never tries to check the corporate where the pom could be
> found
> * downloaded maven-project-info-reports-plugin 2.0 jar in corporate
> {code}
> [EMAIL PROTECTED]:~/projects/testproject$ mvn site -up
> [INFO] Scanning for projects...
> [INFO]
> ---
[jira] Closed: (MNG-3594) Maven 2.0.6 tag doesn't build properly anymore
[ http://jira.codehaus.org/browse/MNG-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3594. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.0.6 applied, thanks > Maven 2.0.6 tag doesn't build properly anymore > -- > > Key: MNG-3594 > URL: http://jira.codehaus.org/browse/MNG-3594 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Jerome Lacoste >Assignee: Brett Porter > Fix For: 2.0.6 > > Attachments: maven-2.0.6-maven-core.diff > > > The uberjar wasn't generated when building. Tried bootstrapping and normal > build (using a maven 2.0.6 install). > I've had to patch the maven-core pom and specify the shade version to get it > to work again. I've used version 0.4 (which was also used in maven 2.0.7) > $ svn info > Path: . > URL: https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6 > Repository Root: https://svn.apache.org/repos/asf > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > Revision: 659652 > Node Kind: directory > Schedule: normal > Last Changed Author: jvanzyl > Last Changed Rev: 522714 > Last Changed Date: 2007-03-27 04:40:40 +0200 (Tue, 27 Mar 2007) -- 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-3397) [RFC] change the POM to use attributes
[ http://jira.codehaus.org/browse/MNG-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3397: -- Fix Version/s: 2.1 > [RFC] change the POM to use attributes > -- > > Key: MNG-3397 > URL: http://jira.codehaus.org/browse/MNG-3397 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.8 >Reporter: Brett Porter > Fix For: 2.1 > > -- 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-3592) provide mechanism to serialize/deserialize MavenProject
[ http://jira.codehaus.org/browse/MNG-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3592: -- Fix Version/s: 2.1 > provide mechanism to serialize/deserialize MavenProject > --- > > Key: MNG-3592 > URL: http://jira.codehaus.org/browse/MNG-3592 > Project: Maven 2 > Issue Type: New Feature >Reporter: Eugene Kuleshov > Fix For: 2.1 > > > When working with embedded Maven it would be useful to be able to persist > MavenProject instances (using some form of serialization), so we could > restore it without triggering full project resolution. One example of that is > a form of persistent caching that will be very useful in the IDE. -- 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-3590) compile time scope which is not active while testing
[ http://jira.codehaus.org/browse/MNG-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3590. - Resolution: Won't Fix you can use provided or optional for this purpose, you will just need to declare it in the locations it is needed > compile time scope which is not active while testing > > > Key: MNG-3590 > URL: http://jira.codehaus.org/browse/MNG-3590 > Project: Maven 2 > Issue Type: New Feature >Reporter: Rainer Flicker > > Sometimes libraries won't work together for testing, but are needed for > compilation. For example, > JBoss embedded is known for several problems with external libraries. If a > library is needed for > compilation, it can not be excluded for testing and therefore tests including > JBoss embedded are > failing. A new scope, which is only active for compilation, would help to > avoid this problem. -- 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-3582) Support 'parameter' mechanism for mojo aggregated objects
[
http://jira.codehaus.org/browse/MNG-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3582:
--
Fix Version/s: 2.1
Component/s: (was: Plugin Requests)
Plugins and Lifecycle
> Support 'parameter' mechanism for mojo aggregated objects
> -
>
> Key: MNG-3582
> URL: http://jira.codehaus.org/browse/MNG-3582
> Project: Maven 2
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.8
>Reporter: Ittay Dror
> Fix For: 2.1
>
>
> if class AMojo has a field AObject, then this field can have xdoclet tags to
> define how to instantiate it (expression, default-value). however, inside the
> object, we cannot use this mechanism. so if in AObject, I want a field whose
> default value will be ${project.build.finalName}, i have to do get it
> "manually"
--
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-3328) Allow multiple profile activation properties.
[ http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3328: -- Fix Version/s: 2.1 > Allow multiple profile activation properties. > - > > Key: MNG-3328 > URL: http://jira.codehaus.org/browse/MNG-3328 > Project: Maven 2 > Issue Type: Improvement > Components: Profiles >Affects Versions: 2.0.8 >Reporter: Paul Gier > Fix For: 2.1 > > > The pom model should be changed to allow multiple properties to activate a > profile. So the profile activation section could look something like this: > > > some-value > another-value > > > This would provide more flexibility in profile activation. -- 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-3463) AsbtractMojo should look for LoggerManager plexus component
[ http://jira.codehaus.org/browse/MNG-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138457#action_138457 ] Brett Porter commented on MNG-3463: --- I'm not sure coupling to plexus is a good idea (even if most other things are). The embedder already does handle directing this to the plexus logger, not system.out specifically. > AsbtractMojo should look for LoggerManager plexus component > --- > > Key: MNG-3463 > URL: http://jira.codehaus.org/browse/MNG-3463 > Project: Maven 2 > Issue Type: Improvement > Components: Logging >Reporter: Robert Egan > Fix For: 2.1 > > > AbstractMojo currently defines it's own Log interface, hard coded to use > System.out. This really restricts the logging capabilities of all plugins. It > would be nice if it attempted to look up the plexus role > "org.codehaus.plexus.logging.LoggerManager" first and only used System.out if > that failed. > Doing this would also go a long way towards resolving MNG-2570 and MNG-3305. -- 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-3463) AsbtractMojo should look for LoggerManager plexus component
[ http://jira.codehaus.org/browse/MNG-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3463: -- Fix Version/s: 2.1 > AsbtractMojo should look for LoggerManager plexus component > --- > > Key: MNG-3463 > URL: http://jira.codehaus.org/browse/MNG-3463 > Project: Maven 2 > Issue Type: Improvement > Components: Logging >Reporter: Robert Egan > Fix For: 2.1 > > > AbstractMojo currently defines it's own Log interface, hard coded to use > System.out. This really restricts the logging capabilities of all plugins. It > would be nice if it attempted to look up the plexus role > "org.codehaus.plexus.logging.LoggerManager" first and only used System.out if > that failed. > Doing this would also go a long way towards resolving MNG-2570 and MNG-3305. -- 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-3578) Enhancements to plugin parameters
[
http://jira.codehaus.org/browse/MNG-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3578:
--
Fix Version/s: 2.x
> Enhancements to plugin parameters
> -
>
> Key: MNG-3578
> URL: http://jira.codehaus.org/browse/MNG-3578
> Project: Maven 2
> Issue Type: Improvement
>Reporter: Ittay Dror
> Fix For: 2.x
>
>
> allow plugin parameters to reference other parameters. so, for example, i can
> have 'dir' and 'file' parameters, where 'file' is '${dir}/something'. then,
> if the user defines 'dir' in the plugin configuration in the pom, file uses
> the configured value.
> also, leave unknown expressions as they are. so if 'file' is
> ${dir}/${unknown} it will be expanded to 'some/path/${unknown}'. this allows
> the mojo to further expand the parameter with runtime value without resorting
> to the use of '$$"
--
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] Moved: (MSHARED-46) Create a common component for files filtering
[ http://jira.codehaus.org/browse/MSHARED-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3374 to MSHARED-46: -- Affects Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Maven Resources Filtering) Key: MSHARED-46 (was: MNG-3374) Project: Maven Shared Components (was: Maven 2) > Create a common component for files filtering > - > > Key: MSHARED-46 > URL: http://jira.codehaus.org/browse/MSHARED-46 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > > Currently we have some duplicated code in some plugins for filtering. > This means some plugins use a different logic. > This component will a common filtering logic for all plugins. -- 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-3575) Allow hexadecimal parameters
[ http://jira.codehaus.org/browse/MNG-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3575: -- Fix Version/s: 2.1 > Allow hexadecimal parameters > > > Key: MNG-3575 > URL: http://jira.codehaus.org/browse/MNG-3575 > Project: Maven 2 > Issue Type: Improvement >Reporter: Marvin Froeder > Fix For: 2.1 > > > I like to ask to hexadecimal support on parameters, like this: > /* >* @parameter default-value="0x869CA7" >*/ > private int defaultBackgroundColor; -- 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-3569) Maven sometimes fails to resolve newest dependency from remote snapshot repository
[ http://jira.codehaus.org/browse/MNG-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3569. - Assignee: Brett Porter Resolution: Not A Bug IIUC - your local repo is just not sync'd with the remote change. It happens first call after midnight by default. This can be configured in the POM (updatePolicy = always), or forced from the command line using -U (does this work for you?) > Maven sometimes fails to resolve newest dependency from remote snapshot > repository > -- > > Key: MNG-3569 > URL: http://jira.codehaus.org/browse/MNG-3569 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8, 2.0.9 > Environment: Linux (Debian etch) & Windows Vista Ultimate >Reporter: Greg Martin >Assignee: Brett Porter > > I have a project called common-core that is currently on version > 1.1-SNAPSHOT. I have another project that depends on > the 1.1-SNAPSHOT version of common-core. > The scenario that always reproduces this for me is: > deploy common-core from machine A > I end up with this maven-metadata-snapshot.xml in my local repository for > common-core:1.1-SNAPSHOT: > > my.group > common-core > 1.1-SNAPSHOT > > > 5 > 20080509.064349 > > 20080509064349 > > > And in the remote snapshot repository, the maven-metadata.xml matches the > above. > So, time passes, and I deploy common-core from machine B, and end up > with this maven-metadata-snapshot.xml in that local repository: > > my.group > common-core > 1.1-SNAPSHOT > > > 20080509.071037 > 6 > > 20080509071037 > > > And now, in the remote snapshot repository, the maven-metadata.xml matches > the above. > If I now go back to machine A and do a mvn clean compile -X on the project > which depends on common-core, it resolves to the wrong snapshot version: > [DEBUG] common-core: resolved to version 1.1-20080509.064349-5 from > repository snapshot > [DEBUG] my.group:common-core:jar:1.1-SNAPSHOT:compile (selected for > compile) > It doesn't look like it's even checking the remote snapshot repository for > updates. > I've tried this on both 2.0.8 and 2.0.9. Is is supposed to be working this > way? -- 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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3283: -- Fix Version/s: 2.1 > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: http://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Brian Fox > Fix For: 2.1 > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3507) ANSI Color logging for improved output visibility.
[ http://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3507: -- Fix Version/s: 2.1 > ANSI Color logging for improved output visibility. > -- > > Key: MNG-3507 > URL: http://jira.codehaus.org/browse/MNG-3507 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur > Fix For: 2.1 > > Attachments: maven-colorlogger.zip > > > Is it possible for Maven to use ANSI color logging? IMO it would make Maven > logs much easier to read and increase the visibility of items that the user > want to see at any given point in time. > I think Andrew Williams did some work under Plexus sandbox to enable color > logging. There also a color logger available in Ant. > http://ant.apache.org/manual/listeners.html#AnsiColorLogger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3563) Content of a property ending with .url gets overwritten with the content of from the pom.xml
[
http://jira.codehaus.org/browse/MNG-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3563:
--
Fix Version/s: 2.0.x
> Content of a property ending with .url gets overwritten with the content of
> from the pom.xml
>
>
> Key: MNG-3563
> URL: http://jira.codehaus.org/browse/MNG-3563
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Linux
>Reporter: Stephan Kleine
> Fix For: 2.0.x
>
>
> If one creates a property e.g. named jdbc.url in a parent pom.xml and then
> refers to that property via ${jdbc.url} in a resource file of a subproject
> whose pom.xml is derived from the one that declares the jdbc.url property the
> content is overwritten with the content of the tag during the filtering
> step.
> E.g.
> com.example.project contains:
> jdbc:mysql://localhost:3306/TestDB
> in its pom.xml
> com.example.subproject is derived from com.example.project and contains
> url="${jdbc.url}
> in some db setup file and
> http://maven.apache.org
> in its pom.xml
> The resulting content, after the filtering step, will be
> "url="http://maven.apache.org""; instead of
> "url="jdbc:mysql://localhost:3306/TestDB"".
--
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-3564) alternative and higher level configuration option to
[ http://jira.codehaus.org/browse/MNG-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3564: -- Fix Version/s: 2.1 > alternative and higher level configuration option to > > > Key: MNG-3564 > URL: http://jira.codehaus.org/browse/MNG-3564 > Project: Maven 2 > Issue Type: New Feature > Components: General >Affects Versions: 2.0.9 >Reporter: manuel aldana > Fix For: 2.1 > > > maven provides scope (test, runtime etc.) to filter certain dependencies. > never the less sometimes it is quite helpful to have a another configuration > option, where you decide what to include transitively or what kind of > dependency-set is relevant to your current project. using > configuration to accomplish this is often very verbose, non-standard and is > difficult to read (it is often not obvious what is meant with all these > exclusions). > > as an example ivy includes such configuration meta-info approach (see > http://ant.apache.org/ivy/m2comparison.html). this feature would be nice > because when building releases one is more flexible. -- 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-3348) Add new dependency scope "bootstrap" to support concept of boot class path
[ http://jira.codehaus.org/browse/MNG-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3348: -- Fix Version/s: 2.x > Add new dependency scope "bootstrap" to support concept of boot class path > -- > > Key: MNG-3348 > URL: http://jira.codehaus.org/browse/MNG-3348 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann > Fix For: 2.x > > > When it comes to cross-platform compilation, one needs to feed in a > bootclasspath into various JDK tools like javac or javadoc (see MCOMPILER-20, > MOJO-606). Currently, the affected Maven plugins provide a configuration > parameter on their own to deal with this concept. Usually, this configuration > needs to be configured with file system paths (either to some JARs in the > local repo or to the user's JDK installation). > That's not really the Maven way. Maven builds classpaths from dependencies > and hence, the bootclasspath should be configurable via dependencies, too. > Having a dedicated scope for such dependencies would make plugin development > and configuration more straightforeward in the case of cross-platform > compilation. > My post MCOMPILER-20#action_112355 may be used as an inspiration, how such a > new scope could look like. -- 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-3518) Handle date qualifier in DefaultArtifactVersion
[
http://jira.codehaus.org/browse/MNG-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3518:
--
Fix Version/s: 2.1
> Handle date qualifier in DefaultArtifactVersion
> ---
>
> Key: MNG-3518
> URL: http://jira.codehaus.org/browse/MNG-3518
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Vincent Siveton
> Fix For: 2.1
>
> Attachments: DefaultArtifactVersion-handledate.diff, pom.xml
>
>
> Eclipse artifacts use a date pattern in version qualifier and build fail with
> the following error
> {noformat}
> [INFO] Failed to resolve artifact.
> Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0)
> org.eclipse.equinox:app:jar:null
> {noformat}
> The following patch adds javadoc for compareTo() to be more clear.
> Also, it handles date pattern in the version to allow "1.0.0" <
> "1.0.0-v20070606". Internally, it compares "1.0.0-19068845215" (ie new
> Date(Integer.MAX_VALUE, 12, 31 )) to "1.0.0-20070606"
--
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-3562) Need documentation of command-line flags
[ http://jira.codehaus.org/browse/MNG-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3562: -- Fix Version/s: Documentation Deficit > Need documentation of command-line flags > > > Key: MNG-3562 > URL: http://jira.codehaus.org/browse/MNG-3562 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: General >Reporter: SebbASF > Fix For: Documentation Deficit > > > The Maven2 documentation does not seem to contain any description of the > command-line flags. > Perhaps the Maven 1 example could be adapted: > http://maven.apache.org/maven-1.x/reference/command-line.html -- 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-3295) Cannot use offline (-o) if a is declared
[ http://jira.codehaus.org/browse/MNG-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3295. - Resolution: Cannot Reproduce Fix Version/s: 2.0.9 > Cannot use offline (-o) if a is declared > - > > Key: MNG-3295 > URL: http://jira.codehaus.org/browse/MNG-3295 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.7 >Reporter: Matt Read > Fix For: 2.0.9 > > > Create a simple project: > mvn archetype:create -DgroupId=test -DartifactId=offline_parent_test > -DarchetypeArtifactId=maven-archetype-quickstart > edit the pom.xml and add a parent entry that you know exists in your local > repository, e.g. > > com.test > MyParent > 1.0-SNAPSHOT > > run > mvn -o install > produces the following error: > [INFO] > NOTE: Maven is executing in offline mode. Any artifacts not already in your > local > repository will be inaccessible. > [INFO] Scanning for projects... > [INFO] snapshot com.test:MyParent:1.0-SNAPSHOT: checking for updates from > maven.catlin.com.repo.snapshots > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Failed to resolve artifact. > GroupId: com.test > ArtifactId: MyParent > Version: 1.0-SNAPSHOT > Reason: System is offline. > com.test:MyParent:pom:1.0-SNAPSHOT > NOTE: Maven is executing in offline mode. Any artifacts not already in your > local > repository will be inaccessible. -- 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-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3559: -- Fix Version/s: 2.0.x > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Fix For: 2.0.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 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-3558) Add a property substitution escaping mechanism
[
http://jira.codehaus.org/browse/MNG-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3558:
--
Fix Version/s: 2.x
> Add a property substitution escaping mechanism
> --
>
> Key: MNG-3558
> URL: http://jira.codehaus.org/browse/MNG-3558
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Christophe DENEUX
> Fix For: 2.x
>
>
> Hi,
> Developping a maven plugin, it is possible to initialize plugin parameters to
> "${artifactId}-${version}" without property substitution, using:
> @parameter expression="$${artifactId}-$${version}.$${extension}"
> at the parameter declaration.
> But, in a POM file, it seems to me that it is not possible to redefine the
> value of a such parameter without property substitution.
> I had tried without success:
>- ${dollar}{artifactId} with the property "dollar"
> set to "$", replaced by value of artifactId,
>- $${artifactId}, replaced by "$" followed by
> artifactId value,
>- \${artifactId}, replaced by "\" followed by
> artifactId value,
>- , replaced by value of
> artifactId.
> Please, add a property substitution escaping mechanism.
> Thanks,
> Christophe
--
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-3552) ProfileManager not available as a component
[
http://jira.codehaus.org/browse/MNG-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3552.
-
Resolution: Won't Fix
it's not a component. Unfortunately you must construct it manually (which you
can do).
I'll defer any decisions about this to the maven-project refactoring.
> ProfileManager not available as a component
> ---
>
> Key: MNG-3552
> URL: http://jira.codehaus.org/browse/MNG-3552
> Project: Maven 2
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.9
>Reporter: Kohsuke Kawaguchi
>
> ProfileManager is currently not available as a component in plexus, so
> plugins cannot get hold of it, unlike other components.
> IOW, the following code won't work from Mojo.
> {noformat}
> /**
> * @component
> */
> private ProfileManager profileManager;
> {noformat}
--
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-3526) Small change to artifact version parsing.
[ http://jira.codehaus.org/browse/MNG-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3526: -- Fix Version/s: 2.0.x > Small change to artifact version parsing. > - > > Key: MNG-3526 > URL: http://jira.codehaus.org/browse/MNG-3526 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.9 >Reporter: Paul Gier > Fix For: 2.0.x > > Attachments: MNG-3526-maven-artifact-r648413.patch > > > We currently many projects that use an OSGi compatible scheme for release > version numbers. The OSGi spec does not currently allow a "-" to determine > the location of the qualifier. So instead of the maven standard like this: > 1.0.1-beta-1 > We have something like this: > 1.0.1.beta1 > Maven's currently handles this by treating the entire version string as a > classifier. It would be helpful this could be parsed as > major = 1 > minor = 0 > incremental = 1 > qualifier = beta1 -- 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-3491) JAR hell detection
[ http://jira.codehaus.org/browse/MNG-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3491: -- Fix Version/s: 2.x seems best served by the enforcer plugin or similar, but worth considering in some core way in the future > JAR hell detection > -- > > Key: MNG-3491 > URL: http://jira.codehaus.org/browse/MNG-3491 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: Andreas Krüger > Fix For: 2.x > > > When your dependency tree contains the same class twice in two different > versions, you are in JAR hell. > I want Maven to detect whether that's where I am. So Maven should: > * Open all JARs it has added to a dependency tree. > * Check what classes are in each JAR (package name and class name). > * If the same class is found twice in two different JARs, I want Maven to > ** compare the two instances > ** fail the build unless they turn out to be bytewise identical. > All of these things should happen automatically, with every individual > dependency tree. > Unless the user specifically requests. E.g., if the user knows a particular > set of classes is officially in the dependency tree (e.g., of a test), but > never actually loaded, it should be possible to accept different versions of > these classes (some wild card pattern). > Regards, and thank you for providing fine software, > Andreas -- 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
